Re: [PATCH v2] i2c-hid: introduce HID over i2c specification implementation
flat view
From: Jiri Slaby <hidden>
Date: 2012-10-16 08:17:58
Also in:
linux-i2c, lkml
On 10/15/2012 10:38 PM, Benjamin Tissoires wrote:
Notes:
{1}: I don't have all the informations in the beginning of the probe function to
get the real size I need to allocate. So the behavior is to allocate first a
buffer by using HID_MIN_BUFFER_SIZE and once I got the information, I can
reallocate the buffer to the right size (in i2c_hid_start).And there is a bug in this. See below.
quoted hunk ↗ jump to hunk
--- /dev/null +++ b/drivers/hid/i2c-hid/i2c-hid.c
...
quoted hunk ↗ jump to hunk
+static int i2c_hid_alloc_buffers(struct i2c_hid *ihid) +{ + /* the worst case is computed from the set_report command with a + * reportID > 15 and the maximum report length */ + int args_len = sizeof(__u8) + /* optional ReportID byte */ + sizeof(__u16) + /* data register */ + sizeof(__u16) + /* size of the report */ + ihid->bufsize; /* report */ + + ihid->inbuf = kzalloc(ihid->bufsize, GFP_KERNEL); + + if (!ihid->inbuf) + return -ENOMEM; + + ihid->argsbuf = kzalloc(args_len, GFP_KERNEL); + + if (!ihid->argsbuf) { + kfree(ihid->inbuf); + return -ENOMEM; + } + + ihid->cmdbuf = kzalloc(sizeof(union command) + args_len, GFP_KERNEL); + + if (!ihid->cmdbuf) { + kfree(ihid->inbuf); + kfree(ihid->argsbuf); + return -ENOMEM; + } + + return 0;
If this is called from hid_start and some of the latter allocation fails here, you free the buffers appropriately. However if another start occurs (e.g. by loading another module for that particular device), it will crash, as the buffers will remain unallocated because at this point ihid->bufsize == old_bufsize. You should set ihid->bufsize back to old_bufsize if i2c_hid_alloc_buffers fails and also set the pointers to NULL here. regards, -- js suse labs