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

ipv4: fib: free fibalias with kfreercu() on insert error path

fibtableinsert() publishes newfa into the leaf's falist with fibinsertalias() before calling the fib entry notifiers. When a notifier fails, the error path removes newfa with fibremovealias() (hlistdelrcu) and frees it right away with kmemcachefree().

fibtablelookup() walks that list under rcureadlock() only, so a concurrent lookup that already reached newfa keeps reading it after the free:

BUG: KASAN: slab-use-after-free in fibtablelookup (net/ipv4/fibtrie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fibtablelookup (net/ipv4/fibtrie.c:1601) iprouteoutputkeyhashrcu (net/ipv4/route.c:2814) iprouteoutputkeyhash (net/ipv4/route.c:2705) ip4datagramconnect (net/ipv4/datagram.c:49) udpconnect (net/ipv4/udp.c:2144) sysconnect (net/socket.c:2167) x64sysconnect (net/socket.c:2173) dosyscall64 entrySYSCALL64afterhwframe which belongs to the cache ipfibalias of size 56

Triggering the error path needs CAPNETADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough.

Free newfa with aliasfreememrcu(), as fibtabledelete() already does for a fibalias removed from the trie.

Bluetooth: qca: fix NVM tag length underflow in TLV parser

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

x86/bugs: Enable IBPB flush on BPF JIT allocation

Enable hardening against JIT spraying when Spectre-v2 mitigations are in use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip enabling the IBPB flush if the BPF dispatcher is already using a retpoline sequence.

This hardening applies only when BPF-JIT is in use. Guard the enabling under CONFIGBPFJIT so that bugs.c still builds with CONFIGBPFJIT=n.

futex: Prevent lockup in requeue-PI during signal/ timeout wakeup

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

net: qrtr: ns: Limit the maximum server registration per node

Current code does no bound checking on the number of servers added per node. A malicious client can flood NEWSERVER messages and exhaust memory.

Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEWSERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtrnsworker().

Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.

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

.NET Information Disclosure Vulnerability

.NET Security Feature Bypass Vulnerability

.NET Spoofing Vulnerability

Azure Service Fabric for Linux Remote Code Execution Vulnerability

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

scsi: core: Wake up the error handler when final completions race against each other

The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.

First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.

This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.

Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.

This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.

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

net: atm: fix crash due to unvalidated vcc pointer in sigdsend()

Reproducer available at [1].

The ATM send path (sendmsg -> vccsendmsg -> sigdsend) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged:

int fd = socket(AFATMSVC, SOCKDGRAM, 0); ioctl(fd, ATMSIGDCTRL); // become ATM signaling daemon struct msghdr msg = { .msgiov = &iov, ... }; (unsigned long )(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef

In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigdenq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values.

Fix this by introducing findgetvcc() which validates the pointer by searching through vcchash (similar to how sigdclose() iterates over all VCCs), and acquires a reference via sockhold() if found.

Since struct atmvcc embeds struct sock as its first member, they share the same lifetime. Therefore using sockhold/sockput is sufficient to keep the vcc alive while it is being used.

Note that there may be a race with sigdclose() which could mark the vcc with various flags (e.g., ATMVFRELEASED) after findgetvcc() returns. However, sockhold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety.

[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

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

net: atm: fix crash due to unvalidated vcc pointer in sigdsend()

Reproducer available at [1].

The ATM send path (sendmsg -> vccsendmsg -> sigdsend) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged:

int fd = socket(AFATMSVC, SOCKDGRAM, 0); ioctl(fd, ATMSIGDCTRL); // become ATM signaling daemon struct msghdr msg = { .msgiov = &iov, ... }; (unsigned long )(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef

In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigdenq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values.

Fix this by introducing findgetvcc() which validates the pointer by searching through vcchash (similar to how sigdclose() iterates over all VCCs), and acquires a reference via sockhold() if found.

Since struct atmvcc embeds struct sock as its first member, they share the same lifetime. Therefore using sockhold/sockput is sufficient to keep the vcc alive while it is being used.

Note that there may be a race with sigdclose() which could mark the vcc with various flags (e.g., ATMVFRELEASED) after findgetvcc() returns. However, sockhold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety.

[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

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

nbd: fix incomplete validation of ioctl arg

We tested and found an alarm caused by nbdioctl arg without verification. The UBSAN warning calltrace like below:

UBSAN: Undefined behaviour in fs/buffer.c:1709:35 signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long long int' CPU: 3 PID: 2523 Comm: syz-executor.0 Not tainted 4.19.90 #1 Hardware name: linux,dummy-virt (DT) Call trace: dumpbacktrace+0x0/0x3f0 arch/arm64/kernel/time.c:78 showstack+0x28/0x38 arch/arm64/kernel/traps.c:158 dumpstack lib/dumpstack.c:77 [inline] dumpstack+0x170/0x1dc lib/dumpstack.c:118 ubsanepilogue+0x18/0xb4 lib/ubsan.c:161 handleoverflow+0x188/0x1dc lib/ubsan.c:192 ubsanhandlesuboverflow+0x34/0x44 lib/ubsan.c:206 blockwritefullpage+0x94c/0xa20 fs/buffer.c:1709 blockwritefullpage+0x1f0/0x280 fs/buffer.c:2934 blkdevwritepage+0x34/0x40 fs/blockdev.c:607 writepage+0x68/0xe8 mm/page-writeback.c:2305 writecachepages+0x44c/0xc70 mm/page-writeback.c:2240 genericwritepages+0xdc/0x148 mm/page-writeback.c:2329 blkdevwritepages+0x2c/0x38 fs/blockdev.c:2114 dowritepages+0xd4/0x250 mm/page-writeback.c:2344

The reason for triggering this warning is blockwritefullpage() - isizeread(inode) - 1 overflow. inode-isize is assigned in nbdioctl() - nbdsetsize() - bytesize. We think it is necessary to limit the size of arg to prevent errors.

Moreover, nbdioctl() - nbdaddsocket(), arg will be cast to int. Assuming the value of arg is 0x80000000000000001) (on a 64-bit machine), it will become 1 after the coercion, which will return unexpected results.

Fix it by adding checks to prevent passing in too large numbers.

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

ACPI: LPIT: Avoid u32 multiplication overflow

In lpitupdateresidency() there is a possibility of overflow in multiplication, if tsckhz is large enough (> UINTMAX/1000).

Change multiplication to mulu32u32().

Found by Linux Verification Center (linuxtesting.org) with SVACE.

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

calipso: fix memory leak in netlblcalipsoaddpass()

If IPv6 support is disabled at boot (ipv6.disable=1), the calipsoinit() -> netlblcalipsoopsregister() function isn't called, and the netlblcalipsoopsget() function always returns NULL. In this case, the netlblcalipsoaddpass() function allocates memory for the doidef variable but doesn't free it with the calipsodoifree().

BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlblcalipsoaddpass net/netlabel/netlabelcalipso.c:76 [inline] [<...>] netlblcalipsoadd+0x22e/0x4f0 net/netlabel/netlabelcalipso.c:111 [<...>] genlfamilyrcvmsgdoit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genlfamilyrcvmsg net/netlink/genetlink.c:783 [inline] [<...>] genlrcvmsg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlinkrcvskb+0x14d/0x440 net/netlink/afnetlink.c:2515 [<...>] genlrcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlinkunicastkernel net/netlink/afnetlink.c:1313 [inline] [<...>] netlinkunicast+0x54b/0x800 net/netlink/afnetlink.c:1339 [<...>] netlinksendmsg+0x90a/0xdf0 net/netlink/afnetlink.c:1934 [<...>] socksendmsgnosec net/socket.c:651 [inline] [<...>] socksendmsg+0x157/0x190 net/socket.c:671 [<...>] syssendmsg+0x712/0x870 net/socket.c:2342 [<...>] syssendmsg+0xf8/0x170 net/socket.c:2396 [<...>] syssendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] dosyscall64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entrySYSCALL64afterhwframe+0x61/0xc6

Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller

[PM: merged via the LSM tree at Jakub Kicinski request]

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

Bluetooth: l2cap: fix null-ptr-deref in l2capchantimeout

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051300-CVE-2024-27399-afa8@gregkh/T

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

powerpc/pseries: Fix potential memleak in paprgetattr()

buf is allocated in paprgetattr(), and krealloc() of buf could fail. We need to free the original buf in the case of failure.

An authentication bypass vulnerability in the network driver of Palo Alto Networks Prisma® Access Agent on Windows enables a local administrator to bypass security inspection, subsequently allowing them to inject and intercept arbitrary network traffic.

The Prisma Access Agent on Linux, macOS, iOS, Android, and Chrome OS is not affected.

An improper link resolution before file access vulnerability exists in the Palo Alto Networks Prisma® Access Agent on Linux platforms that enables a local low privileged user to delete system files in a limited scope and disable Prisma Access Agent.

The Prisma Access Agent on macOS, Windows, iOS, Android, and Chrome OS is not affected.

IBM Tivoli System Automation Application Manager 4.1 and IBM WebSphere Application Server is affected by cross-site scripting in the Administrative Console.

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

net/mlx5e: Prevent deadlock while disabling aRFS

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050149-CVE-2024-27014-d2dc@gregkh/T

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

ksmbd: fix SID memory leak in setposixaclentriesdacl() on overflow

Commit 299f962c0b02 ("ksmbd: use checkaddoverflow() to prevent u16 DACL size overflow") added checkaddoverflow() guards that break out of the ACE-building loops in setposixaclentriesdacl() when the accumulated DACL size would wrap past 65535.

However, each iteration allocates a struct smbsid via kmallocobj() at the top of the loop and relies on the kfree(sid) call at the end of the loop body (the 'passsamesid' label in the first loop, and the explicit kfree at the tail of the second loop) to release it. The newly introduced 'break' statements bypass those kfree() calls, leaking the sid buffer every time an overflow is detected.

A malicious or malformed file with enough POSIX ACL entries to trip the overflow check will leak one or more struct smbsid allocations on every request that touches the file's DACL, providing a trivial kernel memory exhaustion vector.

Free sid before breaking out of the loops to plug the leak.

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

KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O

When completing emulation of instruction that generated a userspace exit for I/O, don't recheck L1 intercepts as KVM has already finished that phase of instruction execution, i.e. has already committed to allowing L2 to perform I/O. If L1 (or host userspace) modifies the I/O permission bitmaps during the exit to userspace, KVM will treat the access as being intercepted despite already having emulated the I/O access.

Pivot on EMULTYPENODECODE to detect that KVM is completing emulation. Of the three users of EMULTYPENODECODE, only completeemulatedio() (the intended "recipient") can reach the code in question. gpinterception()'s use is mutually exclusive with isguestmode(), and completeemulatedinsngp() unconditionally pairs EMULTYPENODECODE with EMULTYPESKIP.

The bad behavior was detected by a syzkaller program that toggles port I/O interception during the userspace I/O exit, ultimately resulting in a WARN on vcpu->arch.pio.count being non-zero due to KVM no completing emulation of the I/O instruction.

WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulatorpioinout+0x154/0x170 [kvm] Modules linked in: kvmintel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulatorpioinout+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: <TASK> kvmfastpio+0xd6/0x1d0 [kvm] vmxhandleexit+0x149/0x610 [kvmintel] kvmarchvcpuioctlrun+0xda8/0x1ac0 [kvm] kvmvcpuioctl+0x244/0x8c0 [kvm] x64sysioctl+0x8a/0xd0 dosyscall64+0x5d/0xc60 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK>

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

net: veth: clear GRO when clearing XDP even when down

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040404-CVE-2024-26803-9985@gregkh/T

gfs2: Fix kernel NULL pointer dereference in gfs2rgrpdump

Syzkaller has reported a NULL pointer dereference when accessing rgd->rdrgl in gfs2rgrpdump(). This can happen when creatingrgd->rdgl fails in readrindexentry(). Add a NULL pointer check in gfs2rgrpdump() to prevent that.

gfs2: Fix kernel NULL pointer dereference in gfs2rgrpdump

Syzkaller has reported a NULL pointer dereference when accessing rgd->rdrgl in gfs2rgrpdump(). This can happen when creatingrgd->rdgl fails in readrindexentry(). Add a NULL pointer check in gfs2rgrpdump() to prevent that.

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

platform/x86: uniwill-laptop: Do not enable the charging limit even when forced

It seems that on some older models (~2020) the battery charging limit can permanently damage the battery. Prevent users from enabling this feature thru the "force" module parameter to avoid causing permanent hardware damage on such devices.

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

Bluetooth: btmtk: fix urb->setuppacket leak in error paths

The setuppacket of control urb is not freed if usbsubmiturb fails or the submitted urb is killed. Add free in these two paths.

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

erofs: fix metabuf leak in inode xattr initialization

commit bb88e8da0025 ("erofs: use meta buffers for xattr operations") converted xattr operations to use on-stack erofsbuf instances. erofsinitinodexattrs() uses such a metabuf while reading the inline xattr header and shared xattr id array.

Some error paths after erofsreadmetabuf() leave through outunlock without dropping the metabuf, so the folio reference can leak.

Consolidate the cleanup at outunlock. erofsputmetabuf() is a no-op if no folio has been acquired, and this keeps all paths after taking EROFSIBLXATTRBIT covered by a single cleanup site.