The Linux Kernel, the operating system core itself.

Security Fix(es):

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

parisc: Fix data TLB miss in sbaunmapsg

Rolf Eike Beer reported the following bug:

[1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018 [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4 [1274934.746891] Hardware name: 9000/785/C8000 [1274934.746891] [1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [1274934.746891] PSW: 00001000000001001111111000001110 Not tainted [1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000 [1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001 [1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001 [1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0 [1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007 [1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001 [1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0 [1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118 [1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800 [1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [1274934.746891] [1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec [1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018 [1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff [1274934.746891] ORIGR28: 0000000040acdd58 [1274934.746891] RP(r2): sbaunmapsg+0xac/0x118 [1274934.746891] Backtrace: [1274934.746891] [<00000000402740cc>] dmaunmapsgattrs+0x6c/0x70 [1274934.746891] [<000000004074d6bc>] scsidmaunmap+0x54/0x60 [1274934.746891] [<00000000407a3488>] mptscsihiodone+0x150/0xd70 [1274934.746891] [<0000000040798600>] mptinterrupt+0x168/0xa68 [1274934.746891] [<0000000040255a48>] _handleirqeventpercpu+0xc8/0x278 [1274934.746891] [<0000000040255c34>] handleirqeventpercpu+0x3c/0xd8 [1274934.746891] [<000000004025ecb4>] handlepercpuirq+0xb4/0xf0 [1274934.746891] [<00000000402548e0>] generichandleirq+0x50/0x70 [1274934.746891] [<000000004019a254>] callonstack+0x18/0x24 [1274934.746891] [1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)

The bug is caused by overrunning the sglist and incorrectly testing sgdmalen(sglist) before nents. Normally this doesn't cause a crash, but in this case sglist crossed a page boundary. This occurs in the following code:

while (sg_dma_len(sglist) && nents--) {

The fix is simply to test nents first and move the decrement of nents into the loop.(CVE-2022-48795)

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

drm/virtio: Fix GEM handle creation UAF

Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done after we are done dereferencing the object.(CVE-2022-48899)

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

thermal: int340x: fix memory leak in int3400_notify()

It is easy to hit the below memory leaks in my TigerLake platform:

unreferenced object 0xffff927c8b91dbc0 (size 32): comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s) hex dump (first 32 bytes): 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk. backtrace: [<ffffffff9c502c3e>] _kmalloctrackcaller+0x2fe/0x4a0 [<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0 [<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70 [<ffffffffc04cb662>] int3400notify+0x82/0x120 [int3400thermal] [<ffffffff9c8b7358>] acpievnotifydispatch+0x54/0x71 [<ffffffff9c88f1a7>] acpiosexecutedeferred+0x17/0x30 [<ffffffff9c2c2c0a>] processonework+0x21a/0x3f0 [<ffffffff9c2c2e2a>] workerthread+0x4a/0x3b0 [<ffffffff9c2cb4dd>] kthread+0xfd/0x130 [<ffffffff9c201c1f>] retfromfork+0x1f/0x30

Fix it by calling kfree() accordingly.(CVE-2022-48924)

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

iio: adc: menz188adc: Fix a resource leak in an error handling path

If iiodeviceregister() fails, a previous ioremap() is left unbalanced.

Update the error handling path and add the missing iounmap() call, as already done in the remove function.(CVE-2022-48928)

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

KVM: x86/mmu: make apf token non-zero to fix bug

In current async pagefault logic, when a page is ready, KVM relies on kvmarchcandequeueasyncpagepresent() to determine whether to deliver a READY event to the Guest. This function test token value of struct kvmvcpupvapfdata, which must be reset to zero by Guest kernel when a READY event is finished by Guest. If value is zero meaning that a READY event is done, so the KVM can deliver another. But the kvmarchsetupasyncpf() may produce a valid token with zero value, which is confused with previous mention and may lead the loss of this READY event.

This bug may cause task blocked forever in Guest: INFO: task stress:7532 blocked for more than 1254 seconds. Not tainted 5.10.0 #16 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:stress state:D stack: 0 pid: 7532 ppid: 1409 flags:0x00000080 Call Trace: _schedule+0x1e7/0x650 schedule+0x46/0xb0 kvmasyncpftaskwaitschedule+0xad/0xe0 ? exittousermodeprepare+0x60/0x70 _kvmhandleasyncpf+0x4f/0xb0 ? asmexcpagefault+0x8/0x30 excpagefault+0x6f/0x110 ? asmexcpagefault+0x8/0x30 asmexcpagefault+0x1e/0x30 RIP: 0033:0x402d00 RSP: 002b:00007ffd31912500 EFLAGS: 00010206 RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0 RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0 RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086 R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000 R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000(CVE-2022-48943)

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

gsmi: fix null-deref in gsmigetvariable

We can get EFI variables without fetching the attribute, so we must allow for that in gsmi.

commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi.(CVE-2023-52893)

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

xhci: Fix null pointer dereference when host dies

Make sure xhcifreedev() and xhcikillendpoint_urbs() do not race and cause null pointer dereference when host suddenly dies.

Usb core may call xhcifreedev() which frees the xhci->devs[slotid] virt device at the same time that xhcikillendpointurbs() tries to loop through all the device's endpoints, checking if there are any cancelled urbs left to give back.

hold the xhci spinlock while freeing the virt device(CVE-2023-52898)

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

nilfs2: fix general protection fault in nilfsbtreeinsert()

If nilfs2 reads a corrupted disk image and tries to reads a b-tree node block by calling _nilfsbtreegetblock() against an invalid virtual block address, it returns -ENOENT because conversion of the virtual block address to a disk block address fails. However, this return value is the same as the internal code that b-tree lookup routines return to indicate that the block being searched does not exist, so functions that operate on that b-tree may misbehave.

When nilfsbtreeinsert() receives this spurious 'not found' code from nilfsbtreedo_lookup(), it misunderstands that the 'not found' check was successful and continues the insert operation using incomplete lookup path data, causing the following crash:

general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] ... RIP: 0010:nilfsbtreegetnonrootnode fs/nilfs2/btree.c:418 [inline] RIP: 0010:nilfsbtreeprepareinsert fs/nilfs2/btree.c:1077 [inline] RIP: 0010:nilfsbtreeinsert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238 Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02 ... Call Trace: <TASK> nilfsbmapdoinsert fs/nilfs2/bmap.c:121 [inline] nilfsbmapinsert+0x20d/0x360 fs/nilfs2/bmap.c:147 nilfsgetblock+0x414/0x8d0 fs/nilfs2/inode.c:101 _blockwritebeginint+0x54c/0x1a80 fs/buffer.c:1991 _blockwritebegin fs/buffer.c:2041 [inline] blockwritebegin+0x93/0x1e0 fs/buffer.c:2102 nilfswritebegin+0x9c/0x110 fs/nilfs2/inode.c:261 genericperformwrite+0x2e4/0x5e0 mm/filemap.c:3772 _genericfilewriteiter+0x176/0x400 mm/filemap.c:3900 genericfilewriteiter+0xab/0x310 mm/filemap.c:3932 callwriteiter include/linux/fs.h:2186 [inline] newsyncwrite fs/readwrite.c:491 [inline] vfswrite+0x7dc/0xc50 fs/readwrite.c:584 ksyswrite+0x177/0x2a0 fs/readwrite.c:637 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd ... </TASK>

This patch fixes the root cause of this problem by replacing the error code that _nilfsbtreegetblock() returns on block address conversion failure from -ENOENT to another internal code -EINVAL which means that the b-tree metadata is corrupted.

By returning -EINVAL, it propagates without glitches, and for all relevant b-tree operations, functions in the upper bmap layer output an error message indicating corrupted b-tree metadata via nilfsbmapconvert_error(), and code -EIO will be eventually returned as it should be.(CVE-2023-52900)

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 dev_uevent() 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 entrySYSCALL64after_hwframe+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.(CVE-2024-39501)

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

ocfs2: add bounds checking to ocfs2checkdir_entry()

This adds sanity checks for ocfs2direntry to make sure all members of ocfs2direntry don't stray beyond valid memory region.(CVE-2024-41015)

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

s390/sclp: Fix sclp_init() cleanup on failure

If sclpinit() fails it only partially cleans up: if there are multiple failing calls to sclpinit() sclpstatechangeevent will be added several times to sclpreg_list, which results in the following warning:

------------[ cut here ]------------ listadd double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10. WARNING: CPU: 0 PID: 1 at lib/listdebug.c:35 listaddvalidorreport+0xde/0xf8 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3 Krnl PSW : 0404c00180000000 000003ffe0d6076a (listaddvalidorreport+0xe2/0xf8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 ... Call Trace: [<000003ffe0d6076a>] _listaddvalidorreport+0xe2/0xf8 ([<000003ffe0d60766>] _listaddvalidorreport+0xde/0xf8) [<000003ffe0a8d37e>] sclpinit+0x40e/0x450 [<000003ffe00009f2>] dooneinitcall+0x42/0x1e0 [<000003ffe15b77a6>] doinitcalls+0x126/0x150 [<000003ffe15b7a0a>] kernelinitfreeable+0x1ba/0x1f8 [<000003ffe0d6650e>] kernelinit+0x2e/0x180 [<000003ffe000301c>] _retfromfork+0x3c/0x60 [<000003ffe0d759ca>] retfromfork+0xa/0x30

Fix this by removing sclpstatechangeevent from sclpreglist when sclpinit() fails.(CVE-2024-41068)

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

i2c: pnx: Fix potential deadlock warning from deltimersync() call in isr

When deltimersync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from waitforcompletion() after a timeout so replacing the call with waitforcompletion_timeout() allows to remove the problematic timer and its related functions altogether.(CVE-2024-42153)

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

protect the fetch of ->fd[fd] in do_dup2() from mispredictions

both callers have verified that fd is not greater than ->maxfds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in closefd()/fileclosefdlocked(); the same solution applies - arrayindexnospec(fd, fdt->maxfds) could differ from fd only in case of speculative execution on mispredicted path.(CVE-2024-42265)

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

net/iucv: fix use after free in iucvsockclose()

iucvseverpath() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucvsockclose() will try to work with a path that has already been severed and freed by iucvcallbackconnrej() called by iucvtaskletfn().

Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucvpathsever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucvseverpath+0xc2/0xd0 [afiucv] [452744.124336] [<000003ff801e01b6>] iucvsockclose+0xa6/0x310 [afiucv] [452744.124341] [<000003ff801e08cc>] iucvsockrelease+0x3c/0xd0 [afiucv] [452744.124345] [<00000000d574794e>] _sockrelease+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sockclose+0x34/0x48 [452744.124820] [<00000000d5421642>] _fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] taskworkrun+0xbc/0xf0 [452744.124832] [<00000000d5145710>] donotifyresume+0x88/0x90 [452744.124841] [<00000000d5978096>] systemcall+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucvpathsever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt

Note that bhlocksock() is not serializing the tasklet context against process context, because the check for sockownedby_user() and corresponding handling is missing.

Ideas for a future clean-up patch: A) Correct usage of bhlocksock() in tasklet context, as described in Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv.

B) Change iucv tasklet into worker and use only locksock() in afiucv.(CVE-2024-42271)

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

mISDN: Fix a use after free in hfcmulti_tx()

Don't dereference sp after calling dev_kfree_skb(sp).(CVE-2024-42280)

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

tipc: Return non-zero value from tipcudpaddr2str() on error

tipcudpaddr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipcmediaaddr_printf(). Fix this by returning 1 on an invalid UDP media address.(CVE-2024-42284)

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

RDMA/iwcm: Fix a use-after-free related to destroying CM IDs

iwconnreqhandler() associates a new struct rdmaidprivate (connid) with an existing struct iwcmid (cm_id) as follows:

    conn_id->cm_id.iw = cm_id;
    cm_id->context = conn_id;
    cm_id->cm_handler = cma_iw_handler;

rdmadestroyid() frees both the cmid and the struct rdmaidprivate. Make sure that cmworkhandler() does not trigger a use-after-free by only freeing of the struct rdmaid_private after all pending work has finished.(CVE-2024-42285)

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

scsi: qla2xxx: During vport delete send async logout explicitly

During vport delete, it is observed that during unload we hit a crash because of stale entries in outstanding command array. For all these stale I/O entries, ehabort was issued and aborted (fastfail_io = 2009h) but I/Os could not complete while vport delete is in process of deleting.

BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Workqueue: qla2xxxwq qladowork [qla2xxx] RIP: 0010:dmadirectunmapsg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8 R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0 Call Trace: <TASK> qla2xxxqpairspfreedma+0x417/0x4e0 ? qla2xxxqpairspcompl+0x10d/0x1a0 ? qla2x00statusentry+0x768/0x2830 ? newidlebalance+0x2f0/0x430 ? dequeueentity+0x100/0x3c0 ? qla24xxprocessresponsequeue+0x6a1/0x19e0 ? _schedule+0x2d5/0x1140 ? qladowork+0x47/0x60 ? processonework+0x267/0x440 ? processonework+0x440/0x440 ? workerthread+0x2d/0x3d0 ? processonework+0x440/0x440 ? kthread+0x156/0x180 ? setkthreadstruct+0x50/0x50 ? retfrom_fork+0x22/0x30 </TASK>

Send out async logout explicitly for all the ports during vport delete.(CVE-2024-42289)

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

f2fs: fix to don't dirty inode for readonly filesystem

syzbot reports f2fs bug as below:

kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fsevictinode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 disposelist fs/inode.c:697 [inline] evictinodes+0x5f8/0x690 fs/inode.c:747 genericshutdownsuper+0x9d/0x2c0 fs/super.c:675 killblocksuper+0x44/0x90 fs/super.c:1667 killf2fssuper+0x303/0x3b0 fs/f2fs/super.c:4894 deactivatelockedsuper+0xc1/0x130 fs/super.c:484 cleanupmnt+0x426/0x4c0 fs/namespace.c:1256 taskworkrun+0x24a/0x300 kernel/taskwork.c:180 ptracenotify+0x2cd/0x380 kernel/signal.c:2399 ptracereportsyscall include/linux/ptrace.h:411 [inline] ptracereportsyscallexit include/linux/ptrace.h:473 [inline] syscallexitwork kernel/entry/common.c:251 [inline] syscallexittousermodeprepare kernel/entry/common.c:278 [inline] _syscallexittousermodework kernel/entry/common.c:283 [inline] syscallexittousermode+0x15c/0x280 kernel/entry/common.c:296 dosyscall64+0x50/0x110 arch/x86/entry/common.c:88 entrySYSCALL64after_hwframe+0x63/0x6b

The root cause is: - dosysopen - f2fslookup - _f2fsfindentry - f2fsidepthwrite - f2fsmarkinodedirtysync - f2fsdirtyinode - setinodeflag(inode, FIDIRTY_INODE)

• umount
  • killf2fssuper
    • killblocksuper
      • genericshutdownsuper
        • syncfilesystem : sb is readonly, skip syncfilesystem()
        • evictinodes
          • iput
            • f2fsevictinode
              • f2fsbugon(sbi, isinodeflagset(inode, FIDIRTYINODE)) : trigger kernel panic

When we try to repair icurrentdepth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fsevictinode().(CVE-2024-42297)

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

ext4: check dot and dotdot of dx_root before making dir indexed

Syzbot reports a issue as follows:

BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: <TASK> makeindexeddir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4addentry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4rename fs/ext4/namei.c:3936 [inline] ext4rename2+0x26e5/0x4370 fs/ext4/namei.c:4214

[...]

The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue.

do_split
  unsigned split
  dx_make_map
   count = 1
  split = count/2 = 0;
  continued = hash2 == map[split - 1].hash;
   ---> map[4294967295]

The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called.

But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows:

bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024

So when renaming dentry1 increases its namelen length by 1, neither hole nor free is sufficient to hold the new dentry, and makeindexed_dir() is called.

In makeindexeddir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1.

Therefore add the ext4checkdx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue.(CVE-2024-42305)

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

net: usb: qmi_wwan: fix memory leak for not ip packets

Free the unused skb when not ip packets arrive.(CVE-2024-43861)

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

wifi: cfg80211: handle 2x996 RU allocation in cfg80211calculatebitrate_he()

Currently NL80211RATEINFOHERUALLOC2x996 is not handled in cfg80211calculatebitrate_he(), leading to below warning:

kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211calculatebitrate_he+0x22b/0x270 [cfg80211]

Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)

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

exec: Fix ToCToU between perm check and set-uid/gid usage

When opening a file for exec via dofilpopen(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges.

For example, if a file could change permissions from executable and not set-id:

---------x 1 root root 16048 Aug 7 13:16 target

to set-id and non-executable:

---S------ 1 root root 16048 Aug 7 13:16 target

it is possible to gain root privileges when execution should have been disallowed.

While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root:

-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target

becomes:

-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target

But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpmfilluid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root".

Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal.(CVE-2024-43882)