OESA-2024-2423

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

usb: typec: ucsi: Fix null pointer dereference in trace

ucsiregisteraltmode checks ISERR for the alt pointer and treats NULL as valid. When CONFIGTYPECDPALTMODE is not enabled, ucsiregisterdisplayport returns NULL which causes a NULL pointer dereference in trace. Rather than return NULL, call typecportregisteraltmode to register DisplayPort alternate mode as a non-controllable mode when CONFIGTYPECDPALTMODE is not enabled.(CVE-2024-46719)

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

x86/tdx: Fix data leak in mmio_read()

The mmio_read() function makes a TDVMCALL to retrieve MMIO data for an address from the VMM.

Sean noticed that mmio_read() unintentionally exposes the value of an initialized variable (val) on the stack to the VMM.

This variable is only needed as an output value. It did not need to be passed to the VMM in the first place.

Do not send the original value of *val to the VMM.

dhansen: clarify what 'val' is used for.

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

drm/amdkfd: Check debug trap enable before write dbgevfile

In interrupt context, write dbgevfile will be run by work queue. It will cause write dbgevfile execution after debugtrapdisable, which will cause NULL pointer access. v2: cancel work "debugeventworkarea" before set dbgevfile as NULL.(CVE-2024-46803)

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

drm/amd/amdgpu: Check tbo resource pointer

Validate tbo resource pointer, skip if NULL(CVE-2024-46807)

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

staging: iio: frequency: ad9834: Validate frequency parameter value

In ad9834writefrequency() clkgetrate() can return 0. In such case ad9834calcfreqreg() call will lead to division by zero. Checking 'if (fout > (clkfreq / 2))' doesn't protect in case of 'fout' is 0. ad9834writefrequency() is called from ad9834write(), where fout is taken from text buffer, which can contain any value.

Modify parameters checking.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47663)

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

lib/generic-radix-tree.c: Fix rare race in _genradixptr_alloc()

If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later.

If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path.(CVE-2024-47668)

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

wifi: iwlwifi: mvm: pause TCM when the firmware is stopped

Not doing so will make us send a host command to the transport while the firmware is not alive, which will trigger a WARNING.

bad state = 0 WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwltranssendcmd+0x1cb/0x1e0 [iwlwifi] RIP: 0010:iwltranssendcmd+0x1cb/0x1e0 [iwlwifi] Call Trace: <TASK> iwlmvmsendcmd+0x40/0xc0 [iwlmvm] iwlmvmconfigscan+0x198/0x260 [iwlmvm] iwlmvmrecalctcm+0x730/0x11d0 [iwlmvm] iwlmvmtcmwork+0x1d/0x30 [iwlmvm] processonework+0x29e/0x640 workerthread+0x2df/0x690 ? rescuerthread+0x540/0x540 kthread+0x192/0x1e0 ? setkthreadstruct+0x90/0x90 retfromfork+0x22/0x30(CVE-2024-47673)

In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ibcachesetupone error flow cleanup When ibcacheupdate return an error, we exit ibcachesetupone instantly with no proper cleanup, even though before this we had already successfully done gidtablesetupone, that results in the kernel WARN below. Do proper cleanup using gidtablecleanupone before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gidtablereleaseone+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: crepro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gidtablereleaseone+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? showregs+0x94/0xa0 ? warn+0x9e/0x1c0 ? gidtablereleaseone+0x181/0x1a0 ? reportbug+0x1f9/0x340 ? gidtablereleaseone+0x181/0x1a0 ? handlebug+0xa2/0x110 ? excinvalidop+0x31/0xa0 ? asmexcinvalidop+0x16/0x20 ? _warnprintk+0xc7/0x180 ? _warnprintk+0xd4/0x180 ? gidtablereleaseone+0x181/0x1a0 ibdevicerelease+0x71/0xe0 ? _pfxibdevicerelease+0x10/0x10 devicerelease+0x44/0xd0 kobjectput+0x135/0x3d0 putdevice+0x20/0x30 rxenetadd+0x7d/0xa0 rxenewlink+0xd7/0x190 nldevnewlink+0x1b0/0x2a0 ? _pfxnldevnewlink+0x10/0x10 rdmanlrcvmsg+0x1ad/0x2e0 rdmanlrcvskb.constprop.0+0x176/0x210 netlinkunicast+0x2de/0x400 netlinksendmsg+0x306/0x660 _socksendmsg+0x110/0x120 syssendmsg+0x30e/0x390 _syssendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouintfromuser+0x7c/0xb0 ? getpidtask+0xb0/0xd0 ? procfailnthwrite+0x5b/0x140 ? _fgetlight+0x9a/0x200 ? preemptcountadd+0x47/0xa0 _syssendmsg+0x61/0xd0 dosyscall64+0x50/0x110 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2024-47693)

In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/dataend/datameta syzbot reported a kernel crash due to commit 1f1e864b6555 ("bpf: Handle sign-extenstin ctx member accesses"). The reason is due to sign-extension of 32-bit load for packet data/dataend/datameta uapi field. The original code looks like: r2 = (s32 *)(r1 + 76) / load _skbuff->data / r3 = *(u32 *)(r1 + 80) / load _skbuff->dataend */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that _skbuff->data load has 32-bit sign extension. After verification and convertctxaccesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel _skbuff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *dataend = (void )(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since "r2 <<= 32" is not allowed as "r2" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) / load _skbuff->data */ this patch added additional checking in isvalidaccess() callback function for packet data/dataend/datameta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/(CVE-2024-47702)

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.(CVE-2024-47726)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as streamenc and dc->bwvbios, are null checked previously in the same function, so Coverity warns "implies that streamenc and dc->bwvbios might be null". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.(CVE-2024-49920)

In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rqqoswait vs. rqqoswakefunction race We're seeing crashes from rqqoswakefunction that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:rawspinlockirqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> trytowakeup+0x5a/0x6a0 rqqoswakefunction+0x71/0x80 _wakeupcommon+0x75/0xa0 _wakeup+0x36/0x60 scaleup.part.0+0x50/0x110 wbtimerfn+0x227/0x450 ... So rqqoswakefunction() calls wakeupprocess(data->task), which calls trytowakeup(), which faults in rawspinlockirqsave(&p->pilock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rqqoswait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wakeupprocess(), leading to the crash. What's happening is that in between rqqoswakefunction() deleting the waitqueue entry and calling wakeupprocess(), rqqoswait() is finding that it already got a token and returning. The race looks like this: rqqoswait() rqqoswakefunction() ============================================================== preparetowaitexclusive() data->gottoken = true; listdelinit(&curr->entry); if (data.gottoken) break; finishwait(&rqw->wait, &data.wq); ^- returns immediately because listemptycareful(&wqentry->entry) is true ... return, go do something else ... wakeupprocess(data->task) (NO LONGER VALID!)-^ Normally, finishwait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rqqoswakefunction() is accessing the waitqueue entry AFTER deleting it. Note that autoremovewakefunction() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use listdelinitcareful() to match the listemptycareful() in finishwait().(CVE-2024-50082)

In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases madagentpriv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el94.x8664 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ibmad1 timeoutsends [ibcore] RIP: 0010:dosoftirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? showtraceloglvl+0x1c4/0x2df ? showtraceloglvl+0x1c4/0x2df ? _irqexitrcu+0xa1/0xc0 ? watchdogtimerfn+0x1b2/0x210 ? _pfxwatchdogtimerfn+0x10/0x10 ? _hrtimerrunqueues+0x127/0x2c0 ? hrtimerinterrupt+0xfc/0x210 ? _sysvecapictimerinterrupt+0x5c/0x110 ? sysvecapictimerinterrupt+0x37/0x90 ? asmsysvecapictimerinterrupt+0x16/0x20 ? _dosoftirq+0x78/0x2ac ? _dosoftirq+0x60/0x2ac _irqexitrcu+0xa1/0xc0 sysveccallfunctionsingle+0x72/0x90 </IRQ> <TASK> asmsysveccallfunctionsingle+0x16/0x20 RIP: 0010:rawspinunlockirq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cmprocesssenderror+0x122/0x1d0 [ibcm] timeoutsends+0x1dd/0x270 [ibcore] processonework+0x1e2/0x3b0 ? _pfxworkerthread+0x10/0x10 workerthread+0x50/0x3a0 ? _pfxworkerthread+0x10/0x10 kthread+0xdd/0x100 ? _pfxkthread+0x10/0x10 retfrom_fork+0x29/0x50 </TASK> Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs(CVE-2024-50095)

In the Linux kernel, the following vulnerability has been resolved: smb: client: Handle kstrdup failures for passwords In smb3_reconfigure(), after duplicating ctx->password and ctx->password2 with kstrdup(), we need to check for allocation failures. If ses->password allocation fails, return -ENOMEM. If ses->password2 allocation fails, free ses->password, set it to NULL, and return -ENOMEM.(CVE-2024-50120)

In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it.(CVE-2024-50131)

In the Linux kernel, the following vulnerability has been resolved: octeonep: Add SKB allocation failures handling in _octepoqprocessrx() buildskb() returns NULL in case of a memory allocation failure so handle it inside _octepoqprocessrx() to avoid NULL pointer dereference. _octepoqprocessrx() is called during NAPI polling by the driver. If skb allocation fails, keep on pulling packets out of the Rx DMA queue: we shouldn't break the polling immediately and thus falsely indicate to the octepnapipoll() that the Rx pressure is going down. As there is no associated skb in this case, don't process the packets and don't push them up the network stack - they are skipped. Helper function is implemented to unmmap/flush all the fragment buffers used by the dropped packet. 'alloc_failures' counter is incremented to mark the skb allocation error in driver statistics. Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50145)

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix possible double free in smb2setea() Clang static checker(scan-build) warning： fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory. 1304 | kfree(ea); | ^~~~~~~~~ There is a double free in such case: 'ea is initialized to NULL' -> 'first successful memory allocation for ea' -> 'something failed, goto seaexit' -> 'first memory release for ea' -> 'goto replayagain' -> 'second goto seaexit before allocate memory for ea' -> 'second memory release for ea resulted in double free'. Re-initialie 'ea' to NULL near to the replayagain label, it can fix this double free problem.(CVE-2024-50152)

In the Linux kernel, the following vulnerability has been resolved: drm/msm: Avoid NULL dereference in msmdispstateprintregs() If the allocation in msmdispstatedumpregs() failed then block->state can be NULL. The msmdispstateprintregs() function does have code to try to handle it with: if (*reg) dumpaddr = *reg; ...but since "dumpaddr" is initialized to NULL the above is actually a noop. The code then goes on to dereference dump_addr. Make the function print "Registers not stored" when it sees a NULL to solve this. Since we're touching the code, fix msmdispstateprintregs() not to pointlessly take a double-pointer and properly mark the pointer as const. Patchwork: https://patchwork.freedesktop.org/patch/619657/(CVE-2024-50156)

In the Linux kernel, the following vulnerability has been resolved: virtiopmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtiopmemflush(), causing the system to hang. So add a status check in the beginning of virtiopmem_flush() to return early if the device is not activated.(CVE-2024-50184)

In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket creation fails"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use skcommonrelease in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AFPACKET socket and if packetcreate fails, it will just skfree the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in _sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.(CVE-2024-50186)