In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftfib: fix stale stack leak via the OIFNAME register
For NFTFIBRESULTOIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTNLOCAL and oif-mismatch paths nftfib{4,6}eval() only writes one register via "dest = 0". The remaining three registers are left as whatever was on the stack in nftdochain()'s struct nftregs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace.
The NFTAFIBFPRESENT existence check has the same shape: it is only meaningful for NFTFIBRESULTOIF, yet it was accepted for any result type while the eval stores a single byte via nftregstore8(), leaving the rest of the declared span stale.
Fix both:
- replace the bare "dest = 0" in the eval with nftfibstoreresult(), which strscpypad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and
- restrict NFTAFIBFPRESENT to NFTFIBRESULTOIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.
In the Linux kernel, the following vulnerability has been resolved:
tracepoint: balance regfunc() on funcadd() failure in tracepointaddfunc()
When a tracepoint goes through the 0 -> 1 transition, tracepointaddfunc() invokes the subsystem's ext->regfunc() before attempting to install the new probe via funcadd(). If funcadd() then fails (for example, when allocateprobes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them.
For syscall tracepoints this is particularly unpleasant: syscallregfunc() bumps systracepointrefcount and sets SYSCALLTRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state.
Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the funcadd() error path, gated on the same condition used there so the unwind is symmetric with the registration.
ext4: dax: fix overflowing extents beyond inode size when partially writing
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: core: Check for unset descriptor
Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case.
This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found.
No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets.
devres: Fix memory leakage caused by driver API devmfreepercpu()
In the Linux kernel, the following vulnerability has been resolved:
inetdiag: Initialize pad field in struct inetdiagreqv2
KMSAN reported uninit-value access in rawlookup() [1]. Diag for raw sockets uses the pad field in struct inetdiagreqv2 for the underlying protocol. This field corresponds to the sdiagrawprotocol field in struct inetdiagreqraw.
inetdiaggetexactcompat() converts inetdiagreq to inetdiagreqv2, but leaves the pad field uninitialized. So the issue occurs when rawlookup() accesses the sdiagrawprotocol field.
Fix this by initializing the pad field in inetdiaggetexactcompat(). Also, do the same fix in inetdiagdumpcompat() to avoid the similar issue in the future.
[1] BUG: KMSAN: uninit-value in rawlookup net/ipv4/rawdiag.c:49 [inline] BUG: KMSAN: uninit-value in rawsockget+0x657/0x800 net/ipv4/rawdiag.c:71 rawlookup net/ipv4/rawdiag.c:49 [inline] rawsockget+0x657/0x800 net/ipv4/rawdiag.c:71 rawdiagdumpone+0xa1/0x660 net/ipv4/rawdiag.c:99 inetdiagcmdexact+0x7d9/0x980 inetdiaggetexactcompat net/ipv4/inetdiag.c:1404 [inline] inetdiagrcvmsgcompat+0x469/0x530 net/ipv4/inetdiag.c:1426 sockdiagrcvmsg+0x23d/0x740 net/core/sockdiag.c:282 netlinkrcvskb+0x537/0x670 net/netlink/afnetlink.c:2564 sockdiagrcv+0x35/0x40 net/core/sockdiag.c:297 netlinkunicastkernel net/netlink/afnetlink.c:1335 [inline] netlinkunicast+0xe74/0x1240 net/netlink/afnetlink.c:1361 netlinksendmsg+0x10c6/0x1260 net/netlink/afnetlink.c:1905 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x332/0x3d0 net/socket.c:745 syssendmsg+0x7f0/0xb70 net/socket.c:2585 syssendmsg+0x271/0x3b0 net/socket.c:2639 syssendmsg net/socket.c:2668 [inline] dosyssendmsg net/socket.c:2677 [inline] sesyssendmsg net/socket.c:2675 [inline] x64syssendmsg+0x27e/0x4a0 net/socket.c:2675 x64syscall+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
Uninit was stored to memory at: rawsockget+0x650/0x800 net/ipv4/rawdiag.c:71 rawdiagdumpone+0xa1/0x660 net/ipv4/rawdiag.c:99 inetdiagcmdexact+0x7d9/0x980 inetdiaggetexactcompat net/ipv4/inetdiag.c:1404 [inline] inetdiagrcvmsgcompat+0x469/0x530 net/ipv4/inetdiag.c:1426 sockdiagrcvmsg+0x23d/0x740 net/core/sockdiag.c:282 netlinkrcvskb+0x537/0x670 net/netlink/afnetlink.c:2564 sockdiagrcv+0x35/0x40 net/core/sockdiag.c:297 netlinkunicastkernel net/netlink/afnetlink.c:1335 [inline] netlinkunicast+0xe74/0x1240 net/netlink/afnetlink.c:1361 netlinksendmsg+0x10c6/0x1260 net/netlink/afnetlink.c:1905 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x332/0x3d0 net/socket.c:745 syssendmsg+0x7f0/0xb70 net/socket.c:2585 syssendmsg+0x271/0x3b0 net/socket.c:2639 syssendmsg net/socket.c:2668 [inline] dosyssendmsg net/socket.c:2677 [inline] sesyssendmsg net/socket.c:2675 [inline] x64syssendmsg+0x27e/0x4a0 net/socket.c:2675 x64syscall+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
Local variable req.i created at: inetdiaggetexactcompat net/ipv4/inetdiag.c:1396 [inline] inetdiagrcvmsgcompat+0x2a6/0x530 net/ipv4/inetdiag.c:1426 sockdiagrcvmsg+0x23d/0x740 net/core/sockdiag.c:282
CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix memleak in seg6hmacinitalgo
seg6hmacinitalgo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms.
Update seg6hmacexit to only free the memory when allocated, so we can reuse the code directly.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: add NULL checks for idev in SRv6 paths
in6devget() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6MINMTU or after NETDEVUNREGISTER).
Add NULL checks for idev returned by in6devget() in both seg6hmacvalidateskb() and ipv6srhrcv() to prevent potential NULL pointer dereferences.
An out-of-bounds memory write flaw in the Linux kernel’s USB Monitor component was found in how a user with access to the /dev/usbmon can trigger it by an incorrect write to the memory of the usbmon. This flaw allows a local user to crash or potentially escalate their privileges on the system.
In drivers/pci/hotplug/rpadlparsysfs.c in the Linux kernel through 5.11.8, the RPA PCI Hotplug driver has a user-tolerable buffer overflow when writing a new device name to the driver from userspace, allowing userspace to write data to the kernel stack frame directly. This occurs because addslotstore and removeslotstore mishandle drcname '\0' termination, aka CID-cc7a0bb058b8.
A vulnerability was found in hiddevopen in drivers/hid/usbhid/hiddev.c in USB human interface device class subsystem, in this problem if a USB device fails to initialize correctly list management code in the error handling path can delete a list entry while other USB code paths could be using it. This may lead to a use-after-free situation which is frequently used by attackers to corrupt memory, panic the system or possibly escalate privileges.
Upstream Patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6d4472d7bec39917b54e4e80245784ea5d60ce49 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9c09b214f30e3c11f9b0b03f89442df03643794d
References:
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.2.10 http://www.openwall.com/lists/oss-security/2019/12/03/4 http://seclists.org/oss-sec/2019/q4/115
Last updated 29 November 2024
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels
Some lwtunnels have a dst cache for post-transformation dst. If the packet destination did not change we may end up recording a reference to the lwtunnel in its own cache, and the lwtunnel state will never be freed.
Discovered by the ioam6.sh test, kmemleak was recently fixed to catch per-cpu memory leaks. I'm not sure if rpl and seg6 can actually hit this, but in principle I don't see why not.
In the Linux kernel, the following vulnerability has been resolved:
usb: mtu3: unmap request DMA on queue failure
mtu3gadgetqueue() maps the request before checking whether the QMU GPD ring can accept another transfer. the request is returned with -EAGAIN before it is linked on the endpoint request list if mtu3preparetransfer() fails.
Normal completion and dequeue paths unmap requests from mtu3reqcomplete(), but this error path never reaches that helper, so the DMA mapping is left active. Unmap the request before returning from the failed queue path.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0
Don't BUG/WARN on interrupt injection due to GIF being cleared, since it's trivial for userspace to force the situation via KVMSETVCPUEVENTS (even if having at least a WARN there would be correct for KVM internally generated injections).
kernel BUG at arch/x86/kvm/svm/svm.c:3386! invalid opcode: 0000 [#1] SMP CPU: 15 PID: 926 Comm: smmtest Not tainted 5.17.0-rc3+ #264 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svminjectirq+0xab/0xb0 [kvmamd] Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Call Trace: <TASK> injectpendingevent+0x2f7/0x4c0 [kvm] kvmarchvcpuioctlrun+0x791/0x17a0 [kvm] kvmvcpuioctl+0x26d/0x650 [kvm] x64sysioctl+0x82/0xb0 dosyscall64+0x3b/0xc0 entrySYSCALL64afterhwframe+0x44/0xae </TASK>
In the Linux kernel, the following vulnerability has been resolved:
Input: aiptek - properly check endpoint type
Syzbot reported warning in usbsubmiturb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint.
Fix it by replacing old desc.bNumEndpoints check with usbfindcommonendpoints() helper for finding endpoints
Fail log:
usb 5-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usbhubwq hubevent ... Call Trace: aiptekopen+0xd5/0x130 drivers/input/tablet/aiptek.c:830 inputopendevice+0x1bb/0x320 drivers/input/input.c:629 kbdconnect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593
arm64: probes: Fix uprobes for big-endian kernels
In the Linux kernel, the following vulnerability has been resolved:
powerpc/xics: fix refcount leak in icpopalinit()
The offindcompatiblenode() function returns a node pointer with refcount incremented, use ofnodeput() on it when done.
In the Linux kernel, the following vulnerability has been resolved:
usbnet: fix memory leak in error case
usbnetwritecmdasync() mixed up which buffers need to be freed in which error case.
v2: add Fixes tag v3: fix uninitialized buf pointer
In the Linux kernel, the following vulnerability has been resolved:
misc/vmwvmci: fix an infoleak in vmcihostdoreceivedatagram()
struct vmcieventqp allocated by qpnotifypeer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN:
BUG: KMSAN: kernel-infoleak in instrumentcopytouser ./include/linux/instrumented.h:121 instrumentcopytouser ./include/linux/instrumented.h:121 copytouser+0x5f/0xb0 lib/usercopy.c:33 copytouser ./include/linux/uaccess.h:169 vmcihostdoreceivedatagram drivers/misc/vmwvmci/vmcihost.c:431 vmcihostunlockedioctl+0x33d/0x43d0 drivers/misc/vmwvmci/vmcihost.c:925 vfsioctl fs/ioctl.c:51 ...
Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dgdispatchashost drivers/misc/vmwvmci/vmcidatagram.c:271 vmcidatagramdispatch+0x4f8/0xfc0 drivers/misc/vmwvmci/vmcidatagram.c:339 qpnotifypeer+0x19a/0x290 drivers/misc/vmwvmci/vmciqueuepair.c:1479 qpbrokerattach drivers/misc/vmwvmci/vmciqueuepair.c:1662 qpbrokeralloc+0x2977/0x2f30 drivers/misc/vmwvmci/vmciqueuepair.c:1750 vmciqpbrokeralloc+0x96/0xd0 drivers/misc/vmwvmci/vmciqueuepair.c:1940 vmcihostdoallocqueuepair drivers/misc/vmwvmci/vmcihost.c:488 vmcihostunlockedioctl+0x24fd/0x43d0 drivers/misc/vmwvmci/vmcihost.c:927 ...
Local variable ev created at: qpnotifypeer+0x54/0x290 drivers/misc/vmwvmci/vmciqueuepair.c:1456 qpbrokerattach drivers/misc/vmwvmci/vmciqueuepair.c:1662 qpbrokeralloc+0x2977/0x2f30 drivers/misc/vmwvmci/vmciqueuepair.c:1750
Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100
Use memset() to prevent the infoleaks.
Also speculatively fix qpnotifypeerlocal(), which may suffer from the same problem.
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid resizing to a partial cluster size
This patch avoids an attempt to resize the filesystem to an unaligned cluster boundary. An online resize to a size that is not integral to cluster size results in the last iteration attempting to grow the fs by a negative amount, which trips a BUGON and leaves the fs with a corrupted in-memory superblock.
In the Linux kernel, the following vulnerability has been resolved:
iio: sca3000: Fix a resource leak in sca3000probe()
spi->irq from requestthreadedirq() not released when iiodeviceregister() fails. Add an return value check and jump to a common error handler when iiodeviceregister() fails.
A use-after-free flaw was found in usbsgcancel in drivers/usb/core/message.c in USB core subsystem. This flaw could allow a local attacker with special user privilege (or root) to crash the system due to a race problem in scatter-gather cancellation and transfer completion in usbsgwait. This vulnerability can even lead to a kernel information leak problem .
Here usbsgcancel() does not take any reference to the transfer and there is nothing to prevent the URBs from being deallocated while the routine is trying to use them.
Taking a reference by incrementing the transfer's io->count field while the cancellation is in progress and decrementing it afterwards can be way to address this. The transfer's URBs are not deallocated until io->complete is triggered, which happens when io->count reaches zero. ~~~ BUG: KASAN: use-after-free in atomicread include/asm-generic/atomic-instrumented.h:26 [inline] BUG: KASAN: use-after-free in usbhcdunlinkurb+0x5f/0x170 drivers/usb/core/hcd.c:1607 Read of size 4 at addr ffff888065379610 by task kworker/u4:1/27 ~~~
References: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.6.8 https://lkml.org/lkml/2020/3/23/52
Upstream commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=056ad39ee9253873522f6469c3364964a322912b
A flaw was found in the way Linux kernel's KVM hypervisor handled deferred TLB flush requests from guest. A race condition may occur between guest issuing a deferred TLB flush request to KVM and KVM handling and acknowledging it. This may result in invalid address translations from TLB being used to access guest memory, leading to potential information leakage issue.
A guest user/process may use this flaw to access guest memory locations which it should not have access to.
Upstream patches: ----------------- -> https://git.kernel.org/linus/a6bd811f1209fe1c64c9f6fd578101d6436c6b6e -> https://git.kernel.org/linus/b043138246a41064527cf019a3d51d9f015e9796 -> https://git.kernel.org/linus/917248144db5d7320655dbb41d3af0b8a0f3d589 -> https://git.kernel.org/linus/1eff70a9abd46f175defafd29bc17ad456f398a7 -> https://git.kernel.org/linus/8c6de56a42e0c657955e12b882a81ef07d1d073e -> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=CVE-2019-3016
An issue was discovered in the Linux kernel before 5.0.9. There is a use-after-free in atalkprocexit, related to net/appletalk/atalkproc.c, net/appletalk/ddp.c, and net/appletalk/sysctlnetatalk.c.
An error in the "sctpmakechunk()" function (net/sctp/smmakechunk.c) when handling SCTP packets length can be exploited by a malicious local user to cause a kernel crash and a DoS.
References:
https://packetstormsecurity.com/files/146620/secunia-sctpmakechunkdos.txt
https://marc.info/?t=151818093200004&r=1&w=2
https://marc.info/?t=151818682600001&r=1&w=2
An upstream patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=07f2c7ab6f8d0a7e7c5764c4e6cc9c52951b9d9c
A flaw was discovered in the Linux kernel's USB subsystem in the usbgetextradescriptor() function in the drivers/usb/core/usb.c which mishandles a size check during the reading of an extra descriptor data. By using a specially crafted USB device which sends a forged extra descriptor, an unprivileged user with physical access to the system can potentially cause a privilege escalation or trigger a system crash or lock up and thus to cause a denial of service (DoS).
A flaw was found in the latest Linux kernel. A out-of-bounds write of kernel address space may be triggered via uncontrolled userland provided offset in ebtentry struct in netfilter/ebtables.c.
References:
https://marc.info/?l=linux-netdev&m=152023808817590&w=2
https://marc.info/?l=linux-netdev&m=152025888924151&w=2
An upsteam patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b71812168571fa55e44cdd0254471331b9c4c4c6
https://github.com/torvalds/linux/commit/b71812168571fa55e44cdd0254471331b9c4c4c6
A flaw was found in the Linux kernel present since v4.0-rc1 and through v4.13-rc4. A crafted network packet sent remotely by an attacker may force the kernel to enter an infinite loop in the cipsov4optptr() function in net/ipv4/cipsoipv4.c leading to a denial-of-service. A certain non-default configuration of LSM (Linux Security Module) and NetLabel should be set up on a system before an attacker could leverage this flaw.
Last updated 4 October 2024