OESA-2024-1679

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

drm/tegra: dsi: Add missing check for offinddevicebynode

Add check for the return value of offinddevicebynode() and return the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)

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

pstore: ramcore: fix possible overflow in persistentraminitecc()

In persistentraminitecc(), on 64-bit arches DIVROUNDUP() will return 64-bit value since persistentramzone::buffersize has type sizet which is derived from the 64-bit *unsigned long*, while the eccblocks variable this value gets assigned to has (always 32-bit) int type. Even if that value fits into int type, an overflow is still possible when calculating the sizet typed ecctotal variable further below since there's no cast to any 64-bit type before multiplication. Declaring the eccblocks variable as *sizet* should fix this mess...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2023-52685)

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

drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function

With tpd12s015remove() marked with _exit this function is discarded when the driver is compiled as a built-in. The result is that when the driver unbinds there is no cleanup done which results in resource leakage or worse.(CVE-2023-52694)

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

crypto: pcrypt - Fix hungtask for PADATA_RESET

We found a hungtask bug in testaeadvec_cfg as follows:

INFO: task cryptomgrtest:391009 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. Call trace: _switchto+0x98/0xe0 _schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 scheduletimeout+0x474/0x560 waitforcommon+0x368/0x4e0 waitforcompletion+0x20/0x30 waitforcompletion+0x20/0x30 testaeadveccfg+0xab4/0xd50 testaead+0x144/0x1f0 algtestaead+0xd8/0x1e0 algtest+0x634/0x890 cryptomgrtest+0x40/0x70 kthread+0x1e0/0x220 retfromfork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasks

For padatadoparallel, when the return err is 0 or -EBUSY, it will call waitforcompletion(&wait->completion) in testaeadveccfg. In normal case, aeadrequestcomplete() will be called in pcryptaeadserial and the return err is 0 for padatadoparallel. But, when pinst->flags is PADATARESET, the return err is -EBUSY for padatadoparallel, and it won't call aeadrequestcomplete(). Therefore, testaeadveccfg will hung at waitfor_completion(&wait->completion), which will cause hungtask.

The problem comes as following: (padatadoparallel) | rcureadlockbh(); | err = -EINVAL; | (padatareplace) | pinst->flags |= PADATARESET; err = -EBUSY | if (pinst->flags & PADATARESET) | rcureadunlock_bh() | return err

In order to resolve the problem, we replace the return err -EBUSY with -EAGAIN, which means parallel_data is changing, and the caller should call it again.

v3: remove retry and just change the return err. v2: introduce padatatrydoparallel() in pcryptaeadencrypt and pcryptaead_decrypt to solve the hungtask.(CVE-2023-52813)

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

drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL

In certain types of chips, such as VEGA20, reading the amdgpuregssmc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:

1. Navigate to the directory: /sys/kernel/debug/dri/0
2. Execute command: cat amdgpuregssmc
3. Exception Log:: [4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000 [4005007.702562] #PF: supervisor instruction fetch in kernel mode [4005007.702567] #PF: errorcode(0x0010) - not-present page [4005007.702570] PGD 0 P4D 0 [4005007.702576] Oops: 0010 [#1] SMP NOPTI [4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u [4005007.702590] RIP: 0010:0x0 [4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 [4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68 [4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 [4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980 [4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 [4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000 [4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 [4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 [4005007.702633] Call Trace: [4005007.702636] <TASK> [4005007.702640] amdgpudebugfsregssmcread+0xb0/0x120 [amdgpu] [4005007.703002] fullproxyread+0x5c/0x80 [4005007.703011] vfsread+0x9f/0x1a0 [4005007.703019] ksysread+0x67/0xe0 [4005007.703023] _x64sysread+0x19/0x20 [4005007.703028] dosyscall64+0x5c/0xc0 [4005007.703034] ? douseraddrfault+0x1e3/0x670 [4005007.703040] ? exittousermodeprepare+0x37/0xb0 [4005007.703047] ? irqentryexittousermode+0x9/0x20 [4005007.703052] ? irqentryexit+0x19/0x30 [4005007.703057] ? excpagefault+0x89/0x160 [4005007.703062] ? asmexcpagefault+0x8/0x30 [4005007.703068] entrySYSCALL64afterhwframe+0x44/0xae [4005007.703075] RIP: 0033:0x7f5e07672992 [4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24 [4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIGRAX: 0000000000000000 [4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992 [4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003 [4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010 [4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000 [4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 [4005007.703105] </TASK> [4005007.703107] Modules linked in: nftables libcrc32c nfnetlink algifhash afalg binfmtmisc nls_ iso88591 ipmissif ast intelraplmsr intelraplcommon drmvramhelper drmttmhelper amd64edac t tm edacmceamd kvmamd ccp machid k10temp kvm acpiipmi ipmisi rapl schfqcodel ipmidevintf ipm imsghandler msr parportpc ppdev lp parport mtd pstoreblk efipstore ramoops pstorezone reedsolo mon iptables xtables autofs4 ibuverbs ibcore amdgpu(OE) amddrmttmhelper(OE) amdttm(OE) iommuv 2 amdsched(OE) amdkcl(OE) drmkmshelper syscopyarea sysfillrect sysimgblt fbsysfops cec rccore drm igb ahci xhcipci libahci i2cpiix4 i2calgobit xhcipci_renesas dca [4005007.703184] CR2: 0000000000000000 [4005007.703188] ---[ en ---truncated---(CVE-2023-52817)

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

nbd: fix uaf in nbd_open

Commit 4af5f2e03013 ("nbd: use blkmqallocdisk and blkcleanupdisk") cleans up disk by blkcleanupdisk() and it won't set disk->privatedata as NULL as before. UAF may be triggered in nbdopen() if someone tries to open nbd device right after nbdput() since nbd has been free in nbddevremove().

Fix this by implementing ->free_disk and free private data in it.(CVE-2023-52837)

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

drm/radeon: possible buffer overflow

Buffer 'afmtstatus' of size 6 could overflow, since index 'afmtidx' is checked after access.(CVE-2023-52867)

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

tracing: Have traceeventfile have ref counters

The following can crash the kernel:

# cd /sys/kernel/tracing # echo 'p:sched schedule' > kprobeevents # exec 5>>events/kprobes/sched/enable # > kprobeevents # exec 5>&-

The above commands:

1. Change directory to the tracefs directory
2. Create a kprobe event (doesn't matter what one)
3. Open bash file descriptor 5 on the enable file of the kprobe event
4. Delete the kprobe event (removes the files too)
5. Close the bash file descriptor 5

The above causes a crash!

BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:tracingreleasefiletr+0xc/0x50

What happens here is that the kprobe event creates a traceeventfile "file" descriptor that represents the file in tracefs to the event. It maintains state of the event (is it enabled for the given instance?). Opening the "enable" file gets a reference to the event "file" descriptor via the open file descriptor. When the kprobe event is deleted, the file is also deleted from the tracefs system which also frees the event "file" descriptor.

But as the tracefs file is still opened by user space, it will not be totally removed until the final dput() is called on it. But this is not true with the event "file" descriptor that is already freed. If the user does a write to or simply closes the file descriptor it will reference the event "file" descriptor that was just freed, causing a use-after-free bug.

To solve this, add a ref count to the event "file" descriptor as well as a new flag called "FREED". The "file" will not be freed until the last reference is released. But the FREE flag will be set when the event is removed to prevent any more modifications to that event from happening, even if there's still a reference to the event "file" descriptor.(CVE-2023-52879)

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

wireguard: netlink: access device through ctx instead of peer

The previous commit fixed a bug that led to a NULL peer->device being dereferenced. It's actually easier and faster performance-wise to instead get the device from ctx->wg. This semantically makes more sense too, since ctx->wg->peerallowedips.seq is compared with ctx->allowedipsseq, basing them both in ctx. This also acts as a defence in depth provision against freed peers.(CVE-2024-26950)

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

nfs: fix UAF in direct writes

In production we have been hitting the following warning consistently

------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcountwarnsaturate+0x9c/0xe0 Workqueue: nfsiod nfsdirectwriteschedulework [nfs] RIP: 0010:refcountwarnsaturate+0x9c/0xe0 PKRU: 55555554 Call Trace: <TASK> ? _warn+0x9f/0x130 ? refcountwarnsaturate+0x9c/0xe0 ? reportbug+0xcc/0x150 ? handlebug+0x3d/0x70 ? excinvalidop+0x16/0x40 ? asmexcinvalidop+0x16/0x20 ? refcountwarnsaturate+0x9c/0xe0 nfsdirectwriteschedulework+0x237/0x250 [nfs] processonework+0x12f/0x4a0 workerthread+0x14e/0x3b0 ? ZSTDgetCParamsinternal+0x220/0x220 kthread+0xdc/0x120 ? _btfnamevalid+0xa0/0xa0 retfrom_fork+0x1f/0x30

This is because we're completing the nfsdirectrequest twice in a row.

The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have

if (nfscommitend(cinfo.mds)) nfsdirectwrite_complete(dreq);

However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfsdirectrequest twice.

The only other place we use nfsgenericcommitlist() is in _nfscommitinode, which wraps this call in a

nfscommitbegin(); nfscommitend();

Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with getdreq()/putdreq() calls around where we process events as well as in the completion paths.

Fix this by using the same pattern for the commit requests.

Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping.(CVE-2024-26958)

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

mac802154: fix llsec key resources release in mac802154llseckey_del

mac802154llseckeydel() can free resources of a key directly without following the RCU rules for waiting before the end of a grace period. This may lead to use-after-free in case llseclookup_key() is traversing the list of keys in parallel with a key deletion:

refcountt: addition on 0; use-after-free. WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcountwarnsaturate+0x162/0x2a0 Modules linked in: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:refcountwarnsaturate+0x162/0x2a0 Call Trace: <TASK> llseclookupkey.isra.0+0x890/0x9e0 mac802154llsecencrypt+0x30c/0x9c0 ieee802154subifstartxmit+0x24/0x1e0 devhardstartxmit+0x13e/0x690 schdirectxmit+0x2ae/0xbc0 _devqueuexmit+0x11dd/0x3c20 dgramsendmsg+0x90b/0xd60 _syssendto+0x466/0x4c0 _x64syssendto+0xe0/0x1c0 dosyscall64+0x45/0xf0 entrySYSCALL64afterhwframe+0x6e/0x76

Also, ieee802154llseckeyentry structures are not freed by mac802154llseckeydel():

unreferenced object 0xffff8880613b6980 (size 64): comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s) hex dump (first 32 bytes): 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................ backtrace: [<ffffffff81dcfa62>] kmemcacheallocnode+0x1e2/0x2d0 [<ffffffff81c43865>] kmalloctrace+0x25/0xc0 [<ffffffff88968b09>] mac802154llseckeyadd+0xac9/0xcf0 [<ffffffff8896e41a>] ieee802154addllseckey+0x5a/0x80 [<ffffffff8892adc6>] nl802154addllseckey+0x426/0x5b0 [<ffffffff86ff293e>] genlfamilyrcvmsgdoit+0x1fe/0x2f0 [<ffffffff86ff46d1>] genlrcvmsg+0x531/0x7d0 [<ffffffff86fee7a9>] netlinkrcvskb+0x169/0x440 [<ffffffff86ff1d88>] genlrcv+0x28/0x40 [<ffffffff86fec15c>] netlinkunicast+0x53c/0x820 [<ffffffff86fecd8b>] netlinksendmsg+0x93b/0xe60 [<ffffffff86b91b35>] syssendmsg+0xac5/0xca0 [<ffffffff86b9c3dd>] _syssendmsg+0x11d/0x1c0 [<ffffffff86b9c65a>] _syssendmsg+0xfa/0x1d0 [<ffffffff88eadbf5>] dosyscall64+0x45/0xf0 [<ffffffff890000ea>] entrySYSCALL64afterhwframe+0x6e/0x76

Handle the proper resource release in the RCU callback function mac802154llseckeydelrcu().

Note that if llseclookupkey() finds a key, it gets a refcount via llseckeyget() and locally copies key id from keyentry (which is a list element). So it's safe to call llseckey_put() and free the list entry after the RCU grace period elapses.

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

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

clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcomfindfreq() or qcomfindfreq_floor().

Only compile tested.(CVE-2024-26965)

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

ubifs: ubifssymlink: Fix memleak of inode->ilink in error path

For error handling path in ubifssymlink(), inode will be marked as bad first, then iput() is invoked. If inode->ilink is initialized by fscryptencryptsymlink() in encryption scenario, inode->ilink won't be freed by callchain ubifsfreeinode -> fscryptfreeinode in error handling path, because makebadinode() has changed 'inode->imode' as 'SIFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifsjnlupdate() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 _fscryptencryptsymlink+0xed/0x1c0 ubifssymlink+0x210/0x300 [ubifs] vfssymlink+0x216/0x360 dosymlinkat+0x11a/0x190 dosyscall64+0x3b/0xe0 There are two ways fixing it: 1. Remove makebadinode() in error handling path. We can do that because ubifsevictinode() will do same processes for good symlink inode and bad symlink inode, for inode->inlink checking is before isbadinode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think.(CVE-2024-26972)

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

KVM: Always flush async #PF workqueue when vCPU is being destroyed

Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM module is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes.

Drop the misguided VM refcount gifting, as calling kvmputkvm() from asyncpfexecute() if kvmputkvm() flushes the async #PF workqueue will result in deadlock. asyncpfexecute() can't return until kvmputkvm() finishes, and kvmputkvm() can't return until asyncpfexecute() finishes:

WARNING: CPU: 8 PID: 251 at virt/kvm/kvmmain.c:1435 kvmputkvm+0x2d/0x320 [kvm] Modules linked in: vhostnet vhost vhostiotlb tap kvmintel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events asyncpfexecute [kvm] RIP: 0010:kvmputkvm+0x2d/0x320 [kvm] Call Trace: <TASK> asyncpfexecute+0x198/0x260 [kvm] processonework+0x145/0x2d0 workerthread+0x27e/0x3a0 kthread+0xba/0xe0 retfromfork+0x2d/0x50 retfromforkasm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events asyncpfexecute [kvm] Call Trace: <TASK> _schedule+0x33f/0xa40 schedule+0x53/0xc0 scheduletimeout+0x12a/0x140 _waitforcommon+0x8d/0x1d0 _flushwork.isra.0+0x19f/0x2c0 kvmclearasyncpfcompletionqueue+0x129/0x190 [kvm] kvmarchdestroyvm+0x78/0x1b0 [kvm] kvmputkvm+0x1c1/0x320 [kvm] asyncpfexecute+0x198/0x260 [kvm] processonework+0x145/0x2d0 workerthread+0x27e/0x3a0 kthread+0xba/0xe0 retfromfork+0x2d/0x50 retfromforkasm+0x11/0x20 </TASK>

If kvmclearasyncpfcompletionqueue() actually flushes the workqueue, then there's no need to gift asyncpfexecute() a reference because all invocations of asyncpfexecute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as _fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module.

Note that kvmcheckasyncpfcompletion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvmclearasyncpfcompletionqueue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvmarchasyncpagepresentqueued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just:

    trace_kvm_async_pf_completed(addr, cr2_or_gpa);

    __kvm_vcpu_wake_up(vcpu);

    mmput(mm);

and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables.

Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes _flushwork() complain (kudos to whoever added that sanity check).

Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated---(CVE-2024-26976)

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

fs: sysfs: Fix reference leak in sysfsbreakactive_protection()

The sysfsbreakactiveprotection() routine has an obvious reference leak in its error path. If the call to kernfsfindandget() fails then kn will be NULL, so the companion sysfsunbreakactive_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released.

Fix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)

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

serial: mxs-auart: add spinlock around changing cts state

The uarthandlectschange() function in serialcore expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board.

[   85.119255] ------------[ cut here ]------------
[   85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
[   85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
[   85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
[   85.151396] Hardware name: Freescale MXS (Device Tree)
[   85.156679] Workqueue: hci0 hci_power_on [bluetooth]
(...)
[   85.191765]  uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
[   85.198787]  mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
(...)(CVE-2024-27000)

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

drm: nv04: Fix out of bounds access

When Output Resource (dcb->or) value is assigned in fabricatedcboutput(), there may be out of bounds access to dacusers array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricatedcb_output() must be interpreted as a number of bit to set, not value.

Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.

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

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

drm/amd/display: Fix a potential buffer overflow in 'dpdscclockenread()'

Tell snprintf() to store at most 10 bytes in the output buffer instead of 30.

Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpudm/amdgpudmdebugfs.c:1508 dpdscclocken_read() error: snprintf() is printing too much 30 vs 10(CVE-2024-27045)

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

USB: usb-storage: Prevent divide-by-0 error in isd200atacommand

The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer.

Protect against this possibility by refusing to bind to the device if either the ATAIDHEADS or ATAIDSECTORS value in the device's ID information is 0. This requires isd200_Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error).(CVE-2024-27059)

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

media: ttpci: fix two memleaks in budgetavattach

When saa7146registerdevice and saa7146vvinit fails, budgetavattach should free the resources it allocates, like the error-handling of ttpcibudgetinit does. Besides, there are two fixme comment refers to such deallocations.(CVE-2024-27073)

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

media: dvb-frontends: avoid stack overflow warnings with clang

A previous patch worked around a KASAN issue in stv0367, now a similar problem showed up with clang:

drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367tersetfrontend' [-Werror,-Wframe-larger-than] 1214 | static int stv0367tersetfrontend(struct dvb_frontend *fe)

Rework the stv0367writereg() function to be simpler and mark both register access functions as noinlineforstack so the temporary i2cmsg structures do not get duplicated on the stack when KASAN_STACK is enabled.(CVE-2024-27075)

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

pstore: inode: Only d_invalidate() is needed

Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning:

WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410

Using the combo of ddrop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use dinvalidate() and update the code to not bother checking for error codes that can never happen.

---(CVE-2024-27389)

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

wifi: iwlwifi: dbg-tlv: ensure NUL termination

The iwlfwinidebuginfo_tlv is used as a string, so we must ensure the string is terminated correctly before using it.(CVE-2024-35845)

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

btrfs: fix information leak in btrfsioctllogicaltoino()

Syzbot reported the following information leak for in btrfsioctllogicaltoino():

BUG: KMSAN: kernel-infoleak in instrumentcopytouser include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copytouser+0xbc/0x110 lib/usercopy.c:40 instrumentcopytouser include/linux/instrumented.h:114 [inline] copytouser+0xbc/0x110 lib/usercopy.c:40 copytouser include/linux/uaccess.h:191 [inline] btrfsioctllogicaltoino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfsioctl+0x714/0x1260 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:904 [inline] _sesysioctl+0x261/0x450 fs/ioctl.c:890 _x64sysioctl+0x96/0xe0 fs/ioctl.c:890 x64syscall+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls64.h:17 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

Uninit was created at: _kmalloclargenode+0x231/0x370 mm/slub.c:3921 _dokmallocnode mm/slub.c:3954 [inline] _kmallocnode+0xb07/0x1060 mm/slub.c:3973 kmallocnode include/linux/slab.h:648 [inline] kvmallocnode+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] initdatacontainer+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfsioctllogicaltoino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfsioctl+0x714/0x1260 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:904 [inline] _sesysioctl+0x261/0x450 fs/ioctl.c:890 _x64sysioctl+0x96/0xe0 fs/ioctl.c:890 x64syscall+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls64.h:17 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000

This happens, because we're copying a 'struct btrfsdatacontainer' back to user-space. This btrfsdatacontainer is allocated in 'initdatacontainer()' via kvmalloc(), which does not zero-fill the memory.

Fix this by using kvzalloc() which zeroes out the memory on allocation.(CVE-2024-35849)

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

scsi: lpfc: Fix possible memory leak in lpfcrcvpadisc()

The call to lpfcsli4resumerpi() in lpfcrcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked.

Check return value after calling lpfcsli4resume_rpi() and conditionally release the elsiocb resource.(CVE-2024-35930)