A vulnerability was found in the usbnet Linux kernel driver.

The bug allows physically proximate attackers to cause a denial of service (NULL pointer dereference and system crash) or possibly have other impact by inserting a USB device with an invalid USB descriptor.

Upstream fixes:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4d06dd537f95683aba3651098ae288b7cbff8274 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1666984c8625b3db19a9abc298931d35ab7bc64b

External references:

https://www.spinics.net/lists/netdev/msg367669.html https://bugzilla.novell.com/showbug.cgi?id=974418

Reference and CVE assignment:

http://seclists.org/oss-sec/2016/q2/19

Last updated 24 July 2024

A local kernel crash on invalid USB device requiring the visor driver was reported. The treoattach() function of the [visor] driver, which is called during the driver initialization process, was dereferencing the bulk-in and interrupt-in urbs without first making sure they had been allocated by core. Due to an incomplete sanity check, the visor driver tries to dereference null-pointers, which results in crash.

Vulnerable code:

CentOS-Kernel linux-3.10.0-229.14.1.el7 (drivers/usb/serial/visor.c) ... 554 #define COPYPORT(dest, src) \ 555 do { \ 556 int i; \ 557 \ 558 for (i = 0; i < ARRAYSIZE(src->readurbs); ++i) { \ 559 dest->readurbs[i] = src->readurbs[i]; \ / Possible Nullpointer-Dereference / 560 dest->readurbs[i]->context = dest; \ 561 dest->bulkinbuffers[i] = src->bulkinbuffers[i]; \ 562 } \ 563 dest->readurb = src->readurb; \ 564 dest->bulkinendpointAddress = src->bulkinendpointAddress;\ 565 dest->bulkinbuffer = src->bulkinbuffer; \ 566 dest->bulkinsize = src->bulkinsize; \ 567 dest->interruptinurb = src->interruptinurb; \ 568 dest->interruptinurb->context = dest; \ 569 dest->interruptinendpointAddress = \ 570 src->interruptinendpointAddress;\ 571 dest->interruptinbuffer = src->interruptinbuffer; \ 572 } while (0); 573 574 swapport = kmalloc(sizeof(swapport), GFPKERNEL); 575 if (!swapport) 576 return -ENOMEM; 577 COPYPORT(swapport, serial->port[0]); / no sanity-check! / 578 COPYPORT(serial->port[0], serial->port[1]); / no sanity-check! / 579 COPYPORT(serial->port[1], swapport); / no sanity-check! / ...

Reproducer can be found in original bug report: https://bugzilla.redhat.com/showbug.cgi?id=1283374

An upstream patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cb3232138e37129e88240a98a1d2aba2187ff57c

Public via: http://seclists.org/bugtraq/2016/Mar/86

CVE-ID request and assignment: http://seclists.org/oss-sec/2016/q1/456 http://seclists.org/oss-sec/2016/q1/458

ISSUE DESCRIPTION =================

Xen PCI backend driver does not perform proper sanity checks on the device's state.

Which in turn allows the generic MSI code (called by Xen PCI backend) to be called incorrectly leading to hitting BUG conditions or causing NULL pointer exceptions in the MSI code.

To exploit this the guest can craft specific sequence of XENPCIOP operations which will trigger this.

Furthermore the frontend can also craft an continous stream of XENPCIOPenablemsi which will trigger an continous stream of WARN() messages triggered by the MSI code leading to the logging in the initial domain to exhaust disk space.

Lastly there is also missing check to verify whether the device has memory decoding enabled set at the start of the day leading the initial domain "accesses to the respective MMIO or I/O port ranges would - - on PCI Express devices - [which can] lead to Unsupported Request responses. The treatment of such errors is platform specific." (from XSA-120). Note that if XSA-120 'addendum' patch has been applied this particular sub-issue is not exploitable.

IMPACT ======

Malicious guest administrators can cause denial of service. If driver domains are not in use, the impact is a host crash.

Only x86 systems are vulnerable. ARM systems are not vulnerable.

VULNERABLE SYSTEMS ==================

This bug affects systems using Linux as the driver domain, including non-disaggregated systems using Linux as dom0.

Linux versions v3.1 and onwards are vulnerable due to supporting PCI pass-through backend driver.

PV and HVM guests which have been granted access to physical PCI devices (PCI passthrough') can take advantage of this vulnerability.

Furthermore, the vulnerability is only applicable when the passed-through PCI devices are MSI-capable or MSI-X. (Most modern devices are).

MITIGATION ==========

Not using PCI passthrough for PV and HVM guests. Note that for HVM guests QEMU is used for PCI passthrough - however the toolstack sets up also the 'PV' PCI which the guest can utilize if it chooses to do so.

External References:

http://xenbits.xen.org/xsa/advisory-157.html

Acknowledgements:

Red Hat would like to thank the Xen project for reporting this issue.

A patch was posted to fix an issue regarding unkillable task eating CPU.

The problem is in the fusefillwritepages() function. When a user calls the syswritev syscall with specially crafted sequence of iovs the kernel function may never terminate and continue in a tight loop, the process is unable to be killed.

Introduced in commit ea9b9907b82a09bd1a708004454f7065de77c5b0 Fixed in commit 3ca8138f014a913f98e6ef40e939868e1e9ea876

Upstream patch: https://lkml.org/lkml/2015/10/12/329

Last updated 24 July 2024

The tmreclaimthread function in arch/powerpc/kernel/process.c in the Linux kernel before 4.4.1 on powerpc platforms does not ensure that TM suspend mode exists before proceeding with a tmreclaim call, which allows local users to cause a denial of service (TM Bad Thing exception and panic) via a crafted application.