OESA-2024-2321

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

iommu/vt-d: Fix double list_add when enabling VMD in scalable mode

When enabling VMD and IOMMU scalable mode, the following kernel panic call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids CPU) during booting:

pci 0000:59:00.5: Adding to iommu group 42 ... vmd 0000:59:00.5: PCI host bridge to bus 10000:80 pci 10000:80:01.0: [8086:352a] type 01 class 0x060400 pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:01.0: enabling Extended Tags pci 10000:80:01.0: PME# supported from D0 D3hot D3cold pci 10000:80:01.0: DMAR: Setup RID2PASID failed pci 10000:80:01.0: Failed to add to iommu group 42: -16 pci 10000:80:03.0: [8086:352b] type 01 class 0x060400 pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:03.0: enabling Extended Tags pci 10000:80:03.0: PME# supported from D0 D3hot D3cold ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:29! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7 Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022 Workqueue: events workforcpufn RIP: 0010:_listaddvalid.cold+0x26/0x3f Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1 fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9 9e e8 8b b1 fe RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8 RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20 RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888 R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0 R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70 FS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> intelpasidalloctable+0x9c/0x1d0 dmarinsertonedevinfo+0x423/0x540 ? devicetoiommu+0x12d/0x2f0 inteliommuattachdevice+0x116/0x290 _iommuattachdevice+0x1a/0x90 iommugroupadddevice+0x190/0x2c0 _iommuprobedevice+0x13e/0x250 iommuprobedevice+0x24/0x150 iommubusnotifier+0x69/0x90 blockingnotifiercallchain+0x5a/0x80 deviceadd+0x3db/0x7b0 ? archmemremapcanramremap+0x19/0x50 ? memremap+0x75/0x140 pcideviceadd+0x193/0x1d0 pciscansingledevice+0xb9/0xf0 pciscanslot+0x4c/0x110 pciscanchildbusextend+0x3a/0x290 vmdenabledomain.constprop.0+0x63e/0x820 vmdprobe+0x163/0x190 localpciprobe+0x42/0x80 workforcpufn+0x13/0x20 processonework+0x1e2/0x3b0 workerthread+0x1c4/0x3a0 ? rescuerthread+0x370/0x370 kthread+0xc7/0xf0 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x1f/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- ... Kernel panic - not syncing: Fatal exception Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---

The following 'lspci' output shows devices '10000:80:*' are subdevices of the VMD device 0000:59:00.5:

$ lspci ... 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20) ... 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03) 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03) 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03) 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03) 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] 10000:82:00 ---truncated---(CVE-2022-48916)

In the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct socdeviceattribute array, which causes an oops when assessed by the socdevicematch(mt7621pciequirksmatch) call. This was only exposed once the CONFIGSOCMT7621 mt7621 socdev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Fix it by adding the required sentinel.(CVE-2022-48952)

In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs ISERR() bug for debugfscreatedir() The debugfscreatedir() function returns error pointers. It never returns NULL. So use ISERR() to check it.(CVE-2023-52917)

In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885vdevinit() return cx23885vdevinit() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)

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

of: module: prevent NULL pointer dereference in vsnprintf()

In ofmodalias(), we can get passed the str and len parameters which would cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr when the length is also 0. Also, we need to filter out the negative values of the len parameter as these will result in a really huge buffer since snprintf() takes sizet parameter while ours is ssize_t...

Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.(CVE-2024-35878)

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

dma: xilinx_dpdma: Fix locking

There are several places where either chan->lock or chan->vchan.lock was not held. Add appropriate locking. This fixes lockdep warnings like

[ 31.077578] ------------[ cut here ]------------ [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinxdpdma.c:834 xilinxdpdmachanqueuetransfer+0x274/0x5e0 [ 31.077953] Modules linked in: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98 [ 31.078102] Hardware name: xlnx,zynqmp (DT) [ 31.078169] Workqueue: eventsunbound deferredprobeworkfunc [ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.078377] pc : xilinxdpdmachanqueuetransfer+0x274/0x5e0 [ 31.078473] lr : xilinxdpdmachanqueuetransfer+0x270/0x5e0 [ 31.078550] sp : ffffffc083bb2e10 [ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def [ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516 [ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff [ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000 [ 31.080307] Call trace: [ 31.080340] xilinxdpdmachanqueuetransfer+0x274/0x5e0 [ 31.080518] xilinxdpdmaissuepending+0x11c/0x120 [ 31.080595] zynqmpdisplayerupdate+0x180/0x3ac [ 31.080712] zynqmpdpsubplaneatomicupdate+0x11c/0x21c [ 31.080825] drmatomichelpercommitplanes+0x20c/0x684 [ 31.080951] drmatomichelpercommittail+0x5c/0xb0 [ 31.081139] committail+0x234/0x294 [ 31.081246] drmatomichelpercommit+0x1f8/0x210 [ 31.081363] drmatomiccommit+0x100/0x140 [ 31.081477] drmclientmodesetcommitatomic+0x318/0x384 [ 31.081634] drmclientmodesetcommitlocked+0x8c/0x24c [ 31.081725] drmclientmodesetcommit+0x34/0x5c [ 31.081812] _drmfbhelperrestorefbdevmodeunlocked+0x104/0x168 [ 31.081899] drmfbhelpersetpar+0x50/0x70 [ 31.081971] fbconinit+0x538/0xc48 [ 31.082047] visualinit+0x16c/0x23c [ 31.082207] dobindcondriver.isra.0+0x2d0/0x634 [ 31.082320] dotakeoverconsole+0x24c/0x33c [ 31.082429] dofbcontakeover+0xbc/0x1b0 [ 31.082503] fbconfbregistered+0x2d0/0x34c [ 31.082663] registerframebuffer+0x27c/0x38c [ 31.082767] _drmfbhelperinitialconfigandunlock+0x5c0/0x91c [ 31.082939] drmfbhelperinitialconfig+0x50/0x74 [ 31.083012] drmfbdevdmaclienthotplug+0xb8/0x108 [ 31.083115] drmclientregister+0xa0/0xf4 [ 31.083195] drmfbdevdmasetup+0xb0/0x1cc [ 31.083293] zynqmpdpsubdrminit+0x45c/0x4e0 [ 31.083431] zynqmpdpsubprobe+0x444/0x5e0 [ 31.083616] platformprobe+0x8c/0x13c [ 31.083713] reallyprobe+0x258/0x59c [ 31.083793] _driverprobedevice+0xc4/0x224 [ 31.083878] driverprobedevice+0x70/0x1c0 [ 31.083961] _deviceattachdriver+0x108/0x1e0 [ 31.084052] busforeachdrv+0x9c/0x100 [ 31.084125] _deviceattach+0x100/0x298 [ 31.084207] deviceinitialprobe+0x14/0x20 [ 31.084292] busprobedevice+0xd8/0xdc [ 31.084368] deferredprobeworkfunc+0x11c/0x180 [ 31.084451] processonework+0x3ac/0x988 [ 31.084643] workerthread+0x398/0x694 [ 31.084752] kthread+0x1bc/0x1c0 [ 31.084848] retfromfork+0x10/0x20 [ 31.084932] irq event stamp: 64549 [ 31.084970] hardirqs last enabled at (64548): [<ffffffc081adf35c>] rawspinunlockirqrestore+0x80/0x90 [ 31.085157] ---truncated---(CVE-2024-35990)

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

netfilter: nfnetlinkqueue: acquire rcureadlock() in instancedestroy_rcu()

syzbot reported that nfreinject() could be called without rcuread_lock() :

WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted

net/netfilter/nfnetlinkqueue.c:263 suspicious rcudereference_check() usage!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 2 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcucallback){....}-{0:0}, at: rculockacquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcucallback){....}-{0:0}, at: rcudobatch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcucallback){....}-{0:0}, at: rcucore+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spinlockbh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnlflush net/netfilter/nfnetlinkqueue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instancedestroyrcu+0x30/0x220 net/netfilter/nfnetlinkqueue.c:172

stack backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: <IRQ> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 lockdeprcususpicious+0x221/0x340 kernel/locking/lockdep.c:6712 nfreinject net/netfilter/nfnetlinkqueue.c:323 [inline] nfqnlreinject+0x6ec/0x1120 net/netfilter/nfnetlinkqueue.c:397 nfqnlflush net/netfilter/nfnetlinkqueue.c:410 [inline] instancedestroyrcu+0x1ae/0x220 net/netfilter/nfnetlinkqueue.c:172 rcudobatch kernel/rcu/tree.c:2196 [inline] rcucore+0xafd/0x1830 kernel/rcu/tree.c:2471 handlesoftirqs+0x2d6/0x990 kernel/softirq.c:554 _dosoftirq kernel/softirq.c:588 [inline] invokesoftirq kernel/softirq.c:428 [inline] _irqexitrcu+0xf4/0x1c0 kernel/softirq.c:637 irqexitrcu+0x9/0x30 kernel/softirq.c:649 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvecapictimerinterrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK>(CVE-2024-36286)

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

ALSA: core: Fix NULL module pointer assignment at card init

The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARNON() for a NULL module pointer passed at sndcard object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIGSND=y) while the driver is a module (CONFIGSNDUSBAUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal.

For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in.

Note that we keep 'ifdef MODULE' for WARNON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIGSND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare.(CVE-2024-38605)

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

soundwire: cadence: fix invalid PDI offset

For some reason, we add an offset to the PDI, presumably to skip the PDI0 and PDI1 which are reserved for BPT.

This code is however completely wrong and leads to an out-of-bounds access. We were just lucky so far since we used only a couple of PDIs and remained within the PDI array bounds.

A Fixes: tag is not provided since there are no known platforms where the out-of-bounds would be accessed, and the initial code had problems as well.

A follow-up patch completely removes this useless offset.(CVE-2024-38635)

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

riscv: prevent pt_regs corruption for secondary idle threads

Top of the kernel thread stack should be reserved for ptregs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their ptregs, so both may get corrupted.

Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving taskptregs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smpcallin stored several registers on stack, corrupting top of ptregs structure including status field. As a result, kernel attempted to save or restore inexistent V context.(CVE-2024-38667)

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

nvmet: fix a possible leak when destroy a ctrl during qp establishment

In nvmetsqdestroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl.

However, a small window is possible where nvmetsqdestroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But before killandconfirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmetsqdestroy. This prevented the final reference drop on the ctrl.

Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that.

This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.(CVE-2024-42152)

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

dev/parport: fix the array out-of-bounds risk

Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed.

Below is the stack trace I encountered during the actual issue:

[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: dohardwarebaseaddr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dumpbacktrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] showstack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dumpstack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] _stackchkfail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] dohardwarebaseaddr+0xcc/0xd0 parport

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

exfat: fix potential deadlock on _exfatgetdentryset

When accessing a file with more entries than ESMAXENTRYNUM, the bh-array is allocated in _exfatgetentryset. The problem is that the bh-array is allocated with GFPKERNEL. It does not make sense. In the following cases, a deadlock for sbi->s_lock between the two processes may occur.

   CPU0                CPU1
   ----                ----

kswapd balancepgdat lock(fsreclaim) exfatiterate lock(&sbi->slock) exfatreaddir exfatgetuninamefromextentry exfatgetdentryset _exfatgetdentryset kmallocarray ... lock(fsreclaim) ... evict exfatevictinode lock(&sbi->slock)

To fix this, let's allocate bh-array with GFP_NOFS.(CVE-2024-42315)

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

wifi: virt_wifi: avoid reporting connection success with wrong SSID

When user issues a connection with a different SSID than the one virtwifi has advertised, the _cfg80211connectresult() will trigger the warning: WARNON(bssnot_found).

The issue is because the connection code in virtwifi does not check the SSID from user space (it only checks the BSSID), and virtwifi will call cfg80211connectresult() with WLANSTATUSSUCCESS even if the SSID is different from the one virtwifi has advertised. Eventually cfg80211 won't be able to find the cfg80211bss and generate the warning.

Fixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)

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

jfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)

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

drm/nouveau: prime: fix refcount underflow

Calling nouveauboref() on a nouveaubo without initializing it (and hence the backing ttmbo) leads to a refcount underflow.

Instead of calling nouveauboref() in the unwind path of drmgemobject_init(), clean things up manually.

(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)

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

devres: Fix memory leakage caused by driver API devmfreepercpu()

It will cause memory leakage when use driver API devmfreepercpu() to free memory allocated by devmallocpercpu(), fixed by using devresrelease() instead of devresdestroy() within devmfreepercpu().(CVE-2024-43871)

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

drm/client: fix null pointer dereference in drmclientmodeset_probe

In drmclientmodesetprobe(), the return value of drmmodeduplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drmmode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)

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

mptcp: pm: only decrement addaddraccepted for MPJ req

Adding the following warning ...

WARNONONCE(msk->pm.addaddraccepted == 0)

... before decrementing the addaddraccepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest.

Removing a 'subflow' endpoint will first trigger a RMADDR, then the subflow closure. Before this patch, and upon the reception of the RMADDR, the other peer will then try to decrement this addaddraccepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR.

A way to solve that is to decrement the counter only if the attached subflow was an MPJOIN to a remote id that was not 0, and initiated by the host receiving the RMADDR.(CVE-2024-45009)

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

usb: dwc3: core: Prevent USB core invalid event buffer address access

This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3gadgetsuspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3coreexit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.

To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address.(CVE-2024-46675)

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

soc: qcom: cmd-db: Map shared memory as WC, not WB

Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone.

The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings.

Changing the mapping of cmd-db memory from MEMREMAPWB to MEMREMAPWT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC.

I tested this on SA8155P with Xen.(CVE-2024-46689)

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

drm/amdgpu: fix mc_data out-of-bounds read warning

Clear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)

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

drm/amdgpu: Fix out-of-bounds read of dfv17channelnumber

Check the fbchannelnumber range to avoid the array out-of-bounds read error(CVE-2024-46724)

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

hwmon: (nct6775-core) Fix underflows seen when writing limit attributes

DIVROUNDCLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clampval() and DIVROUND_CLOSEST() operations.(CVE-2024-46757)

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

drm/amd/display: added NULL check at start of dcvalidatestream

[Why] prevent invalid memory access

[How] check if dc and stream are NULL(CVE-2024-46802)

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

KVM: x86: Acquire kvm->srcu when handling KVMSETVCPU_EVENTS

Grab kvm->srcu when processing KVMSETVCPU_EVENTS, as KVM will forcibly leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX reads guest memory.

Note, kvmvcpuioctlx86setvcpuevents() can also be called from KVMRUN via syncregs(), which already holds SRCU. I.e. trying to precisely use kvmvcpusrcureadlock() around the problematic SMM code would cause problems. Acquiring SRCU isn't all that expensive, so for simplicity, grab it unconditionally for KVMSETVCPU_EVENTS.

============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted

include/linux/kvmhost.h:1027 suspicious rcudereference_check() usage!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvmvcpu_ioctl+0x7d/0x970 [kvm]

stack backtrace: CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x7f/0x90 lockdeprcususpicious+0x13f/0x1a0 kvmvcpugfntomemslot+0x168/0x190 [kvm] kvmvcpureadguest+0x3e/0x90 [kvm] nestedvmxloadmsr+0x6b/0x1d0 [kvmintel] loadvmcs12hoststate+0x432/0xb40 [kvmintel] vmxleavenested+0x30/0x40 [kvmintel] kvmvcpuioctlx86setvcpuevents+0x15d/0x2b0 [kvm] kvmarchvcpuioctl+0x1107/0x1750 [kvm] ? markheldlocks+0x49/0x70 ? kvmvcpuioctl+0x7d/0x970 [kvm] ? kvmvcpuioctl+0x497/0x970 [kvm] kvmvcpuioctl+0x497/0x970 [kvm] ? lockacquire+0xba/0x2d0 ? findheldlock+0x2b/0x80 ? douseraddrfault+0x40c/0x6f0 ? lockrelease+0xb7/0x270 _x64sysioctl+0x82/0xb0 dosyscall64+0x6c/0x170 entrySYSCALL64after_hwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539 </TASK>(CVE-2024-46830)

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

spi: nxp-fspi: fix the KASAN report out-of-bounds bug

Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO.

To reproduce the issue, write 3 bytes data to NOR chip.

dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxpfspiexecop+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dumpbacktrace+0x90/0xe8 [ 36.967414] showstack+0x18/0x24 [ 36.970749] dumpstacklvl+0x78/0x90 [ 36.974451] printreport+0x114/0x5cc [ 36.978151] kasanreport+0xa4/0xf0 [ 36.981670] _asanreportloadnnoabort+0x1c/0x28 [ 36.986587] nxpfspiexecop+0x26ec/0x2838 [ 36.990800] spimemexecop+0x8ec/0xd30 [ 36.994762] spimemnodirmapread+0x190/0x1e0 [ 36.999323] spimemdirmapwrite+0x238/0x32c [ 37.003710] spinorwritedata+0x220/0x374 [ 37.007932] spinorwrite+0x110/0x2e8 [ 37.011711] mtdwriteoobstd+0x154/0x1f0 [ 37.015838] mtdwriteoob+0x104/0x1d0 [ 37.019617] mtdwrite+0xb8/0x12c [ 37.022953] mtdcharwrite+0x224/0x47c [ 37.026732] vfswrite+0x1e4/0x8c8 [ 37.030163] ksyswrite+0xec/0x1d0 [ 37.033586] _arm64syswrite+0x6c/0x9c [ 37.037539] invokesyscall+0x6c/0x258 [ 37.041327] el0svccommon.constprop.0+0x160/0x22c [ 37.046244] doel0svc+0x44/0x5c [ 37.049589] el0svc+0x38/0x78 [ 37.052681] el0t64synchandler+0x13c/0x158 [ 37.057077] el0t64sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasansavestack+0x2c/0x54 [ 37.069570] kasansavetrack+0x20/0x3c [ 37.073438] kasansaveallocinfo+0x40/0x54 [ 37.077736] _kasankmalloc+0xa0/0xb8 [ 37.081515] _kmallocnoprof+0x158/0x2f8 [ 37.085563] mtdkmallocupto+0x120/0x154 [ 37.089690] mtdcharwrite+0x130/0x47c [ 37.093469] vfswrite+0x1e4/0x8c8 [ 37.096901] ksyswrite+0xec/0x1d0 [ 37.100332] _arm64syswrite+0x6c/0x9c [ 37.104287] invokesyscall+0x6c/0x258 [ 37.108064] el0svccommon.constprop.0+0x160/0x22c [ 37.112972] doel0svc+0x44/0x5c [ 37.116319] el0svc+0x38/0x78 [ 37.119401] el0t64synchandler+0x13c/0x158 [ 37.123788] el0t64sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ============================================================== ---truncated---(CVE-2024-46853)

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

PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)

Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452DJuly 2018Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang.

The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here.

The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed.

[1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)

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

nilfs2: fix state management in error path of log writing function

After commit a694291a6211 ("nilfs2: separate wait function from nilfssegctorwrite") was applied, the log writing function nilfssegctordo_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling.

First, if nilfssegctorbeginconstruction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfssegctorabortconstruction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncateinodepagesfinal(), which is called via nilfsevict_inode() when an inode is evicted from memory, will hang.

Second, the NILFSICOLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFSICOLLECTED set are erroneously removed from the "scdirtyfiles" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping.

Fix these issues by uniformly calling nilfssegctorabortconstruction() on failure of each step in the loop in nilfssegctordoconstruct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfsredirtyinodes() to ensure that the NILFSICOLLECTED flag is cleared.(CVE-2024-47669)

In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcprtodeltaus() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcprearmrto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: errorcode(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? showregs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? _die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? nocontext+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6protocoldeliverrcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6sublistrcvfinish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? _badareanosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? badareanosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? douseraddrfault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6listrcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? _dopagefault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? dopagefault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? pagefault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcprearmrto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcpsendlossprobe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcpwritetimerhandler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcpwritetimer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcpwritetimerhandler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] calltimerfn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] _runtimers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibratecpukhz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? nativex2apicicrwrite+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapicnext_even ---truncated---(CVE-2024-47684)

In the Linux kernel, the following vulnerability has been resolved: netfilter: nfrejectipv6: fix nfrejectip6tcphdrput() syzbot reported that nfrejectip6tcphdrput() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skbputzero() to clear the whole TCP header, as done in nfrejectiptcphdrput() BUG: KMSAN: uninit-value in nfrejectip6tcphdrput+0x688/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:255 nfrejectip6tcphdrput+0x688/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:255 nfsendreset6+0xd84/0x15b0 net/ipv6/netfilter/nfrejectipv6.c:344 nftrejectineteval+0x3c1/0x880 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x438/0x22a0 net/netfilter/nftablescore.c:288 nftdochaininet+0x41a/0x4f0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x29b/0x390 net/ipv6/ip6input.c:310 _netifreceiveskbonecore net/core/dev.c:5661 [inline] _netifreceiveskb+0x1da/0xa00 net/core/dev.c:5775 processbacklog+0x4ad/0xa50 net/core/dev.c:6108 _napipoll+0xe7/0x980 net/core/dev.c:6772 napipoll net/core/dev.c:6841 [inline] netrxaction+0xa5a/0x19b0 net/core/dev.c:6963 handlesoftirqs+0x1ce/0x800 kernel/softirq.c:554 _dosoftirq+0x14/0x1a kernel/softirq.c:588 dosoftirq+0x9a/0x100 kernel/softirq.c:455 _localbhenableip+0x9f/0xb0 kernel/softirq.c:382 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:908 [inline] _devqueuexmit+0x2692/0x5610 net/core/dev.c:4450 devqueuexmit include/linux/netdevice.h:3105 [inline] neighresolveoutput+0x9ca/0xae0 net/core/neighbour.c:1565 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x2347/0x2ba0 net/ipv6/ip6output.c:141 _ip6finishoutput net/ipv6/ip6output.c:215 [inline] ip6finishoutput+0xbb8/0x14b0 net/ipv6/ip6output.c:226 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x356/0x620 net/ipv6/ip6output.c:247 dstoutput include/net/dst.h:450 [inline] NFHOOK include/linux/netfilter.h:314 [inline] ip6xmit+0x1ba6/0x25d0 net/ipv6/ip6output.c:366 inet6cskxmit+0x442/0x530 net/ipv6/inet6connectionsock.c:135 _tcptransmitskb+0x3b07/0x4880 net/ipv4/tcpoutput.c:1466 tcptransmitskb net/ipv4/tcpoutput.c:1484 [inline] tcpconnect+0x35b6/0x7130 net/ipv4/tcpoutput.c:4143 tcpv6connect+0x1bcc/0x1e40 net/ipv6/tcpipv6.c:333 _inetstreamconnect+0x2ef/0x1730 net/ipv4/afinet.c:679 inetstreamconnect+0x6a/0xd0 net/ipv4/afinet.c:750 _sysconnectfile net/socket.c:2061 [inline] _sysconnect+0x606/0x690 net/socket.c:2078 _dosysconnect net/socket.c:2088 [inline] _sesysconnect net/socket.c:2085 [inline] _x64sysconnect+0x91/0xe0 net/socket.c:2085 x64syscall+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:43 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f Uninit was stored to memory at: nfrejectip6tcphdrput+0x60c/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:249 nfsendreset6+0xd84/0x15b0 net/ipv6/netfilter/nfrejectipv6.c:344 nftrejectineteval+0x3c1/0x880 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x438/0x22a0 net/netfilter/nftablescore.c:288 nftdochaininet+0x41a/0x4f0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x29b/0x390 net/ipv6/ip6input.c:310 _netifreceiveskbone_core ---truncated---(CVE-2024-47685)

In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdupuser() to return ZEROSIZEPTR. When we access the name.data that has been assigned the value of ZEROSIZEPTR in nfs4clienttoreclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4clienttoreclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dumpstack+0x9a/0xd0 [ T1205] ? nfs4clienttoreclaim+0xe9/0x260 [ T1205] _kasanreport.cold+0x34/0x84 [ T1205] ? nfs4clienttoreclaim+0xe9/0x260 [ T1205] kasanreport+0x3a/0x50 [ T1205] nfs4clienttoreclaim+0xe9/0x260 [ T1205] ? nfsd4releaselockowner+0x410/0x410 [ T1205] cldpipedowncall+0x5ca/0x760 [ T1205] ? nfsd4cldtrackingexit+0x1d0/0x1d0 [ T1205] ? downwritekillablenested+0x170/0x170 [ T1205] ? avcpolicyseqno+0x28/0x40 [ T1205] ? selinuxfilepermission+0x1b4/0x1e0 [ T1205] rpcpipewrite+0x84/0xb0 [ T1205] vfswrite+0x143/0x520 [ T1205] ksyswrite+0xc9/0x170 [ T1205] ? _ia32sysread+0x50/0x50 [ T1205] ? ktimegetcoarserealts64+0xfe/0x110 [ T1205] ? ktimegetcoarserealts64+0xa2/0x110 [ T1205] dosyscall64+0x33/0x40 [ T1205] entrySYSCALL64afterhwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.(CVE-2024-47692)

In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to connum - 1 to stay in bounds In the function initconns(), after the createcon() and createcm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to cltpath->s.connum. This commits resets the cid to cltpath->s.connum - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)

In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832pidfilter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so setbit and clearbit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. hverkuil: added fixes tag, rtl2830pidfilter -> rtl2832pidfilter in logmsg

In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcmprocread after removeprocentry(). syzbot reported a warning in bcmrelease(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcmprocread triggers unnecessary removeprocentry() in bcmrelease(). Let's clear bo->bcmprocread after removeprocentry() in bcmnotify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 removeprocentry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:removeprocentry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> bcmrelease+0x250/0x880 net/can/bcm.c:1578 _sockrelease net/socket.c:659 [inline] sockclose+0xbc/0x240 net/socket.c:1421 _fput+0x24a/0x8a0 fs/filetable.c:422 taskworkrun+0x24f/0x310 kernel/taskwork.c:228 exittaskwork include/linux/taskwork.h:40 [inline] doexit+0xa2f/0x27f0 kernel/exit.c:882 dogroupexit+0x207/0x2c0 kernel/exit.c:1031 _dosysexitgroup kernel/exit.c:1042 [inline] _sesysexitgroup kernel/exit.c:1040 [inline] _x64sysexitgroup+0x3f/0x40 kernel/exit.c:1040 x64syscall+0x2634/0x2640 arch/x86/include/generated/asm/syscalls64.h:232 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIGRAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 </TASK>(CVE-2024-47709)

In the Linux kernel, the following vulnerability has been resolved: sockmap: Add a condresched() in sockhashfree() Several syzbot soft lockup reports all have in common sockhashfree() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for setoutputgamma in dcn30setoutputtransferfunc This commit adds a null check for the setoutputgamma function pointer in the dcn30setoutputtransferfunc function. Previously, setoutputgamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if setoutputgamma is indeed null. To fix this, we now ensure that setoutputgamma is not null before dereferencing it. We do this by adding a nullity check for setoutputgamma before the call to setoutputgamma at line 401. If setoutputgamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30hwseq.c:401 dcn30setoutputtransferfunc() error: we previously assumed 'mpc->funcs->setoutputgamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30hwseq.c 373 bool dcn30setoutputtransferfunc(struct dc dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 / program OGAM or 3DLUT only for the top pipe/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /program rmu shaper and 3dlut in MPC/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 / there are no ROM LUTs in OUTGAM */ 396 if (stream->outtransferfunc.type == TFTYPEPREDEFINED) 397 BREAKTODEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->setoutputgamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }(CVE-2024-47720)

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spinunlockirqrestore() called with IRQs enabled Fix missuse of spinlockirq()/spinunlockirq() when spinlockirqsave()/spinlockirqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: rawlocalirqrestore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warnbogusirqrestore+0x30/0x40 ... Call trace: warnbogusirqrestore+0x30/0x40 _rawspinunlockirqrestore+0x84/0xc8 addqptolist+0x11c/0x148 [hnsrocehwv2] hnsrocecreateqpcommon.constprop.0+0x240/0x780 [hnsrocehwv2] hnsrocecreateqp+0x98/0x160 [hnsrocehwv2] createqp+0x138/0x258 ibcreateqpkernel+0x50/0xe8 createmadqp+0xa8/0x128 ibmadportopen+0x218/0x448 ibmadinitdevice+0x70/0x1f8 addclientcontext+0xfc/0x220 enabledeviceandget+0xd0/0x140 ibregisterdevice.part.0+0xf4/0x1c8 ibregisterdevice+0x34/0x50 hnsroceregisterdevice+0x174/0x3d0 [hnsrocehwv2] hnsroceinit+0xfc/0x2c0 [hnsrocehwv2] _hnsrocehwv2initinstance+0x7c/0x1d0 [hnsrocehwv2] hnsrocehwv2initinstance+0x9c/0x180 hnsrocehwv2

In the Linux kernel, the following vulnerability has been resolved: nfsd: call cacheput if xdrreservespace returns NULL If not enough buffer space available, but idmaplookup has triggered lookupfn which calls cacheget and returns successfully. Then we missed to call cacheput here which pairs with cacheget. Reviwed-by: Jeff Layton <jlayton@kernel.org>(CVE-2024-47737)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfsbtreecheckdelete() The function nilfsbtreecheckdelete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)

In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpuonlinemask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHPONLINE] | cpudevicedown() osnoisehotplugworkfn() | | cpuswritelock() | takedowncpu(1) | cpuswriteunlock() [CPUHPOFFLINE] | cpusreadlock() | startkthread(1) | cpusreadunlock() | To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)

In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at closectree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct taskstruct; 3) We call btrfsstopallworkers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfsadddelayediput(), because the taskstruct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthreadstop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at closectree() before we call kthreadstop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in _lockacquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfsworkhelper Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 _lockacquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lockacquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 _rawspinlockirqsave include/linux/spinlockapismp.h:110 [inline] _rawspinlockirqsave+0xd5/0x120 kernel/locking/spinlock.c:162 classrawspinlockirqsaveconstructor include/linux/spinlock.h:551 [inline] trytowakeup+0xb0/0x1480 kernel/sched/core.c:4154 btrfswritepagefixupworker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfsworkhelper+0x390/0xc50 fs/btrfs/async-thread.c:314 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa63/0x1850 kernel/workqueue.c:3310 workerthread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 </TASK> Allocated by task 2: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 unpoisonslabobject mm/kasan/common.c:319 [inline] _kasanslaballoc+0x66/0x80 mm/kasan/common.c:345 kasanslaballoc include/linux/kasan.h:247 [inline] slabpostallochook mm/slub.c:4086 [inline] slaballocnode mm/slub.c:4135 [inline] kmemcacheallocnodenoprof+0x16b/0x320 mm/slub.c:4187 alloctaskstructnode kernel/fork.c:180 [inline] duptaskstruct+0x57/0x8c0 kernel/fork.c:1107 copyprocess+0x5d1/0x3d50 kernel/fork.c:2206 kernelclone+0x223/0x880 kernel/fork.c:2787 kernelthread+0x1bc/0x240 kernel/fork.c:2849 createkthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 Freed by task 61: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x40/0x50 mm/kasan/generic.c:579 poisonslabobject mm/kasan/common.c:247 [inline] _kasanslabfree+0x59/0x70 mm/kasan/common.c:264 kasanslabfree include/linux/kasan.h:230 [inline] slabfreeh ---truncated---(CVE-2024-49867)

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULTINJECTION: forcing a failure. starttransaction+0x830/0x1670 fs/btrfs/transaction.c:676 preparetorelocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocateblockgroup+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfsupdaterelocroot+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: <TASK> commitfsroots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfscommittransaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 delbalanceitem fs/btrfs/volumes.c:3678 [inline] resetbalancestate+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfsbalance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfsioctlbalance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:907 [inline] _sesysioctl+0xf9/0x170 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f [CAUSE] The allocation failure happens at the starttransaction() inside preparetorelocate(), and during the error handling we call unsetreloccontrol(), which makes fsinfo->balancectl to be NULL. Then we continue the error path cleanup in btrfsbalance() by calling resetbalancestate() which will call delbalanceitem() to fully delete the balance item in the root tree. However during the small window between setreloccontrl() and unsetreloccontrol(), we can have a subvolume tree update and created a relocroot for that subvolume. Then we go into the final btrfscommittransaction() of delbalanceitem(), and into btrfsupdaterelocroot() inside commitfsroots(). That function checks if fsinfo->relocctl is in the mergereloctree stage, but since fsinfo->relocctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fsinfo->relocctl inside btrfsupdaterelocroot(), before checking fsinfo->relocctl->mergereloctree. That DEADRELOCTREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)

In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserrio to avoid warning Ext4 will throw -EBADMSG through ext4readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserrio. nfsdbufferedreaddir iteratedir // -EBADMSG -74 ext4readdir // .iterateshared ext4dxreaddir ext4htreefilltree htreedirblocktotree ext4readdirblock _ext4readdirblock ext4dirblockcsumverify warnnospaceforcsum _warnnospaceforcsum return ERRPTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? _warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? reportbug+0x125/0x150 [ 161.144595] ? handlebug+0x41/0x90 [ 161.145284] ? excinvalidop+0x14/0x70 [ 161.146009] ? asmexcinvalidop+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsdbufferedreaddir+0x28b/0x2b0 [ 161.148333] ? nfsd4encodedirentfattr+0x380/0x380 [ 161.149258] ? nfsdbufferedfilldir+0xf0/0xf0 [ 161.150093] ? waitforconcurrentwrites+0x170/0x170 [ 161.151004] ? genericfilellseeksize+0x48/0x160 [ 161.151895] nfsdreaddir+0x132/0x190 [ 161.152606] ? nfsd4encodedirentfattr+0x380/0x380 [ 161.153516] ? nfsdunlink+0x380/0x380 [ 161.154256] ? overridecreds+0x45/0x60 [ 161.155006] nfsd4encodereaddir+0x21a/0x3d0 [ 161.155850] ? nfsd4encodereadlink+0x210/0x210 [ 161.156731] ? writebytestoxdrbuf+0x97/0xe0 [ 161.157598] ? _writebytestoxdrbuf+0xd0/0xd0 [ 161.158494] ? lockdowngrade+0x90/0x90 [ 161.159232] ? nfs4svcdecodevoidarg+0x10/0x10 [ 161.160092] nfsd4encodeoperation+0x15a/0x440 [ 161.160959] nfsd4proccompound+0x718/0xe90 [ 161.161818] nfsddispatch+0x18e/0x2c0 [ 161.162586] svcprocesscommon+0x786/0xc50 [ 161.163403] ? nfsdsvc+0x380/0x380 [ 161.164137] ? svcprintk+0x160/0x160 [ 161.164846] ? svcxprtdoenqueue.part.0+0x365/0x380 [ 161.165808] ? nfsdsvc+0x380/0x380 [ 161.166523] ? rcuiswatching+0x23/0x40 [ 161.167309] svcprocess+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsdshutdownthreads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthreadinsertworksanitycheck+0x80/0x80 [ 161.171246] retfrom_fork+0x1f/0x30(CVE-2024-49875)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize getbytesperelement's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytesperelementy & bytesperelementc are initialized by getbytesperelement() which should never return 0. This fixes 10 DIVIDEBYZERO issues reported by Coverity.(CVE-2024-49892)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in cm_helper_translate_curve_to_degamma_hw_format function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFERFUNCPOINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10cmcommon.c:594 cmhelpertranslatecurvetodegammahwformat() error: buffer overflow 'outputtf->tfpts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10cmcommon.c:595 cmhelpertranslatecurvetodegammahwformat() error: buffer overflow 'outputtf->tfpts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10cmcommon.c:596 cmhelpertranslatecurvetodegammahwformat() error: buffer overflow 'outputtf->tf_pts.blue' 1025 <= s32max(CVE-2024-49894)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the cm3_helper_translate_curve_to_degamma_hw_format function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFERFUNCPOINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30cmcommon.c:338 cm3helpertranslatecurvetodegammahwformat() error: buffer overflow 'outputtf->tfpts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30cmcommon.c:339 cm3helpertranslatecurvetodegammahwformat() error: buffer overflow 'outputtf->tfpts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30cmcommon.c:340 cm3helpertranslatecurvetodegammahwformat() error: buffer overflow 'outputtf->tf_pts.blue' 1025 <= s32max(CVE-2024-49895)

In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of newea in eabuffer syzbot reports that lzo1x1docompress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x1docompress+0x19f9/0x2510 lib/lzo/lzo1xcompress.c:178 ... Uninit was stored to memory at: eaput fs/jfs/xattr.c:639 [inline] ... Local variable eabuf created at: _jfssetxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 _jfsxattrset+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is eabuf->newea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)

In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmtleafidx greater than num leaves per dmap tree, add a checking for dmtleafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)

In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in _mutexlockcommon kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in _mutexlock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 _mutexlockcommon kernel/locking/mutex.c:587 [inline] _mutexlock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfsdmap.c:2390 dbFreeDmap fs/jfs/jfsdmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfsdmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfsdmap.c:1650 jfsioctrim+0x433/0x670 fs/jfs/jfsdiscard.c:100 jfsioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:907 [inline] _sesysioctl+0xfc/0x170 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x40/0x50 mm/kasan/generic.c:579 poisonslabobject+0xe0/0x150 mm/kasan/common.c:240 _kasanslabfree+0x37/0x60 mm/kasan/common.c:256 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2252 [inline] slabfree mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfsdmap.c:278 jfsmountrw+0x4ac/0x6a0 fs/jfs/jfsmount.c:247 jfsremount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfiguresuper+0x445/0x880 fs/super.c:1083 vfscmdreconfigure fs/fsopen.c:263 [inline] vfsfsconfiglocked fs/fsopen.c:292 [inline] _dosysfsconfig fs/fsopen.c:473 [inline] _sesysfsconfig+0xb6e/0xf80 fs/fsopen.c:345 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f [Analysis] There are two paths (dbUnmount and jfsioctrim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20setoutputtransferfunc This commit adds a null check for the setoutputgamma function pointer in the dcn20setoutputtransferfunc function. Previously, setoutputgamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if setoutputgamma is null. To fix this, we now ensure that setoutputgamma is not null before dereferencing it. We do this by adding a null check for setoutputgamma before the call to setoutputgamma at line 1048.(CVE-2024-49911)

In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irqpinlist (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mpirqdomainalloc+0x9ab/0xa80 irqdomainallocirqslocked+0x25d/0x8d0 _irqdomainallocirqs+0x80/0x110 mpmappintoirq+0x645/0x890 acpiregistergsiioapic+0xe6/0x150 hpetopen+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timercheck() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around _addpintoirqnode() and making mpirqdomainalloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)

In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2cleanupjournaltail() returns error In jbd2logwaitforspace(), we might call jbd2cleanupjournaltail() to recover some journal space. But if an error occurs while executing jbd2cleanupjournaltail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if jcommittingtransaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. _jbd2logwaitforspace: needed 256 blocks and only had 217 space available _jbd2logwaitforspace: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 _jbd2logwaitforspace+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:jbd2logwaitforspace+0x251/0x2e0 Call Trace: <TASK> addtransactioncredits+0x5d1/0x5e0 startthishandle+0x1ef/0x6a0 jbd2_journalstart+0x18b/0x340 ext4dirtyinode+0x5d/0xb0 _markinodedirty+0xe4/0x5d0 genericupdatetime+0x60/0x70 [...] ============================================ So only if jbd2cleanupjournaltail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2cleanupjournal_tail return the correct error code.(CVE-2024-49959)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2readblocks Patch series "Misc fixes for ocfs2readblocks", v5. This series contains 2 fixes for ocfs2readblocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2readblocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqisyncwork before freeing oinfo ocfs2globalreadinfo() will initialize and schedule dqisyncwork at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIGDEBUGOBJECTS* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timerlist hint: qsyncworkfn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqisyncwork first. BTW, return status instead of -1 when .readfile_info fails.(CVE-2024-49966)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the cm3_helper_translate_curve_to_hw_format function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFERFUNCPOINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30cmcommon.c:180 cm3helpertranslatecurvetohwformat() error: buffer overflow 'outputtf->tfpts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30cmcommon.c:181 cm3helpertranslatecurvetohwformat() error: buffer overflow 'outputtf->tfpts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30cmcommon.c:182 cm3helpertranslatecurvetohwformat() error: buffer overflow 'outputtf->tfpts.blue' 1025 <= s32max(CVE-2024-49969)

In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)

In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clkops .prepare callback may trigger a deadlock on drivers/clk/clk.c preparelock mutex. This is because the clock controller first grabs the preparelock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtimeresume callback, which calls clkprepareenable(), which attempts to grab the preparelock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clkenable()/clkdisable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the preparelock mutex.(CVE-2024-49985)

In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flushwork initialization out of if block After commit 379a58caa199 ("scsi: fnic: Move fnicfnicflushtx() to a work queue"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 _queuework+0x373/0x410 kernel: <IRQ> kernel: queueworkon+0x3a/0x50 kernel: fnicwqcopycmplhandler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnicisrmsixwqcopy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: _handleirqeventpercpu+0x36/0x1a0 kernel: handleirqeventpercpu+0x30/0x70 kernel: handleirqevent+0x34/0x60 kernel: handleedgeirq+0x7e/0x1a0 kernel: _commoninterrupt+0x3b/0xb0 kernel: commoninterrupt+0x58/0xa0 kernel: </IRQ> It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)

In the Linux kernel, the following vulnerability has been resolved: net: do not delay dstentriesadd() in dstrelease() dstentriesadd() uses per-cpu data that might be freed at netns dismantle from ip6routenetexit() calling dstentriesdestroy() Before ip6routenetexit() can be called, we release all the dsts associated with this netns, via calls to dstrelease(), which waits an rcu grace period before calling dstdestroy() dstentriesadd() use in dstdestroy() is racy, because dstentriesdestroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIGXFRM case, dstdestroy() can call dstreleaseimmediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.(CVE-2024-50036)

In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42completecopies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42completecopies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsecgsskrb5 authrpcgss nfsv4 dnsresolver nfs lockd grace fscache netfs ocfs2dlmfs ocfs2stacko2cb ocfs2dlm vhostnet vhost vhostiotlb tap tun iptrpfilter xtmultiport ipsethaship ipsethashnet xfrminterface xfrm6tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519generic veth xtaddrtype xtset nfconntracknetlink ipsethashipportnet ipsethashipportip ipsetbitmapport ipsethashipport dummy ipset ipvssh ipvswrr ipvsrr ipvs iptablefilter schingress nfnetlinkcttimeout vportgre ipgre iptunnel gre vportgeneve geneve vportvxlan vxlan ip6udptunnel udptunnel openvswitch nfconncount dmroundrobin dmservicetime dmmultipath xtnat xtMASQUERADE nftchainnat nfnat xtmark xtconntrack xtcomment nftcompat nftcounter nftables nfnetlink ocfs2 ocfs2nodemanager ocfs2stackglue iscsitcp libiscsitcp libiscsi scsitransportiscsi ipmissif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cascache casdisk ses enclosure scsitransportsas sg acpiipmi ipmisi ipmidevintf ipmimsghandler iptables vfiopci vfiopcicore vfiovirqfd vfioiommutype1 vfio dmmirror dmregionhash dmlog dmmod nfconntrack nfdefragipv6 nfdefragipv4 brnetfilter bridge stp llc fuse xfs libcrc32c ast drmvramhelper qla2xxx drmkmshelper syscopyarea crct10difce sysfillrect ghashce sysimgblt sha2ce fbsysfops cec sha256arm64 sha1ce drmttmhelper ttm nvmefc igb sbsagwdt nvmefabrics drm nvmecore i2calgobit i40e scsitransportfc megaraidsas aesneonbs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBEV3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4reclaimopenstate+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4reclaimopenstate+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)