A use-after-free vulnerability was found in the cxgb4 driver in the Linux kernel. The bug occurs when the cxgb4 device is detaching due to a possible rearming of the flowerstatstimer from the work queue. This flaw allows a local user to crash the system, causing a denial of service condition.

A flaw was found in the Netfilter subsystem in the Linux kernel. The sctpmtcheck did not validate the flagcount field. This flaw allows a local privileged (CAPNETADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.

A flaw was found in ipv4senddestunreach() due to NULL pointer derefence due to a missing edge-case check.

A segment fault (SEGV) flaw was found in libtiff that could be triggered by passing a crafted tiff file to the TIFFReadRGBATileExt() API. This flaw allows a remote attacker to cause a heap-buffer overflow, leading to a denial of service.

A null pointer dereference flaw was found in the Linux kernel API for the cryptographic algorithm scatterwalk functionality. This issue occurs when a user constructs a malicious packet with specific socket configuration, which could allow a local user to crash the system or escalate their privileges on the system.

A use-after-free flaw was found in vcsread in drivers/tty/vt/vcscreen.c in vcscreen in the Linux Kernel. In this flaw an attacker with local user access may ead to a system crash or a leak of internal kernel information.

Reference: https://www.spinics.net/lists/stable-commits/msg285184.html

A flaw was found in the XFRM subsystem in the Linux kernel. The specific flaw exists within the processing of state filters, which can result in a read past the end of an allocated buffer. This flaw allows a local privileged (CAPNETADMIN) attacker to trigger an out-of-bounds read, potentially leading to an information disclosure.

A flaw was found in the Netfilter subsystem in the Linux kernel. The xtu32 module did not validate the fields in the xtu32 structure. This flaw allows a local privileged attacker to trigger an out-of-bounds read by setting the size fields with a value beyond the array boundaries, leading to a crash or information disclosure.

A flaw was found in the Netfilter subsystem in the Linux kernel. The nfnlosfaddcallback function did not validate the user mode controlled optnum field. This flaw allows a local privileged (CAPNETADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.

A vulnerability was found in vhostnewmsg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhostnewmsg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file.

An issue was found in the tiffcp utility distributed by the libtiff package where a crafted TIFF file on processing may cause a heap-based buffer overflow leads to an application crash.

A race condition leading to a use-after-free issue was found in the QXL driver in the Linux kernel.

A flaw was found in KVM. An improper check in svmsetx2apicmsrinterception() may allow direct access to host x2apic msrs when the guest resets its apic, potentially leading to a denial of service condition.

A flaw was found in rsvpchange(). The root cause is an slab-out-of-bound access, but since the offset to the original pointer is an unsign int fully controlled by users, the behavior is usually a wild pointer access.

An out-of-bounds read issue was found in the NVMe-oF/TCP subsystem in the Linux kernel. A remote attacker could send a crafted TCP packet triggering a heap-based buffer overflow that results in kmalloc data to be printed (and potentially leaked) to the kernel ring buffer (dmesg).

Upstream refs: https://lore.kernel.org/linux-nvme/b58a2dc6-cc8f-4d19-9efe-e1d5b4505efc@nvidia.com/T/ https://lore.kernel.org/linux-nvme/CAK5usQvxAyC3LJ4OnqerS1P0JpbfFr9uRZmq6Jb4QhaB7AQCoQ@mail.gmail.com/T/

A Null pointer de-reference problem was found in idafree in lib/idr.c file when it calls the xasload function and returns a null value, assigning NULL to the bitmap variable.

Therefore, if (xaisvalue(bitmap)) will fail and jump to the else branch. However, in the else branch, the statement if (!testbit(bit, bitmap->bitmap)) references the member of bitmap, which triggers a null pointer dereference vulnerability.

Reference: https://github.com/torvalds/linux/commit/af73483f4e8b6f5c68c9aa63257bdd929a9c194a

A null pointer dereference vulnerability was found in nftdynsetinit() in net/netfilter/nftdynset.c in nftables in the Linux kernel. This issue may allow a local attacker with CAPNETADMIN user privilege to trigger a denial of service.

In the Linux kernel, the following vulnerability has been resolved:

net: do not leave a dangling sk pointer, when socket creation fails

It is possible to trigger a use-after-free by: attaching an fentry probe to sockrelease() and the probe calling the bpfgetsocketcookie() helper running traceroute -I 1.1.1.1 on a freshly booted VM

A KASAN enabled kernel will log something like below (decoded and stripped): ================================================================== BUG: KASAN: slab-use-after-free in sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) Read of size 8 at addr ffff888007110dd8 by task traceroute/299

CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: dumpstacklvl (lib/dumpstack.c:117 (discriminator 1)) printreport (mm/kasan/report.c:378 mm/kasan/report.c:488) ? sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) kasanreport (mm/kasan/report.c:603) ? sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) kasancheckrange (mm/kasan/generic.c:183 mm/kasan/generic.c:189) sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) bpfgetsocketptrcookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sockdiag.h:42 net/core/filter.c:5094 net/core/filter.c:5092) bpfprog875642cf11f1d139sockrelease+0x6e/0x8e bpftrampoline6442506592+0x47/0xaf sockrelease (net/socket.c:652) sockcreate (net/socket.c:1601) ... Allocated by task 299 on cpu 2 at 78.328492s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) kasanslaballoc (mm/kasan/common.c:312 mm/kasan/common.c:338) kmemcacheallocnoprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007) skprotalloc (net/core/sock.c:2075) skalloc (net/core/sock.c:2134) inetcreate (net/ipv4/afinet.c:327 net/ipv4/afinet.c:252) sockcreate (net/socket.c:1572) syssocket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) x64syssocket (net/socket.c:1718) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Freed by task 299 on cpu 2 at 78.328502s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) kasansavefreeinfo (mm/kasan/generic.c:582) poisonslabobject (mm/kasan/common.c:242) kasanslabfree (mm/kasan/common.c:256) kmemcachefree (mm/slub.c:4437 mm/slub.c:4511) skdestruct (net/core/sock.c:2117 net/core/sock.c:2208) inetcreate (net/ipv4/afinet.c:397 net/ipv4/afinet.c:252) sockcreate (net/socket.c:1572) syssocket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) x64syssocket (net/socket.c:1718) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Fix this by clearing the struct socket reference in skcommonrelease() to cover all protocol families create functions, which may already attached the reference to the sk object with sockinitdata().

In the Linux kernel, the following vulnerability has been resolved:

drivers: core: synchronize reallyprobe() and devuevent()

Synchronize the dev->driver usage in reallyprobe() and devuevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization:

Thread #1: ==========

reallyprobe() { ... probefailed: ... deviceunbindcleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... }

Thread #2: ==========

devuevent() { ... if (dev->driver) // If dev->driver is NULLed from reallyprobe() from here on, // after above check, the system crashes addueventvar(env, "DRIVER=%s", dev->driver->name); ... }

reallyprobe() holds the lock, already. So nothing needs to be done there. devuevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in devuevent() itself. So fix this race by adding the lock to the non-protected path. This is the path where above race is observed:

devuevent+0x235/0x380 ueventshow+0x10c/0x1f0 <= Add lock here devattrshow+0x3a/0xa0 sysfskfseqshow+0x17c/0x250 kernfsseqshow+0x7c/0x90 seqreaditer+0x2d7/0x940 kernfsfopreaditer+0xc6/0x310 vfsread+0x5bc/0x6b0 ksysread+0xeb/0x1b0 x64sysread+0x42/0x50 x64syscall+0x27ad/0x2d30 dosyscall64+0xcd/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f

Similar cases are reported by syzkaller in

https://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a

But these are regarding the initialization of dev->driver

dev->driver = drv;

As this switches dev->driver to non-NULL these reports can be considered to be false-positives (which should be "fixed" by this commit, as well, though).

The same issue was reported and tried to be fixed back in 2015 in

https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/

already.

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: Avoid address calculations via out of bounds array indexing

req->nchannels must be set before req->channels[] can be used.

This patch fixes one of the issues encountered in [1].

[ 83.964255] UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:364:4 [ 83.964258] index 0 is out of range for type 'struct ieee80211channel []' [...] [ 83.964264] Call Trace: [ 83.964267] <TASK> [ 83.964269] dumpstacklvl+0x3f/0xc0 [ 83.964274] ubsanhandleoutofbounds+0xec/0x110 [ 83.964278] ieee80211prephwscan+0x2db/0x4b0 [ 83.964281] ieee80211startscan+0x601/0x990 [ 83.964291] nl80211triggerscan+0x874/0x980 [ 83.964295] genlfamilyrcvmsgdoit+0xe8/0x160 [ 83.964298] genlrcvmsg+0x240/0x270 [...]

[1] https://bugzilla.kernel.org/showbug.cgi?id=218810

In the Linux kernel, the following vulnerability has been resolved:

mm/writeback: fix possible divide-by-zero in wbdirtylimits(), again

The Linux kernel CVE team has assigned CVE-2024-26720 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040344-CVE-2024-26720-06fa@gregkh/T

A flaw was found in unrestricted eBPF usage by the BPFBTFLOAD, leading to a possible out-of-bounds memory write in the Linux kernel’s BPF subsystem due to the way a user loads BTF. This flaw allows a local user to crash or escalate their privileges on the system.

In kernel/bpf/verifier.c , there is a possible way to manipulate pointer arithmetic due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

A race problem was seen in the vtkioctl in drivers/tty/vt/vtioctl.c in the Linux kernel, which may cause an out of bounds read in vt as the write access to vcmode is not protected by lock-in vtioctl (KDSETMDE). The highest threat from this vulnerability is to data confidentiality.

Android contains an unspecified vulnerability in the kernel that allows for remote code execution. This vulnerability resides in Linux Kernel and could impact other products, including but not limited to Android OS.

In multiqtune of schmultiq.c, there is a possible out of bounds write due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Fix out of bounds reads when finding clock sources

The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads.

For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop.

For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.

An out of bounds write exists in FreeType versions 2.13.0 and below (newer versions of FreeType are not vulnerable) when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild.

A flaw was found in Linux Kernel, where a race in KDGKBSENT and KDSKBSENT leads to use-after-free read in vtdokdgkbioctl

References: https://groups.google.com/g/syzkaller-bugs/c/kZsmxkpq3UI/m/J35PFexWBgAJ?pli=1

A vulnerability was found in Linux Kernel, where Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack. When an attacker connects to a victim device using the address of the device and the victim initiates a Pairing, the attacker can reflect the encrypted nonce even without knowledge of the key.