aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/core
diff options
context:
space:
mode:
authorJann Horn <jannh@google.com>2022-01-26 14:14:52 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-02-11 10:57:07 +0100
commit57bc3d3ae8c14df3ceb4e17d26ddf9eeab304581 (patch)
treea236eb36c72058755014fa1eacb3d71d385d0206 /drivers/usb/core
parentusb: dwc3: gadget: Prevent core from processing stale TRBs (diff)
downloadlinux-dev-57bc3d3ae8c14df3ceb4e17d26ddf9eeab304581.tar.xz
linux-dev-57bc3d3ae8c14df3ceb4e17d26ddf9eeab304581.zip
net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup
ax88179_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular: - The metadata array (hdr_off..hdr_off+2*pkt_cnt) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data. I have tested that this can be used by a malicious USB device to send a bogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in response that contains random kernel heap data. It's probably also possible to get OOB writes from this on a little-endian system somehow - maybe by triggering skb_cow() via IP options processing -, but I haven't tested that. Fixes: e2ca90c276e1 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver") Cc: stable@kernel.org Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/usb/core')
0 files changed, 0 insertions, 0 deletions