hw/scsi/scsi-disk.c line 2554 allocation overflow
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Expired
|
Undecided
|
Unassigned |
Bug Description
When compiling qemu from git master (at commit 03bf012e523ecdf
make[1]: Entering directory '/home/
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/
nm: stats64.o: no symbols
LINK aarch64-
In function ‘scsi_disk_
inlined from ‘scsi_new_request’ at hw/scsi/
inlined from ‘scsi_new_request’ at hw/scsi/
hw/scsi/
hw/scsi/
/usr/include/
78 | gpointer g_malloc (gsize n_bytes) G_GNUC_MALLOC G_GNUC_
| ^
lto1: all warnings being treated as errors
lto-wrapper: fatal error: c++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
same happens for most other targets: alpha-softmmu/
Notice -softmmu being a common factor here.
The size of the allocation for the temporary buffer for dumping using snprintf is determined based on the size of the buffer via call to scsi_cdb_length. I believe the heavy inlining and constant propagation makes scsi_cdb_length return -1, so len = -1. Then allocation size is 5*len + 1, or -4. Which overflows to 2^64 - 4 or so.
The case of len==-1 from scsi_cdb_length happens if the (buf[0] >> 5) is not 0, 1, 2, 4 or 5.
However, I can't find out how gcc figures out that buf[0] is not one of these variables. To me looking at this function, compiler should not know anything about buf[0].
I tried following the chain of calls back, including devirtualize alloc_req, and I found scsi_device_
glib2 version 2.62.1-1
FYI. Adding if (len <= 0) return; in the scsi_disk_ new_request_ dump solved the compilation issue for me.
So indeed gcc thinks len == -1
I am pretty sure the build qemu is functional, as this path is only taken if the trace_event_ get_state_ backends( TRACE_SCSI_ DISK_NEW_ REQUEST) is true, which by default it is not.
BTW. Also, aarch64- softmmu/ qemu-system- aarch64 takes very long time to link compared to other targets, so I recommend using -flto=16 to increase parallelism, and reduce lto link time to about 4 minutes. (But 64GB of memory recommended).
I also tested with --disable-slirp configure flag. Still same issue.