HID: fix data access in implement()
implement() is setting bytes in LE data stream. In case the data is not aligned to 64bits, it reads past the allocated buffer. It doesn't really change any value there (it's properly bitmasked), but in case that this read past the boundary hits a page boundary, pagefault happens when accessing 64bits of 'x' in implement(), and kernel oopses. This happens much more often when numbered reports are in use, as the initial 8bit skip in the buffer makes the whole process work on values which are not aligned to 64bits. This problem dates back to attempts in 2005 and 2006 to make implement() and extract() as generic as possible, and even back then the problem was realized by Adam Kroperlin, but falsely assumed to be impossible to cause any harm: http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html I have made several attempts at fixing it "on the spot" directly in implement(), but the results were horrible; the special casing for processing last 64bit chunk and switching to different math makes it unreadable mess. I therefore took a path to allocate a few bytes more which will never make it into final report, but are there as a cushion for all the 64bit math operations happening in implement() and extract(). All callers of hid_output_report() are converted at the same time to allocate the buffer by newly introduced hid_alloc_report_buf() helper. Bruno noticed that the whole raw_size test can be dropped as well, as hid_alloc_report_buf() makes sure that the buffer is always of a proper size. Reviewed-by:Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
mentioned in commit 6666ae9c
-
mentioned in commit b420c5f5
-
mentioned in commit 0fc9111e
-
mentioned in commit 853ec04e
-
mentioned in commit 25a43138
-
mentioned in commit e0a0572c
-
mentioned in commit 8a7b621b
-
mentioned in commit 086ea1ad
-
mentioned in commit 909a1e5f
-
mentioned in commit 47ed953e
-
mentioned in commit 1d07eac5
-
mentioned in commit e18a2d09
-
mentioned in commit eb33bcb0
-
mentioned in commit 503d74b6
-
mentioned in commit 680d5eea
-
mentioned in commit 4c69e62e
-
mentioned in commit 3e6ad0bb
-
mentioned in commit 078d4362
-
mentioned in commit be603d50
-
mentioned in commit 3dff1855
-
mentioned in commit 66e9a399
-
mentioned in commit d16c37a7
-
mentioned in commit f53f8f20
-
mentioned in commit 07c59bff
-
mentioned in commit 6a64c8e6
-
mentioned in commit cf8498e1
-
mentioned in commit ffe3b3e4
-
mentioned in commit 167f328f
-
mentioned in commit a0857338
-
mentioned in commit b9b52f3d
-
mentioned in commit 818cb313
-
mentioned in commit f02dd268
-
mentioned in commit 5c1e825c
-
mentioned in commit 81b67e62
-
mentioned in commit 56790fb1
-
mentioned in commit cbb44b1f
-
mentioned in commit e9804015
-
mentioned in commit e5a51f40
-
mentioned in commit ccf67492
-
mentioned in commit 7316d67b
-
mentioned in commit 7dbf216e
-
mentioned in commit cd241a90
-
mentioned in commit c8949393