Segfault during fread after generic scsi ioctl - c

Question

Background
I am writing a tool to boot up an embedded ARM system over USB. This particular ARM system has a boot loader which can load a system over USB by emulating a Mass storage device and implementing some vendor SCSI opcodes which allow the host to write information to memory. My tool, which runs on the host to which the embedded ARM system is attached, is to send a zImage or other binary to the device using these vendor commands.
I use the Linux generic SCSI interface to send the commands.
After sending a few commands to write values into the registers that control the RAM controller, my program opens a file, then enters a loop within which it reads 4096 bytes at a time from the file, then sends them to the device.
I do not have any documentation for the SCSI commands that need to be sent. I have determined the protocol to use by capturing and analyzing the USB traffic which is sent by an equivalent windows-only tool that the vendor provides. There are some strange aspects to this protocol, particularly that it accepts addresses and values in little endian format and that 32 bit values within the SCSI commands are not word aligned, however I don't think these have any bearing to the problem at hand.
The Problem
After sending the first 7 buffers, the program segfaults.
The section that segfaults is as follows:
int ak_usbboot_writefile(ak_usbboot_dev* dev, const char *filename, uint32_t addr) {
uint8_t dataBuff[DATABUFF_SIZE];
size_t len;
printf("STOREFILE: FILENAME=%s ADDR=%08x\n", filename, addr);
ak_usbboot_errno = AK_USBBOOT_OK;
FILE *f = fopen(filename, "rb");
if (f==NULL) {
ak_usbboot_errno = errno;
return errno;
}
/* Segfault occurs on the next line */
while ( (len = fread(dataBuff, 1, DATABUFF_SIZE, f)) > 0) {
printf("read len=%ld\n", len);
int r = ak_usbboot_storemem(dev, dataBuff, len, addr);
if (r!=AK_USBBOOT_OK) {
goto EXIT;
}
addr += len;
}
The segfault occurs calling fread. The backtrace looks like this:
#0 __memcpy_sse2 () at ../sysdeps/x86_64/memcpy.S:272
#1 0x00007f92907b9233 in __GI__IO_file_xsgetn (fp=0x1f10030, data=<optimized out>, n=4096) at fileops.c:1427
#2 0x00007f92907ae9d8 in __GI__IO_fread (buf=<optimized out>, size=1, count=4096, fp=0x1f10030) at iofread.c:42
#3 0x0000000000401492 in ak_usbboot_writefile (dev=0x1f10010, filename=0x7fff078b0718 "/home/harmic/git/Lamobo-D1s/tool/burntool/zImage", addr=2174808064) at ak_usbboot.c:217
#4 0x0000000000400c4d in ak_boot (dev_name=0x7fff078b070f "/dev/sg2", file=0x7fff078b0718 "/home/harmic/git/Lamobo-D1s/tool/burntool/zImage") at main.c:86
#5 0x0000000000400d68 in cmd_boot (argc=2, argv=0x7fff078af538) at main.c:114
#6 0x0000000000400dfc in main (argc=4, argv=0x7fff078af528) at main.c:130
I can't see anything wrong with the way the file is being handled, and if I comment out the call to ak_usbboot_storemem then the loop completes with no problems.
ak_usbboot_storemem looks like this:
int ak_usbboot_storemem(ak_usbboot_dev* dev, const void* buffer, uint32_t len, uint32_t addr) {
uint8_t cmdBuff[16] = {
0xf1, 0x3f, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x68, 0, 0
};
printf("STORE: INBUFF=%p LEN=%08x ADDR=%08x\n", buffer, len, addr);
memcpy(&cmdBuff[5], &addr, 4);
memcpy(&cmdBuff[9], &len, 4);
return _sendCmd(dev, &cmdBuff, sizeof(cmdBuff), (void*)buffer, len, SG_DXFER_TO_DEV);
}
_sendCmd looks like this:
int _sendCmd(ak_usbboot_dev* dev, const void* cmdBuff, int cmdLen, void* dataBuff, int dataLen, int sg_dir) {
fputs("CMD: ", stdout);
const uint8_t* p = (const uint8_t*)cmdBuff;
for (int i=0; i<cmdLen; i++) {
printf("%02x ", *p++);
}
fputs("\n", stdout);
sg_io_hdr_t io_hdr = {
.interface_id = 'S',
.dxfer_direction = sg_dir,
.cmd_len = cmdLen,
.mx_sb_len = sizeof(dev->sense_buffer),
.iovec_count = 0,
.dxfer_len = dataLen,
.dxferp = dataBuff,
.cmdp = (void*)cmdBuff,
.sbp = dev->sense_buffer,
.timeout = 10000,
.flags = 0,
.pack_id = 0,
};
if (ioctl(dev->fd, SG_IO, &io_hdr) < 0) {
ak_usbboot_errno = errno;
return ak_usbboot_errno;
}
if ((io_hdr.info & SG_INFO_OK_MASK) != SG_INFO_OK) {
dev->sb_len = io_hdr.sb_len_wr;
dev->driver_status = io_hdr.driver_status;
dev->masked_status = io_hdr.masked_status;
dev->host_status = io_hdr.host_status;
ak_usbboot_errno = AK_USBBOOT_SCSIERR;
return AK_USBBOOT_SCSIERR;
} else {
dev->err = AK_USBBOOT_OK;
return AK_USBBOOT_OK;
}
}
I am guessing something I am doing with the SCSI Generic IOCTL is causing this, but I have not been able to spot anything so far.
Any insights welcomed!

Answer 1

The comment from #Andrew Medico put me on the right track. I should have thought of using valgrind earlier.
Valgrind reported multiple errors like this:
==28114== Invalid write of size 4
==28114== at 0x400FF5: _sendCmd (ak_usbboot.c:73)
==28114== by 0x4010D7: ak_usbboot_open (ak_usbboot.c:104)
==28114== by 0x400B7E: ak_boot (main.c:70)
==28114== by 0x400D67: cmd_boot (main.c:114)
==28114== by 0x400DFB: main (main.c:130)
==28114== Address 0x51f3074 is not stack'd, malloc'd or (recently) free'd
When running under valgrind, the program completed normally, booting the device as it should!
ak_usbboot.c:73 is this line:
dev->err = AK_USBBOOT_OK;
That lead me to look more closely at where dev was being allocated:
ak_usbboot_dev* dev = malloc(sizeof(dev));
Oops. I was allocating enough space for a pointer to a struct, rather than to the struct itself. As a result writing to the struct was corrupting the heap.
Of course it should have been:
ak_usbboot_dev* dev = malloc(sizeof(*dev));
This answer is probably not much use to anyone else, other than as a tip as to how to track down such problems - valgrind is a godsend.