The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ipvlan: Dont Use skb->sk in ipvlanprocessv{4,6}_outbound

Raw packet from PFPACKET socket ontop of an IPv6-backed ipvlan device will hit WARNONONCE() in skmcloop() through schdirect_xmit() path.

WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 skmcloop+0x2d/0x70 Modules linked in: schnetem ipvlan rfkill cirrus drmshmemhelper sg drmkmshelper CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skmcloop+0x2d/0x70 Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? _warn (kernel/panic.c:693) ? skmcloop (net/core/sock.c:760) ? reportbug (lib/bug.c:201 lib/bug.c:219) ? handlebug (arch/x86/kernel/traps.c:239) ? excinvalidop (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asmexcinvalidop (./arch/x86/include/asm/idtentry.h:621) ? skmcloop (net/core/sock.c:760) ip6finishoutput2 (net/ipv6/ip6output.c:83 (discriminator 1)) ? nfhookslow (net/netfilter/core.c:626) ip6finishoutput (net/ipv6/ip6output.c:222) ? _pfxip6finishoutput (net/ipv6/ip6output.c:215) ipvlanxmitmodel3 (drivers/net/ipvlan/ipvlancore.c:602) ipvlan ipvlanstartxmit (drivers/net/ipvlan/ipvlanmain.c:226) ipvlan devhardstartxmit (net/core/dev.c:3594) schdirectxmit (net/sched/schgeneric.c:343) _qdiscrun (net/sched/schgeneric.c:416) nettxaction (net/core/dev.c:5286) handlesoftirqs (kernel/softirq.c:555) _irqexitrcu (kernel/softirq.c:589) sysvecapictimer_interrupt (arch/x86/kernel/apic/apic.c:1043)

The warning triggers as this: packetsendmsg packetsnd //skb->sk is packet sk _devqueuexmit _devxmitskb //q->enqueue is not NULL _qdiscrun schdirectxmit devhardstartxmit ipvlanstartxmit ipvlanxmitmodel3 //l3 mode ipvlanprocessoutbound //vepa flag ipvlanprocessv6outbound ip6localout _ip6finishoutput ip6finishoutput2 //multicast packet skmcloop //sk->skfamily is AFPACKET

Call ip{6}localout() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)

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

dma-mapping: benchmark: fix node id validation

While validating node ids in mapbenchmarkioctl(), nodepossible() may be provided with invalid argument outside of [0,MAXNUMNODES-1] range leading to:

BUG: KASAN: wild-memory-access in mapbenchmarkioctl (kernel/dma/mapbenchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dmamapbenchma/971 CPU: 7 PID: 971 Comm: dmamapbenchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:117) kasanreport (mm/kasan/report.c:603) kasancheckrange (mm/kasan/generic.c:189) variabletestbit (arch/x86/include/asm/bitops.h:227) [inline] archtestbit (arch/x86/include/asm/bitops.h:239) [inline] _testbit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] nodestate (include/linux/nodemask.h:423) [inline] mapbenchmarkioctl (kernel/dma/mapbenchmark.c:214) fullproxyunlockedioctl (fs/debugfs/file.c:333) _x64sysioctl (fs/ioctl.c:890) dosyscall64 (arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:130)

Compare node ids with sane bounds first. NUMANONODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node.

Found by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)

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

RDMA/rxe: Fix seg fault in rxecompqueue_pkt

In rxecompqueuepkt() an incoming response packet skb is enqueued to the resppkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale.

This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.(CVE-2024-38544)

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

wifi: ar5523: enable proper endpoint verification

Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it.

Fix the issue by checking for the existence of all proper endpoints with their according types intact.

Sadly, this patch has not been tested on real hardware.

[1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usbsubmiturb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523cmdread drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523hostavailable drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usbprobeinterface+0x30f/0x7f0 drivers/usb/core/driver.c:396 calldriverprobe drivers/base/dd.c:560 [inline] reallyprobe+0x249/0xb90 drivers/base/dd.c:639 _driverprobedevice+0x1df/0x4d0 drivers/base/dd.c:778 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:808 _deviceattachdriver+0x1d4/0x2e0 drivers/base/dd.c:936 busforeachdrv+0x163/0x1e0 drivers/base/bus.c:427 _deviceattach+0x1e4/0x530 drivers/base/dd.c:1008 busprobedevice+0x1e8/0x2a0 drivers/base/bus.c:487 deviceadd+0xbd9/0x1e90 drivers/base/core.c:3517 usbsetconfiguration+0x101d/0x1900 drivers/usb/core/message.c:2170 usbgenericdriverprobe+0xbe/0x100 drivers/usb/core/generic.c:238 usbprobedevice+0xd8/0x2c0 drivers/usb/core/driver.c:293 calldriverprobe drivers/base/dd.c:560 [inline] reallyprobe+0x249/0xb90 drivers/base/dd.c:639 _driverprobedevice+0x1df/0x4d0 drivers/base/dd.c:778 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:808 _deviceattachdriver+0x1d4/0x2e0 drivers/base/dd.c:936 busforeachdrv+0x163/0x1e0 drivers/base/bus.c:427 _deviceattach+0x1e4/0x530 drivers/base/dd.c:1008 busprobedevice+0x1e8/0x2a0 drivers/base/bus.c:487 deviceadd+0xbd9/0x1e90 drivers/base/core.c:3517 usbnewdevice.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hubportconnect drivers/usb/core/hub.c:5353 [inline] hubportconnectchange drivers/usb/core/hub.c:5497 [inline] portevent drivers/usb/core/hub.c:5653 [inline] hubevent+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 processonework+0x9bf/0x1710 kernel/workqueue.c:2289 workerthread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306 </TASK>(CVE-2024-38565)

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

eth: sungem: remove .ndopollcontroller to avoid deadlocks

Erhard reports netpoll warnings from sungem:

netpollsendskbondev(): eth0 enabled interrupts in poll (gemstartxmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpollsendskb+0x1fc/0x20c

gempollcontroller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gempollcontroller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.(CVE-2024-38597)

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

ext4: fix mbcacheentry's erefcnt leak in ext4xattrblockcache_find()

Syzbot reports a warning as follows:

============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mbcachedestroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mbcachedestroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4putsuper+0x6d4/0xcd0 fs/ext4/super.c:1375 genericshutdownsuper+0x136/0x2d0 fs/super.c:641 killblocksuper+0x44/0x90 fs/super.c:1675 ext4killsb+0x68/0xa0 fs/ext4/super.c:7327

[...]

This is because when finding an entry in ext4xattrblockcachefind(), if ext4sbbread() returns -ENOMEM, the ce's erefcnt, which has already grown in the _entryfind(), won't be put away, and eventually trigger the above issue in mbcache_destroy() due to reference count leakage.

So call mbcacheentry_put() on the -ENOMEM error branch as a quick fix.(CVE-2024-39276)

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

md/raid5: fix deadlock that raid5d() wait for itself to clear MDSBCHANGE_PENDING

Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MDSBCHANGE_PENDING in raid5d"")

However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d().

Current implementation in raid5d() has a weird dependence:

1) mdcheckrecovery() from raid5d() must hold 'reconfigmutex' to clear MDSBCHANGEPENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MDSBCHANGE_PENDING to be cleared;

This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfigmutex', and mdcheckrecovery() can't update superblock, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released.

Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MDSBCHANGEPENDING is still set after mdcheckrecovery(), daemon thread will be woken up when 'reconfigmutex' is released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)

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

jfs: xattr: fix buffer overflow for invalid xattr

When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer.

Fix this all up by properly restricting the size of the debug hex dump in the kernel log.(CVE-2024-40902)

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

iommu: Return right value in iommusvabind_device()

iommusvabinddevice() should return either a sva bond handle or an ERRPTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer.

In reality, this doesn't cause any problems because iommusvabinddevice() only returns NULL when the kernel is not configured with CONFIGIOMMUSVA. In this case, iommudevenablefeature(dev, IOMMUDEVFEATSVA) will return an error, and the device drivers won't call iommusvabinddevice() at all.(CVE-2024-40945)

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

tty: add the option to have a tty reject a new ldisc

... and use it to limit the virtual terminals to just NTTY. They are kind of special, and in particular, the "conwrite()" routine violates the "writes cannot sleep" rule that some ldiscs rely on.

This avoids the

BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659

when NGSM has been attached to a virtual console, and gsmldwrite() calls conwrite() while holding a spinlock, and conwrite() then tries to get the console lock.(CVE-2024-40966)

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

can: mcp251xfd: fix infinite loop when xmit fails

When the mcp251xfdstartxmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application.

Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfdstartxmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, teftail=0x000017cf, tefhead=0x000017d0, tx_head=0x000017d3). ... and repeat forever.

The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus.

The problem occurs because txring->head increments even if mcp251xfdstartxmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfdhandletefifone().

Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message.

mkl: use more imperative wording in patch description

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

netfilter: nftables: fully validate NFTDATA_VALUE on store to data registers

register store validation for NFTDATAVALUE is conditional, however, the datatype is always either NFTDATAVALUE or NFTDATAVERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers.(CVE-2024-42070)

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

drm/lima: fix shared irq handling on driver remove

lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIGDEBUGSHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.(CVE-2024-42127)

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

mm: avoid overflows in dirty throttling logic

The dirty throttling logic is interspersed with assumptions that dirty limits in PAGESIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirtybytes / dirtybackgroundbytes interfaces we can just refuse to set so large limits. For dirtyratio / dirtybackgroundratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINTMAX.

This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB.(CVE-2024-42131)

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

libceph: fix race between delayedwork() and cephmonc_stop()

The way the delayed work is handled in cephmoncstop() is prone to races with monfault() and possibly also finishhunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after canceldelayedworksync() runs -- _closesession() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in monfault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.

To fix this:

• clear monc->curmon and monc->hunting as part of closing the session in cephmonc_stop()
• bail from delayedwork() if monc->curmon is cleared, similar to how it's done in monfault() and finishhunting() (based on monc->hunting)
• call canceldelayedwork_sync() after the session is closed(CVE-2024-42232)

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

usb: gadget: configfs: Prevent OOB read/write in usbstringcopy()

Userspace provided string 's' could trivially have the length zero. Left unchecked this will firstly result in an OOB read in the form if (str[0 - 1] == '\n') followed closely by an OOB write in the form str[0 - 1] = '\0'`.

There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short.(CVE-2024-42236)

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

ext4: make sure the first directory block is not a hole

The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow.

ext4_mknod
 ...
  ext4_add_entry
    // Read block 0
    ext4_read_dirblock(dir, block, DIRENT)
      bh = ext4_bread(NULL, inode, block, 0)
      if (!bh && (type == INDEX || type == DIRENT_HTREE))
      // The first directory block is a hole
      // But type == DIRENT, so no error is reported.

After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as makeindexeddir()) to crash.

Therefore when ext4readdirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad.(CVE-2024-42304)

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

drm/gma500: fix null pointer dereference in cdvintellvdsgetmodes

In cdvintellvdsgetmodes(), the return value of drmmodeduplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drmmodeduplicate(). Add a check to avoid npd.(CVE-2024-42310)

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

bna: adjust 'name' buf size of bnatcb and bnaccb structures

To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there.

For '%d' specifiers, assume that they require: * 1 char for 'txid + txinfo->tcb[i]->id' sum, BNADMAXTXQPERTX is 8 * 2 chars for 'rxid + rxinfo->rxctrl[i].ccb->id', BNADMAXRXPPER_RX is 16

And replace sprintf with snprintf.

Detected using the static analysis tool - Svace.(CVE-2024-43839)