A local user can trigger a flaw in the Linux kernel's handling of key lookups in the keychain subsystem.

The keyrejectandlink() function contains an error in which a key-lookup can fail and in an attempt to cache the failed lookup may attempt to free memory which can still be in use.

This could crash the system or at worse free a memory block which would then be re-used by another kernel mechanism causing a user after free.

Product bug:

https://bugzilla.redhat.com/showbug.cgi?id=1341352

Upstream patch:

https://www.spinics.net/lists/linux-kernel-janitors/msg26069.html

A vulnerability was found in Linux kernel. There is an information leak in file "sound/core/timer.c" of the latest mainline Linux kernel, the stack object “tread” has a total size of 32 bytes. It contains a 8-bytes padding, which is not initialized but sent to user via copytouser(), resulting a kernel leak.

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.

Last updated 24 July 2024

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

A vulnerability was found in the Linux kernel. A device pretending to be a device driven by the ims-pcu driver but leaving out either of the two interfaces present on the genuine device will oops the driver.

Reference with proposed fix:

https://bugzilla.novell.com/showbug.cgi?id=971628

Linux-input maintainer tree patch:

https://kernel.googlesource.com/pub/scm/linux/kernel/git/dtor/input/+/a0ad220c96692eda76b2e3fd7279f3dcd1d8a8ff

An upstream patch:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a0ad220c96692eda76b2e3fd7279f3dcd1d8a8ff

CVE-ID request: http://seclists.org/oss-sec/2016/q1/715

CVE-ID assignment: http://seclists.org/oss-sec/2016/q1/717

Destroy of network interface with huge number of ipv4 addresses keeps rtnllock for a very long time (up to hour). It blocks many network related operations, including for example creation of new incoming ssh connections.

The problem is especially important for containers, container owner have enough permission to enable this trigger and then can block network access on whole host node.

Upstream fix:

http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=fbd40ea0180a2d328c5adc61414dc8bab9335ce2

References:

http://seclists.org/oss-sec/2016/q1/643

CVE assignment:

http://seclists.org/oss-sec/2016/q1/647

A flaw was found in in the Linux kernel's USB device management code which could cause a crash when a device which required cypressm8 driver. The kernel would panic causing null pointer dereference.

Product bug:

https://bugzilla.redhat.com/showbug.cgi?id=1283368

Kernel crash occurs when presented a buggy USB device which requires digiacceleport driver, causing null pointer dereference.

Product bug:

https://bugzilla.redhat.com/showbug.cgi?id=1283378

A flaw was found in the Linux kernel handling when a buggy USB device is attached attempting to use the cdcacm kernel module. This flaw would cause the kernel to panic by a null pointer dereference.

Public via:

http://seclists.org/bugtraq/2016/Mar/54

CVE-ID request and assignment:

http://seclists.org/oss-sec/2016/q1/605

http://seclists.org/oss-sec/2016/q1/622

Upstream patch:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8835ba4a39cf53f705417b3b3a94eb067673f2c9

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

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

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.

GNOME NetworkManager allows remote attackers to cause a denial of service (IPv6 traffic disruption) via a crafted MTU value in an IPv6 Router Advertisement (RA) message, a different vulnerability than CVE-2015-8215.

It was reported [1] that iptables can allow protocols that do not have a protocol handler kernel module loaded.

Given following iptables ruleset: -P FORWARD DROP -A FORWARD -m sctp --dport 9 -j ACCEPT -A FORWARD -p tcp --dport 80 -j ACCEPT -A FORWARD -p tcp -m conntrack -m state ESTABLISHED,RELATED -j ACCEPT

One would assume that this allows SCTP on port 9 and TCP on port 80. Unfortunately, if the SCTP conntrack module is not loaded, this allows all SCTP communication to pass through, i.e. -p sctp -j ACCEPT

[1]: http://www.spinics.net/lists/netfilter-devel/msg33430.html

Last updated 24 July 2024

arch/x86/kvm/vmx.c in the KVM subsystem in the Linux kernel before 3.17.2 on Intel processors does not ensure that the value in the CR4 control register remains the same after a VM entry, which allows host OS users to kill arbitrary processes or cause a denial of service (system disruption) by leveraging /dev/kvm access, as demonstrated by PRSETTSC prctl calls within a modified copy of QEMU.

A flaw was found in the way iommu mapping failures were handled in kvmiommumappages() function in the Linux kernel. A privileged user in the guest could use this flaw to crash the host in case the guest has access to passed in device.

Acknowledgements:

Red Hat would like to thank Jack Morgenstein of Mellanox for reporting this issue; the security impact of this issue was discovered by Michael Tsirkin of Red Hat.

Description of the problem: For a TCP-style socket, while processing the COOKIEECHO chunk in sctpsfdo51Dce(), after it has passed a series of sanity check, a new association would be created in sctpunpackcookie(), but afterwards, some processing maybe failed, and sctpassociationfree() will be called to free the previously allocated association, in sctpassociationfree(), skackbacklog value is decremented for this socket, since the initial value for skackbacklog is 0, after the decrement, it will be 65535, a wrap-around problem happens, and if we want to establish new associations afterward in the same socket, ABORT would be triggered since sctp deem the accept queue as full.

A remote attacker can block further connection to the particular sctp server socket by sending a specially crafted sctp packet.

Upstream patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d3217b15a19a4779c39b212358a5c71d725822ee

Acknowledgements:

Red Hat would like to thank Gopal Reddy Kodudula of Nokia Siemens Networks for reporting this issue.

Last updated 24 July 2024

Last updated 24 July 2024

Reported by Dave Jones, currently we have:

--w--w--w-. 1 root root 0 2010-11-11 14:56 /sys/kernel/debug/acpi/custommethod

which is just crazy. Change this to --w-------.

This custommethod file allows to inject custom ACPI methods into the ACPI interpreter tables. This control file was introduced with world writeable permissions in Linux Kernel 2.6.33.

Introduced in: http://git.kernel.org/linus/a1a541d86f50a9957beeedb122a035870d602647 http://git.kernel.org/linus/a25ee9200eef07377e1703697afbb5d81f89e500

Fixed in: http://git.kernel.org/linus/ed3aada1bf34c5a9e98af167f125f8a740fc726a

Due to integer underflow and overflow issues when determining the number of pages required for maliciously crafted I/O requests, a local user could send a device ioctl that results in the sequential allocation of a very large number of pages, causing the OOM killer to be invoked and crashing the system:

Proposed patch: http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commit;h=cb4644cac4a2797afc847e6c92736664d4b0ea34

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Last updated 24 July 2024

Description of problem: Upstream commit dab5855 ("perfcounter: Add mmap event hooks to mprotect()") is fundamentally wrong as mprotectfixup() can free 'vma' due to merging. Fix the problem by moving perfeventmmap() hook to mprotectfixup(). In certain scenario, a local, unprivileged user could use this flaw to trigger a denial of service.

Upstream commit: http://git.kernel.org/linus/63bfd7384b119409685a17d5c58f0b56e5dc03da

By submitting certain I/O requests with 0 length, a local user could cause a kernel panic.

Proposed patch: http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commit;h=9284bcf4e335e5f18a8bc7b26461c33ab60d0689

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: gdthioctlalloc() takes the size variable as an int. copyfromuser() takes the size variable as an unsigned long. gen.datalen and gen.senselen are unsigned longs. On x8664 longs are 64 bit and ints are 32 bit.

We could pass in a very large number and the allocation would truncate the size to 32 bits and allocate a small buffer. Then when we do the copyfromuser(), it would result in a memory corruption.

Reference: http://ns3.spinics.net/lists/linux-scsi/msg47361.html

Upstream: http://git.kernel.org/linus/f63ae56e4e97fb12053590e41a4fa59e7daa74a4

Description of problem: In bcmconnect() (in net/can/bcm.c), there is the following code:

sprintf(bo->procname, "%p", sock);

"procname" is a 9-byte char array. On 64-bit platforms, up to 17 bytes may be copied into the buffer. Fortunately, structure padding will most likely prevent this from being a problem, except for the trailing NULL byte, which may overwrite the first byte of the next heap object.

Reference: http://www.spinics.net/lists/netdev/msg145791.html

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: Reported by Nelson Elhage.

CVE-2010-3848 AFECONET kernel stack overflow CVE-2010-3849 AFECONET saddr->cookie NULL dereferences CVE-2010-3850 AFECONET SIOCSIFADDR ioctl does not check privileges

The two main vulnerabilities lie in the econetsendmsg() function. If CONFIGECONETAUNUDP, the function declares a variable-length array of iovec's on the stack:

static int econetsendmsg(struct kiocb iocb, struct socket sock, struct msghdr msg, sizet len) { ... #ifdef CONFIGECONETAUNUDP ... struct iovec iov[msg->msgiovlen+1]; ... #endif

"msg->msgiovlen" is a user-controlled value <= 1024; 1024 'struct iovec's is enough to overflow the kernel stack and clobber the 'threadinfo' struct on either 32- or 64-bit systems with or without CONFIG4KSTACKS.

The code populates 'iov' with user-controlled values, so this is almost certainly exploitable for privesc.

The second bug is conveniently labeled as such for anyone who cares to look:

/ BUG: saddr may be NULL / eb->cookie = saddr->cookie;

In fact, 'saddr' comes from userspace and may be NULL (if non-NULL, it will have been copied to kernelspace), leading to a NULL-pointer dereference. This saddr->cookie dereference appears twice, once in the "hardware" case and once in the "UDP emulation" case. This is easily exploitable for an oops, but probably not anything more.

The final issue is in the ecdevioctl function. The SIOCSIFADDR ioctl does not check privileges, allowing an unprivileged user to assign econet addresses to arbitrary interfaces. It is possible this is intentional, but AFAIK it would be unusual for SIOCSIFADDR to be unprivileged, so this may be an accident.

Note that it is necessary to use this property in order to make the first two bugs exploitable, since econetsendmsg will return almost immediately if no econet addresses are configured.

Reference: http://seclists.org/oss-sec/2010/q4/236