A data race that can trick the kernel into using initialized memory was found. This vulnerability can at least give access to arbitrary SysV shared memory. It is almost certain that this vulnerability can be used to gain arbitrary code execution in the kernel.
While working on KTSAN, Dmitry Vyukov got a report that says that ipcaddid() installs a not-completely initialized object into the shared object table. In particular, uid/gid are not initialized. ipcobtainobjectcheck() in turn obtains the object and verifies uid/gid for permission purposes. Since the fields are not initialized, the check can falsely succeed.
Race report:
ThreadSanitizer: data-race in ipcobtainobjectcheck
Read at 0xffff88047f810f68 of size 8 by thread 2749 on CPU 5: [<ffffffff8147d84d>] ipcobtainobjectcheck+0x7d/0xd0 ipc/util.c:621 [< inline >] msqobtainobjectcheck ipc/msg.c:90 [<ffffffff8147e708>] msgctlnolock.constprop.9+0x208/0x430 ipc/msg.c:480 [< inline >] SYSCmsgctl ipc/msg.c:538 [<ffffffff8147f061>] SySmsgctl+0xa1/0xb0 ipc/msg.c:522 [<ffffffff81ee3e11>] entrySYSCALL64fastpath+0x31/0x95 arch/x86/entry/entry64.S:188
Previous write at 0xffff88047f810f68 of size 8 by thread 2755 on CPU 4: [<ffffffff8147cf97>] ipcaddid+0x217/0x260 ipc/util.c:257 [<ffffffff8147eb4c>] newque+0xac/0x240 ipc/msg.c:141 [< inline >] ipcgetpublic ipc/util.c:355 [<ffffffff8147daa2>] ipcget+0x202/0x280 ipc/util.c:646 [< inline >] SYSCmsgget ipc/msg.c:255 [<ffffffff8147efaa>] SySmsgget+0x7a/0x90 ipc/msg.c:241 [<ffffffff81ee3e11>] entrySYSCALL64fastpath+0x31/0x95 arch/x86/entry/entry64.S:188
Mutexes locked by thread 2755: Mutex 445417 is locked here: [<ffffffff81ee0d45>] downwrite+0x65/0x80 kernel/locking/rwsem.c:62 [< inline >] ipcgetpublic ipc/util.c:348 [<ffffffff8147d90c>] ipcget+0x6c/0x280 ipc/util.c:646 [< inline >] SYSCmsgget ipc/msg.c:255 [<ffffffff8147efaa>] SySmsgget+0x7a/0x90 ipc/msg.c:241 [<ffffffff81ee3e11>] entrySYSCALL64fastpath+0x31/0x95 arch/x86/entry/entry64.S:188
Mutex 453634 is locked here: [< inline >] rawspinlock include/linux/spinlockapismp.h:158 [<ffffffff81ee37d0>] rawspinlock+0x50/0x70 kernel/locking/spinlock.c:151 [< inline >] spinlock include/linux/spinlock.h:312 [<ffffffff8147ce0e>] ipcaddid+0x8e/0x260 ipc/util.c:238 [<ffffffff8147eb4c>] newque+0xac/0x240 ipc/msg.c:141 [< inline >] ipcgetpublic ipc/util.c:355 [<ffffffff8147daa2>] ipcget+0x202/0x280 ipc/util.c:646 [< inline >] SYSCmsgget ipc/msg.c:255 [<ffffffff8147efaa>] SySmsgget+0x7a/0x90 ipc/msg.c:241 [<ffffffff81ee3e11>] entrySYSCALL64fastpath+0x31/0x95 arch/x86/entry/entry64.S:188
ipcaddid installs new ipc object with idralloc, from this point on it is accessible to other threads. At this point the object contains unitialized garbage. Then it fills in uid, etc:
new->cuid = new->uid = euid; new->gid = new->cgid = egid; new->seq = ids->seq++;
While this happens another thread can get access to the object and do uid check on the unitialized garbage, which can give falsely give accesses to the shared object to a process that should not have access to the object.
Upstream patch:
https://github.com/torvalds/linux/commit/b9a532277938
CVE assignment:
http://seclists.org/oss-sec/2015/q4/7
A flaw was found in the way the Linux kernel's file system implementation handled rename operations in which the source was inside and the destination was outside of a bind mount. A privileged user inside a container could use this flaw to escape the bind mount and, potentially, escalate their privileges on the system.
It was found that the Linux kernel's Infiniband subsystem did not properly sanitize input parameters while registering memory regions from the userspace via the (u)verbs API. As a result, an unrestricted physical memory access could be achieved.
A local user with access to /dev/infiniband/uverbsX could use this flaw to crash the system or, potentially, escalate their privileges on the system.
Buffer overflow in the picolcdrawevent function in devices/hid/hid-picolcdcore.c in the PicoLCD HID device driver in the Linux kernel through 3.16.3, as used in Android on Nexus 7 devices, allows physically proximate attackers to cause a denial of service (system crash) or possibly execute arbitrary code via a crafted device that sends a large report.
Last updated 24 July 2024
Array index error in the logidjrawevent function in drivers/hid/hid-logitech-dj.c in the Linux kernel before 3.16.2 allows physically proximate attackers to execute arbitrary code or cause a denial of service (invalid kfree) via a crafted device that provides a malformed REPORTTYPENOTIFDEVICEUNPAIRED value.
Last updated 24 July 2024
A flaw was found in the way pppol2tpsetsockopt() and pppol2tpgetsockopt() functions in the Linux kernel's PPP over L2TP implementation handled non-SOLPPPOL2TP level.
A local, unprivileged user could use this flaw to escalate their privileges on the system.
Acknowledgements:
Red Hat would like to thank Sasha Levin for reporting this issue.
It was found that the Linux kernel's ptrace subsystem allowed a traced process' instruction pointer to be set to a non-canonical memory address without forcing the non-sysret code path when returning to user space. A local, unprivileged user could use this flaw to crash the system or, potentially, escalate their privileges on the system. Note: The CVE-2014-4699 issue only affected systems using an Intel CPU.
Last updated 24 July 2024
Last updated 24 July 2024
Buffer overflow in the nfs4getacluncached function in fs/nfs/nfs4proc.c in the Linux kernel before 3.7.2 allows local users to cause a denial of service (memory corruption and system crash) or possibly have unspecified other impact via a getxattr system call for the system.nfs4acl extended attribute of a pathname on an NFSv4 filesystem.
Buffer overflow in the exitcodeprocwrite function in arch/um/kernel/exitcode.c in the Linux kernel before 3.12 allows local users to cause a denial of service or possibly have unspecified other impact by leveraging root privileges for a write operation.
Last updated 24 July 2024
Buffer overflow in the ozcdevwrite function in drivers/staging/ozwpa ...
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
A flaw was found in the way ipcrcuputref() function handled reference counter decrementing. Without external synchronization reference counter might not be adjusted properly, as presented with the freeque() vs domsgsnd() race, leading to memory leaks.
An unprivileged local user could use this flaw to cause OOM conditions, potentially crashing the system.
References: https://wiki.openvz.org/Download/kernel/rhel6-testing/042stab084.3
Upstream patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6062a8 (making the refcounter atomic hunks)
Acknowledgements:
Red Hat would like to thank Vladimir Davydov (Parallels) for reporting this issue.
Last updated 24 July 2024
Last updated 24 July 2024
drivers/hid/hid-sony.c in the Human Interface Device (HID) subsystem in the Linux kernel through 3.11, when CONFIGHIDSONY is enabled, allows physically proximate attackers to cause a denial of service (heap-based out-of-bounds write) via a crafted device.
drivers/hid/hid-steelseries.c in the Human Interface Device (HID) subsystem in the Linux kernel through 3.11, when CONFIGHIDSTEELSERIES is enabled, allows physically proximate attackers to cause a denial of service (heap-based out-of-bounds write) via a crafted device.
Alan Chester reported an issue with IPv6 on SCTP that IPsec traffic is not being encrypted, whereas on IPv4 it is. Setting up an AH + ESP transport does not seem to have the desired effect:
SCTP + IPv4:
22:14:20.809645 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 116) 192.168.0.2 > 192.168.0.5: AH(spi=0x00000042,sumlen=16,seq=0x1): ESP(spi=0x00000044,seq=0x1), length 72 22:14:20.813270 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 340) 192.168.0.5 > 192.168.0.2: AH(spi=0x00000043,sumlen=16,seq=0x1):
SCTP + IPv6:
22:31:19.215029 IP6 (class 0x02, hlim 64, next-header SCTP (132) payload length: 364) fe80::222:15ff:fe87:7fc.3333 > fe80::92e6:baff:fe0d:5a54.36767: sctp 1) [INIT ACK] [init tag: 747759530] [rwnd: 62464] [OS: 10] [MIS: 10]
References: https://bugzilla.kernel.org/showbug.cgi?id=24412
Upstream fix: http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=95ee62083cb6453e056562d91f597552021e6ae7
A flaw was found in the way ansi cprng implementation in the Linux kernel processed non-block size aligned requests. If several small requests are made that are less than the instances block size, the remainder for loop code doesn't increment randdatavalid in the last iteration, meaning that the last bytes in the randdata buffer gets reused on the subsequent smaller-than-a-block request for random data.
Acknowledgements:
Red Hat would like to thank Stephan Mueller for reporting this issue.
A flaw was found in the way Linux kernel's device-mapper subsystem, under certain conditions, interpreted data written to snapshot block devices. Snapshots are constructed from a single "cow" (copy-on-write) device that contains a mixture of data and metadata, and the bug involves a user writing a data block that is later incorrectly interpreted as metadata controlling how blocks are mapped.
An attacker could construct a mapping to read data from disk blocks in 'free space' that is normally inaccessible.
Please note that apart from having security consequences (data leak), this bug is also a data corruptor.
Acknowledgements:
Red Hat would like to thank Fujitsu for reporting this issue.
Last updated 24 July 2024
Last updated 24 July 2024
A flaw was found in the way Linux kernel's SCTP network protocol implementation handled duplicate cookies. A transient empty association is created while processing the duplicate cookie chunk that userspace could query, potentially leading to NULL pointer dereference. A remote attacker able to initiate SCTP connection to the system could use this flaw to create transient conditions that could lead to remote system crash if remote system user is querying SCTP connection info at the time these conditions exist.
Upstream fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f2815633504b442ca0b0605c16bf3d88a3a0fcea
Last updated 24 July 2024