OESA-2025-1820

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

tipc: fix the msg->req tlv len check in tipcnlcompatnametabledumpheader

This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value in tipcnlcompatnametabledump") where it should have type casted sizeof(..) to int to work when TLVGETDATALEN() returns a negative value.

syzbot reported a call trace because of it:

BUG: KMSAN: uninit-value in ... tipcnlcompatnametabledump+0x841/0xea0 net/tipc/netlinkcompat.c:934 _tipcnlcompatdumpit+0xab2/0x1320 net/tipc/netlinkcompat.c:238 tipcnlcompatdumpit+0x991/0xb50 net/tipc/netlinkcompat.c:321 tipcnlcompatrecv+0xb6e/0x1640 net/tipc/netlinkcompat.c:1324 genlfamilyrcvmsgdoit net/netlink/genetlink.c:731 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:775 [inline] genlrcvmsg+0x103f/0x1260 net/netlink/genetlink.c:792 netlinkrcvskb+0x3a5/0x6c0 net/netlink/afnetlink.c:2501 genlrcv+0x3c/0x50 net/netlink/genetlink.c:803 netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] netlinkunicast+0xf3b/0x1270 net/netlink/afnetlink.c:1345 netlinksendmsg+0x1288/0x1440 net/netlink/afnetlink.c:1921 socksendmsgnosec net/socket.c:714 [inline] socksendmsg net/socket.c:734 inline

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

net: tun: Fix memory leaks of napigetfrags

kmemleak reports after running test_progs:

unreferenced object 0xffff8881b1672dc0 (size 232): comm "testprogs", pid 394388, jiffies 4354712116 (age 841.975s) hex dump (first 32 bytes): e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g..... 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace: [<00000000c8f01748>] napiskbcacheget+0xd4/0x150 [<0000000041c7fc09>] _napibuildskb+0x15/0x50 [<00000000431c7079>] _napiallocskb+0x26e/0x540 [<000000003ecfa30e>] napigetfrags+0x59/0x140 [<0000000099b2199e>] tungetuser+0x183d/0x3bb0 [tun] [<000000008a5adef0>] tunchrwriteiter+0xc0/0x1b1 [tun] [<0000000049993ff4>] doiterreadvwritev+0x19f/0x320 [<000000008f338ea2>] doiterwrite+0x135/0x630 [<000000008a3377a4>] vfswritev+0x12e/0x440 [<00000000a6b5639a>] dowritev+0x104/0x280 [<00000000ccf065d8>] dosyscall64+0x3b/0x90 [<00000000d776e329>] entrySYSCALL64afterhwframe+0x63/0xcd

The issue occurs in the following scenarios: tungetuser() napigrofrags() napifragsfinish() case GRONORMAL: gronormalone() listaddtail(&skb->list, &napi->rxlist); <-- While napi->rxcount < READONCE(gronormalbatch), <-- gronormallist() is not called, napi->rxlist is not empty <-- not ask to complete the gro work, will cause memory leaks in <-- following tunnapidel() ... tunnapidel() netifnapidel() _netifnapidel() <-- &napi->rx_list is not empty, which caused memory leaks

To fix, add napicomplete() after napigro_frags().(CVE-2022-49871)

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

wifi: cfg80211: fix memory leak in queryregdbfile()

In the function queryregdbfile() the alpha2 parameter is duplicated using kmemdup() and subsequently freed in regdbfwcb(). However, requestfirmwarenowait() can fail without calling regdbfwcb() and thus leak memory.(CVE-2022-49881)

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

net: mdio: fix undefined behavior in bit shift for _mdiobusregister

Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below:

UBSAN: shift-out-of-bounds in drivers/net/phy/mdiobus.c:586:27 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> dumpstacklvl+0x7d/0xa5 dumpstack+0x15/0x1b ubsanepilogue+0xe/0x4e _ubsanhandleshiftoutofbounds+0x1e7/0x20c _mdiobusregister+0x49d/0x4e0 fixedmdiobusinit+0xd8/0x12d dooneinitcall+0x76/0x430 kernelinitfreeable+0x3b3/0x422 kernelinit+0x24/0x1e0 retfrom_fork+0x1f/0x30 </TASK>(CVE-2022-49907)

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

ipvs: fix WARNING in _ipvscleanupbatch()

During the initialization of ipvsconnnetinit(), if file ipvsconn or ipvsconnsync fails to be created, the initialization is successful by default. Therefore, the ipvsconn or ipvsconnsync file doesn't be found during the remove.

The following is the stack information: name 'ipvsconnsync' WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712 removeprocentry+0x389/0x460 Modules linked in: Workqueue: netns cleanupnet RIP: 0010:removeprocentry+0x389/0x460 Call Trace: <TASK> _ipvscleanupbatch+0x7d/0x120 opsexitlist+0x125/0x170 cleanupnet+0x4ea/0xb00 processonework+0x9bf/0x1710 workerthread+0x665/0x1080 kthread+0x2e4/0x3a0 retfromfork+0x1f/0x30 </TASK>(CVE-2022-49918)

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

net: sched: Fix use after free in red_enqueue()

We can't use "skb" again after passing it to qdiscenqueue(). This is basically identical to commit 2f09707d0c97 ("schsfb: Also store skb len before calling child enqueue").(CVE-2022-49921)

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

wifi: mac80211: Fix UAF in ieee80211scanrx()

ieee80211scanrx() tries to access scanreq->flags after a null check, but a UAF is observed when the scan is completed and _ieee80211scancompleted() executes, which then calls cfg80211scandone() leading to the freeing of scan_req.

Since scanreq is rcudereference()'d, prevent the racing in _ieee80211scancompleted() by ensuring that from mac80211's POV it is no longer accessed from an RCU read critical section before we call cfg80211scan_done().(CVE-2022-49934)

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

cifs: fix small mempool leak in SMB2_negotiate()

In some cases of failure (dialect mismatches) in SMB2negotiate(), after the request is sent, the checks would return -EIO when they should be rather setting rc = -EIO and jumping to negexit to free the response buffer from mempool.(CVE-2022-49938)

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

wifi: mac80211: Don't finalize CSA in IBSS mode if state is disconnected

When we are not connected to a channel, sending channel "switch" announcement doesn't make any sense.

The BSS list is empty in that case. This causes the for loop in cfg80211getbss() to be bypassed, so the function returns NULL (check line 1424 of net/wireless/scan.c), causing the WARNON() in ieee80211ibsscsabeacon() to get triggered (check line 500 of net/mac80211/ibss.c), which was consequently reported on the syzkaller dashboard.

Thus, check if we have an existing connection before generating the CSA beacon in ieee80211ibssfinish_csa().(CVE-2022-49942)

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

vt: Clear selection before changing the font

When changing the console font with ioctl(KDFONTOP) the new font size can be bigger than the previous font. A previous selection may thus now be outside of the new screen size and thus trigger out-of-bounds accesses to graphics memory if the selection is removed in vcdoresize().

Prevent such out-of-memory accesses by dropping the selection before the various confontset() console handlers are called.(CVE-2022-49948)

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

arm64: cacheinfo: Fix incorrect assignment of signed error value to unsigned fw_level

Though acpifindlastcachelevel() always returned signed value and the document states it will return any errors caused by lack of a PPTT table, it never returned negative values before.

Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage") however changed it by returning -ENOENT if no PPTT was found. The value returned from acpifindlastcachelevel() is then assigned to unsigned fw_level.

It will result in the number of cache leaves calculated incorrectly as a huge value which will then cause the following warning from _allocpages as the order would be great than MAX_ORDER because of incorrect and huge cache leaves value.

| WARNING: CPU: 0 PID: 1 at mm/pagealloc.c:5407 _allocpages+0x74/0x314 | Modules linked in: | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-10393-g7c2a8d3ac4c0 #73 | pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : _allocpages+0x74/0x314 | lr : allocpages+0xe8/0x318 | Call trace: | _allocpages+0x74/0x314 | allocpages+0xe8/0x318 | kmallocordertrace+0x68/0x1dc | _kmalloc+0x240/0x338 | detectcacheattributes+0xe0/0x56c | updatesiblingsmasks+0x38/0x284 | storecputopology+0x78/0x84 | smppreparecpus+0x48/0x134 | kernelinitfreeable+0xc4/0x14c | kernelinit+0x2c/0x1b4 | retfrom_fork+0x10/0x20

Fix the same by changing fwlevel to be signed integer and return the error from initcache_level() early in case of error.(CVE-2022-49964)

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

drm/amd/display: clear optc underflow before turn off odm clock

[Why] After ODM clock off, optc underflow bit will be kept there always and clear not work. We need to clear that before clock off.

[How] Clear that if have when clock off.(CVE-2022-49969)

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

scsi: storvsc: Remove WQMEMRECLAIM from storvscerrorwq

storvscerrorwq workqueue should not be marked as WQMEMRECLAIM as it doesn't need to make forward progress under memory pressure. Marking this workqueue as WQMEMRECLAIM may cause deadlock while flushing a non-WQMEMRECLAIM workqueue. In the current state it causes the following warning:

[ 14.506347] ------------[ cut here ]------------ [ 14.506354] workqueue: WQMEMRECLAIM storvscerrorwq0:storvscremovelun is flushing !WQMEMRECLAIM eventsfreezablepower:diskeventsworkfn [ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 checkflushdependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 14.506393] Workqueue: storvscerrorwq0 storvscremovelun [ 14.506395] RIP: 0010:checkflushdependency+0xb5/0x130 <-snip-> [ 14.506408] Call Trace: [ 14.506412] _flushwork+0xf1/0x1c0 [ 14.506414] _cancelworktimer+0x12f/0x1b0 [ 14.506417] ? kernfsput+0xf0/0x190 [ 14.506418] canceldelayedworksync+0x13/0x20 [ 14.506420] diskblockevents+0x78/0x80 [ 14.506421] delgendisk+0x3d/0x2f0 [ 14.506423] srremove+0x28/0x70 [ 14.506427] devicereleasedriverinternal+0xef/0x1c0 [ 14.506428] devicereleasedriver+0x12/0x20 [ 14.506429] busremovedevice+0xe1/0x150 [ 14.506431] devicedel+0x167/0x380 [ 14.506432] _scsiremovedevice+0x11d/0x150 [ 14.506433] scsiremovedevice+0x26/0x40 [ 14.506434] storvscremovelun+0x40/0x60 [ 14.506436] processonework+0x209/0x400 [ 14.506437] workerthread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? processonework+0x400/0x400 [ 14.506441] ? kthreadpark+0x90/0x90 [ 14.506443] retfrom_fork+0x35/0x40 [ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]---(CVE-2022-49986)

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

md: call _mdstopwrites in mdstop

From the link [1], we can see raid1d was running even after the path raiddtr -> mdstop -> _mdstop.

Let's stop write first in destructor to align with normal md-raid to fix the KASAN issue.

[1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a(CVE-2022-49987)

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

xen/privcmd: fix error exit of privcmdioctldm_op()

The error exit of privcmdioctldmop() is calling unlockpages() potentially with pages being NULL, leading to a NULL dereference.

Additionally lockpages() doesn't check for pinuserpagesfast() having been completely successful, resulting in potentially not locking all pages into memory. This could result in sporadic failures when using the related memory in user mode.

Fix all of that by calling unlockpages() always with the real number of pinned pages, which will be zero in case pages being NULL, and by checking the number of pages pinned by pinuserpagesfast() matching the expected number of pages.(CVE-2022-49989)

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

drivers:md:fix a potential use-after-free bug

In line 2884, "raid5releasestripe(sh);" drops the reference to sh and may cause sh to be released. However, sh is subsequently used in lines 2886 "if (sh->batchhead && sh != sh->batchhead)". This may result in an use-after-free bug.

It can be fixed by moving "raid5releasestripe(sh);" to the bottom of the function.(CVE-2022-50022)

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

usb: host: ohci-ppc-of: Fix refcount leak bug

In ohcihcdppcofprobe(), offindcompatiblenode() will return a node pointer with refcount incremented. We should use ofnode_put() when it is not used anymore.(CVE-2022-50033)

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

iavf: Fix reset error handling

Do not call iavfclose in iavfresettask error handling. Doing so can lead to double call of napidisable, which can lead to deadlock there. Removing VF would lead to iavfremove task being stuck, because it requires critlock, which is held by iavfclose. Call iavfdisablevf if reset fail, so that driver will clean up remaining invalid resources. During rapid VF resets, HW can fail to setup VF mailbox. Wrong error handling can lead to iavfremove being stuck with: [ 5218.999087] iavf 0000:82:01.0: Failed to init adminq: -53 ... [ 5267.189211] INFO: task repro.sh:11219 blocked for more than 30 seconds. [ 5267.189520] Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1 [ 5267.189764] "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. [ 5267.190062] task:repro.sh state:D stack: 0 pid:11219 ppid: 8162 flags:0x00000000 [ 5267.190347] Call Trace: [ 5267.190647] <TASK> [ 5267.190927] _schedule+0x460/0x9f0 [ 5267.191264] schedule+0x44/0xb0 [ 5267.191563] schedulepreemptdisabled+0x14/0x20 [ 5267.191890] _mutexlock.isra.12+0x6e3/0xac0 [ 5267.192237] ? iavfremove+0xf9/0x6c0 [iavf] [ 5267.192565] iavfremove+0x12a/0x6c0 [iavf] [ 5267.192911] ? rawspinunlockirqrestore+0x1e/0x40 [ 5267.193285] pcideviceremove+0x36/0xb0 [ 5267.193619] devicereleasedriverinternal+0xc1/0x150 [ 5267.193974] pcistopbusdevice+0x69/0x90 [ 5267.194361] pcistopandremovebusdevice+0xe/0x20 [ 5267.194735] pciiovremovevirtfn+0xba/0x120 [ 5267.195130] sriovdisable+0x2f/0xe0 [ 5267.195506] icefreevfs+0x7d/0x2f0 [ice] [ 5267.196056] ? pcigetdevice+0x4f/0x70 [ 5267.196496] icesriovconfigure+0x78/0x1a0 [ice] [ 5267.196995] sriovnumvfsstore+0xfe/0x140 [ 5267.197466] kernfsfopwriteiter+0x12e/0x1c0 [ 5267.197918] newsyncwrite+0x10c/0x190 [ 5267.198404] vfswrite+0x24e/0x2d0 [ 5267.198886] ksyswrite+0x5c/0xd0 [ 5267.199367] dosyscall64+0x3a/0x80 [ 5267.199827] entrySYSCALL64afterhwframe+0x46/0xb0 [ 5267.200317] RIP: 0033:0x7f5b381205c8 [ 5267.200814] RSP: 002b:00007fff8c7e8c78 EFLAGS: 00000246 ORIGRAX: 0000000000000001 [ 5267.201981] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f5b381205c8 [ 5267.202620] RDX: 0000000000000002 RSI: 00005569420ee900 RDI: 0000000000000001 [ 5267.203426] RBP: 00005569420ee900 R08: 000000000000000a R09: 00007f5b38180820 [ 5267.204327] R10: 000000000000000a R11: 0000000000000246 R12: 00007f5b383c06e0 [ 5267.205193] R13: 0000000000000002 R14: 00007f5b383bb880 R15: 0000000000000002 [ 5267.206041] </TASK> [ 5267.206970] Kernel panic - not syncing: hungtask: blocked tasks [ 5267.207809] CPU: 48 PID: 551 Comm: khungtaskd Kdump: loaded Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1 [ 5267.208726] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019 [ 5267.209623] Call Trace: [ 5267.210569] <TASK> [ 5267.211480] dumpstacklvl+0x33/0x42 [ 5267.212472] panic+0x107/0x294 [ 5267.213467] watchdog.cold.8+0xc/0xbb [ 5267.214413] ? procdohungtasktimeoutsecs+0x30/0x30 [ 5267.215511] kthread+0xf4/0x120 [ 5267.216459] ? kthreadcompleteandexit+0x20/0x20 [ 5267.217505] retfrom_fork+0x22/0x30 [ 5267.218459] </TASK>(CVE-2022-50053)

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

net: atlantic: fix aq_vec index out of range error

The final update statement of the for loop exceeds the array range, the dereference of self->aq_vec[i] is not checked and then leads to the index out of range error. Also fixed this kind of coding style in other for loop.

[ 97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aqnic.c:1404:48 [ 97.937607] index 8 is out of range for type 'aqvecs *[8]' [ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2 [ 97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022 [ 97.937611] Workqueue: eventsunbound asyncrunentryfn [ 97.937616] Call Trace: [ 97.937617] <TASK> [ 97.937619] dumpstacklvl+0x49/0x63 [ 97.937624] dumpstack+0x10/0x16 [ 97.937626] ubsanepilogue+0x9/0x3f [ 97.937627] _ubsanhandleoutofbounds.cold+0x44/0x49 [ 97.937629] ? _scmsend+0x348/0x440 [ 97.937632] ? aqvecstop+0x72/0x80 [atlantic] [ 97.937639] aqnicstop+0x1b6/0x1c0 [atlantic] [ 97.937644] aqsuspendcommon+0x88/0x90 [atlantic] [ 97.937648] aqpmsuspendpoweroff+0xe/0x20 [atlantic] [ 97.937653] pcipmsuspend+0x7e/0x1a0 [ 97.937655] ? pcipmsuspendnoirq+0x2b0/0x2b0 [ 97.937657] dpmruncallback+0x54/0x190 [ 97.937660] _devicesuspend+0x14c/0x4d0 [ 97.937661] asyncsuspend+0x23/0x70 [ 97.937663] asyncrunentryfn+0x33/0x120 [ 97.937664] processonework+0x21f/0x3f0 [ 97.937666] workerthread+0x4a/0x3c0 [ 97.937668] ? processonework+0x3f0/0x3f0 [ 97.937669] kthread+0xf0/0x120 [ 97.937671] ? kthreadcompleteandexit+0x20/0x20 [ 97.937672] retfromfork+0x22/0x30 [ 97.937676] </TASK>

v2. fixed "warning: variable 'aq_vec' set but not used"

v3. simplified a for loop(CVE-2022-50066)

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

dm raid: fix address sanitizer warning in raid_status

There is this warning when using a kernel with the address sanitizer and running this testsuite: https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid

================================================================== BUG: KASAN: slab-out-of-bounds in raidstatus+0x1747/0x2820 [dmraid] Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319 CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> dumpstacklvl+0x6a/0x9c printaddressdescription.constprop.0+0x1f/0x1e0 printreport.cold+0x55/0x244 kasanreport+0xc9/0x100 raidstatus+0x1747/0x2820 [dmraid] dmimameasureontableload+0x4b8/0xca0 [dmmod] tableload+0x35c/0x630 [dmmod] ctlioctl+0x411/0x630 [dmmod] dmctlioctl+0xa/0x10 [dmmod] _x64sysioctl+0x12a/0x1a0 dosyscall64+0x5b/0x80

The warning is caused by reading conf->maxnrstripes in raidstatus. The code in raidstatus reads mddev->private, casts it to struct r5conf and reads the entry maxnrstripes.

However, if we have different raid type than 4/5/6, mddev->private doesn't point to struct r5conf; it may point to struct r0conf, struct r1conf, struct r10conf or struct mpconf. If we cast a pointer to one of these structs to struct r5conf, we will be reading invalid memory and KASAN warns about it.

Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6.(CVE-2022-50084)

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

dm raid: fix address sanitizer warning in raid_resume

There is a KASAN warning in raidresume when running the lvm test lvconvert-raid.sh. The reason for the warning is that mddev->raiddisks is greater than rs->raid_disks, so the loop touches one entry beyond the allocated length.(CVE-2022-50085)

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

firmware: armscpi: Ensure scpiinfo is not assigned if the probe fails

When scpi probe fails, at any point, we need to ensure that the scpiinfo is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could result use-after-free as the value is exported via getscpiops() and could refer to a memory allocated via devmkzalloc() but freed when the probe fails.(CVE-2022-50087)

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

scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts

Ensure SRB is returned during I/O timeout error escalation. If that is not possible fail the escalation path.

Following crash stack was seen:

BUG: unable to handle kernel paging request at 0000002f56aa90f8 IP: qlachkedifrxsadeletepending+0x14/0x30 [qla2xxx] Call Trace: ? qla2x00statusentry+0x19f/0x1c50 [qla2xxx] ? qla2x00startsp+0x116/0x1170 [qla2xxx] ? dmapoolalloc+0x1d6/0x210 ? mempoolalloc+0x54/0x130 ? qla24xxprocessresponsequeue+0x548/0x12b0 [qla2xxx] ? qladowork+0x2d/0x40 [qla2xxx] ? processonework+0x14c/0x390(CVE-2022-50098)

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

sched, cpuset: Fix dlcpubusy() panic due to empty cs->cpus_allowed

With cgroup v2, the cpuset's cpusallowed mask can be empty indicating that the cpuset will just use the effective CPUs of its parent. So cpusetcanattach() can call taskcanattach() with an empty mask. This can lead to cpumaskanyand() returns nrcpuids causing the call to dlbw_of() to crash due to percpu value access of an out of bound CPU value. For example:

[80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0
  :
[80468.191019] RIP: 0010:dl_cpu_busy+0x30/0x2b0
  :
[80468.207946] Call Trace:
[80468.208947]  cpuset_can_attach+0xa0/0x140
[80468.209953]  cgroup_migrate_execute+0x8c/0x490
[80468.210931]  cgroup_update_dfl_csses+0x254/0x270
[80468.211898]  cgroup_subtree_control_write+0x322/0x400
[80468.212854]  kernfs_fop_write_iter+0x11c/0x1b0
[80468.213777]  new_sync_write+0x11f/0x1b0
[80468.214689]  vfs_write+0x1eb/0x280
[80468.215592]  ksys_write+0x5f/0xe0
[80468.216463]  do_syscall_64+0x5c/0x80
[80468.224287]  entry_SYSCALL_64_after_hwframe+0x44/0xae

Fix that by using effectivecpus instead. For cgroup v1, effectivecpus is the same as cpusallowed. For v2, effectivecpus is the real cpumask to be used by tasks within the cpuset anyway.

Also update taskcanattach()'s 2nd argument name to cseffectivecpus to reflect the change. In addition, a check is added to taskcanattach() to guard against the possibility that cpumaskanyand() may return a value >= nrcpuids.(CVE-2022-50103)

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

RDMA/rxe: Fix error unwind in rxecreateqp()

In the function rxecreateqp(), rxeqpfrominit() is called to initialize qp, internally things like the spin locks are not setup until rxeqpinitreq().

If an error occures before this point then the unwind will call rxecleanup() and eventually to rxeqpdocleanup()/rxecleanuptask() which will oops when trying to access the uninitialized spinlock.

Move the spinlock initializations earlier before any failures.(CVE-2022-50127)

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

RDMA/hfi1: fix potential memory leak in setupbasectxt()

setupbasectxt() allocates a memory chunk for uctxt->groups with hfi1allocctxtrcvgroups(). When inituserctxt() fails, uctxt->groups is not released, which will lead to a memory leak.

We should release the uctxt->groups with hfi1freectxtrcvgroups() when inituserctxt() fails.(CVE-2022-50134)

A vulnerability, which was classified as critical, has been found in Linux Kernel up to 5.19.1 (Operating System).Using CWE to declare the problem leads to CWE-911. The product uses a reference count to manage a resource, but it does not update or incorrectly updates the reference count.Impacted is availability.Upgrading to version 4.14.291, 4.19.256, 5.4.211, 5.10.137, 5.15.61, 5.18.18 or 5.19.2 eliminates this vulnerability. Applying the patch 995fb2874bb5696357846a91e59181c600e6aac8/d10855876a6f47add6ff621cef25cc0171dac162/80b1465b2ae81ebb59bbe62bcb7a7f7d4e9ece6f/941ef6997f9db704fe4fd62fc01e420fdd5048b2/d5730780e9ea84e5476752a47c749036c6a74af5/a74322d4b897ddc268b340c4a397f6066c2f945d/babd7b0124650ab71a6487e38588b8659b3aa2dc/77087a04c8fd554134bddcb8a9ff87b21f357926 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2022-50160)

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

drm/radeon: fix potential buffer overflow in nisetmcspecialregisters()

The last case label can write two buffers 'mcregaddress[j]' and 'mcdata[j]' with 'j' offset equal to SMCNISLANDSMCREGISTERARRAYSIZE since there are no checks for this value in both case labels after the last 'j++'.

Instead of changing '>' to '>=' there, add the bounds check at the start of the second 'case' (the first one already has it).

Also, remove redundant last checks for 'j' index bigger than array size. The expression is always false. Moreover, before or after the patch 'table->last' can be equal to SMCNISLANDSMCREGISTERARRAY_SIZE and it seems it can be a valid value.

Detected using the static analysis tool - Svace.(CVE-2022-50185)

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

regulator: of: Fix refcount leak bug in ofgetregulation_constraints()

We should call the ofnodeput() for the reference returned by ofgetchildbyname() which has increased the refcount.(CVE-2022-50191)

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

PM: hibernate: defer device probing when resuming from hibernation

syzbot is reporting hung task at miscopen() [1], for there is a race window of AB-BA deadlock which involves probecount variable. Currently waitfordeviceprobe() from snapshotopen() from miscopen() can sleep forever with miscmtx held if probe_count cannot become 0.

When a device is probed by hubevent() work function, probecount is incremented before the probe function starts, and probe_count is decremented after the probe function completed.

There are three cases that can prevent probe_count from dropping to 0.

(a) A device being probed stopped responding (i.e. broken/malicious hardware).

(b) A process emulating a USB device using /dev/raw-gadget interface stopped responding for some reason.

(c) New device probe requests keeps coming in before existing device probe requests complete.

The phenomenon syzbot is reporting is (b). A process which is holding systemtransitionmutex and miscmtx is waiting for probecount to become 0 inside waitfordeviceprobe(), but the probe function which is called from hubevent() work function is waiting for the processes which are blocked at mutexlock(&miscmtx) to respond via /dev/raw-gadget interface.

This patch mitigates (b) by deferring waitfordeviceprobe() from snapshotopen() to snapshotwrite() and snapshotioctl(). Please note that the possibility of (b) remains as long as any thread which is emulating a USB device via /dev/raw-gadget interface can be blocked by uninterruptible blocking operations (e.g. mutex_lock()).

Please also note that (a) and (c) are not addressed. Regarding (c), we should change the code to wait for only one device which contains the image for resuming from hibernation. I don't know how to address (a), for use of timeout for waitfordevice_probe() might result in loss of user data in the image. Maybe we should require the userland to wait for the image device before opening /dev/snapshot interface.(CVE-2022-50202)

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

md-raid10: fix KASAN warning

There's a KASAN warning in raid10removedisk when running the lvm test lvconvert-raid-reshape.sh. We fix this warning by verifying that the value "number" is valid.

BUG: KASAN: slab-out-of-bounds in raid10removedisk+0x61/0x2a0 [raid10] Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682

CPU: 3 PID: 124682 Comm: mdXraid10 Not tainted 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x34/0x44 printreport.cold+0x45/0x57a ? _locktextstart+0x18/0x18 ? raid10removedisk+0x61/0x2a0 [raid10] kasanreport+0xa8/0xe0 ? raid10removedisk+0x61/0x2a0 [raid10] raid10removedisk+0x61/0x2a0 [raid10] Buffer I/O error on dev dm-76, logical block 15344, async page read ? _mutexunlockslowpath.constprop.0+0x1e0/0x1e0 removeandaddspares+0x367/0x8a0 [mdmod] ? superwritten+0x1c0/0x1c0 [mdmod] ? mutextrylock+0xac/0x120 ? rawspinlock+0x72/0xc0 ? _rawspinlockbh+0xc0/0xc0 mdcheckrecovery+0x848/0x960 [mdmod] raid10d+0xcf/0x3360 [raid10] ? schedclockcpu+0x185/0x1a0 ? rberase+0x4d4/0x620 ? varwakefunction+0xe0/0xe0 ? psigroupchange+0x411/0x500 ? preemptcountsub+0xf/0xc0 ? rawspinlockirqsave+0x78/0xc0 ? _locktextstart+0x18/0x18 ? raid10syncrequest+0x36c0/0x36c0 [raid10] ? preemptcountsub+0xf/0xc0 ? _rawspinunlockirqrestore+0x19/0x40 ? deltimersync+0xa9/0x100 ? trytodeltimersync+0xc0/0xc0 ? rawspinlockirqsave+0x78/0xc0 ? _locktextstart+0x18/0x18 ? _rawspinunlockirq+0x11/0x24 ? _listdelentryvalid+0x68/0xa0 ? finishwait+0xa3/0x100 mdthread+0x161/0x260 [mdmod] ? unregistermdpersonality+0xa0/0xa0 [mdmod] ? rawspinlockirqsave+0x78/0xc0 ? preparetowaitevent+0x2c0/0x2c0 ? unregistermdpersonality+0xa0/0xa0 [mdmod] kthread+0x148/0x180 ? kthreadcompleteandexit+0x20/0x20 retfrom_fork+0x1f/0x30 </TASK>

Allocated by task 124495: kasansavestack+0x1e/0x40 _kasankmalloc+0x80/0xa0 setupconf+0x140/0x5c0 [raid10] raid10run+0x4cd/0x740 [raid10] mdrun+0x6f9/0x1300 [mdmod] raidctr+0x2531/0x4ac0 [dmraid] dmtableaddtarget+0x2b0/0x620 [dmmod] tableload+0x1c8/0x400 [dmmod] ctlioctl+0x29e/0x560 [dmmod] dmcompatctlioctl+0x7/0x20 [dmmod] _docompatsysioctl+0xfa/0x160 dosyscall64+0x90/0xc0 entrySYSCALL64afterhwframe+0x46/0xb0

Last potentially related work creation: kasansavestack+0x1e/0x40 _kasanrecordauxstack+0x9e/0xc0 kvfreecallrcu+0x84/0x480 timerfdrelease+0x82/0x140 L _fput+0xfa/0x400 taskworkrun+0x80/0xc0 exittousermodeprepare+0x155/0x160 syscallexittousermode+0x12/0x40 dosyscall64+0x42/0xc0 entrySYSCALL64afterhwframe+0x46/0xb0

Second to last potentially related work creation: kasansavestack+0x1e/0x40 _kasanrecordauxstack+0x9e/0xc0 kvfreecallrcu+0x84/0x480 timerfdrelease+0x82/0x140 _fput+0xfa/0x400 taskworkrun+0x80/0xc0 exittousermodeprepare+0x155/0x160 syscallexittousermode+0x12/0x40 dosyscall64+0x42/0xc0 entrySYSCALL64afterhwframe+0x46/0xb0

The buggy address belongs to the object at ffff889108f3d200 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte region [ffff889108f3d200, ffff889108f3d300)

The buggy address belongs to the physical page: page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c head:000000007ef2a34c order:2 compoundmapcount:0 compoundpincount:0 flags: 0x4000000000010200(slab|head|zone=2) raw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40 raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff889108f3d280: 00 00 ---truncated---(CVE-2022-50211)

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

usbnet: Fix linkwatch use-after-free on disconnect

usbnet uses the work usbnetdeferredkevent() to perform tasks which may sleep. On disconnect, completion of the work was originally awaited in ->ndo_stop(). But in 2003, that was moved to ->disconnect() by historic commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock":

https://git.kernel.org/tglx/history/c/0f138bbfd83c

The change was made because back then, the kernel's workqueue implementation did not allow waiting for a single work. One had to wait for completion of all work by calling flushscheduledwork(), and that could deadlock when waiting for usbnetdeferredkevent() with rtnlmutex held in ->ndostop().

The commit solved one problem but created another: It causes a use-after-free in USB Ethernet drivers aqc111.c, asixdevices.c, ax88179178a.c, ch9200.c and smsc75xx.c:

• If the drivers receive a link change interrupt immediately before disconnect, they raise EVENTLINKRESET in their (non-sleepable) ->status() callback and schedule usbnetdeferredkevent().
• usbnetdeferredkevent() invokes the driver's ->linkreset() callback, which calls netifcarrier_{on,off}().
• That in turn schedules the work linkwatch_event().

Because usbnetdeferredkevent() is awaited after unregisternetdev(), netifcarrier{on,off}() may operate on an unregistered netdev and linkwatchevent() may run after free_netdev(), causing a use-after-free.

In 2010, usbnet was changed to only wait for a single instance of usbnetdeferredkevent() instead of all work by commit 23f333a2bfaf ("drivers/net: don't use flushscheduledwork()").

Unfortunately the commit neglected to move the wait back to ->ndo_stop(). Rectify that omission at long last.(CVE-2022-50220)

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

KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0

Don't BUG/WARN on interrupt injection due to GIF being cleared, since it's trivial for userspace to force the situation via KVMSETVCPU_EVENTS (even if having at least a WARN there would be correct for KVM internally generated injections).

kernel BUG at arch/x86/kvm/svm/svm.c:3386! invalid opcode: 0000 [#1] SMP CPU: 15 PID: 926 Comm: smmtest Not tainted 5.17.0-rc3+ #264 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svminjectirq+0xab/0xb0 [kvmamd] Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Call Trace: <TASK> injectpendingevent+0x2f7/0x4c0 [kvm] kvmarchvcpuioctlrun+0x791/0x17a0 [kvm] kvmvcpuioctl+0x26d/0x650 [kvm] _x64sysioctl+0x82/0xb0 dosyscall64+0x3b/0xc0 entrySYSCALL64after_hwframe+0x44/0xae </TASK>(CVE-2022-50228)

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

ALSA: bcd2000: Fix a UAF bug on the error path of probing

When the driver fails in sndcardregister() at probe time, it will free the 'bcd2k->midiouturb' before killing it, which may cause a UAF bug.

The following log can reveal it:

[ 50.727020] BUG: KASAN: use-after-free in bcd2000inputcomplete+0x1f1/0x2e0 [sndbcd2000] [ 50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0 [ 50.729530] Call Trace: [ 50.732899] bcd2000inputcomplete+0x1f1/0x2e0 [sndbcd2000]

Fix this by adding usbkillurb() before usbfreeurb().(CVE-2022-50229)

A heap out-of-bounds write vulnerability in the Linux Kernel ipvlan network driver can be exploited to achieve local privilege escalation.The out-of-bounds write is caused by missing skb->cb initialization in the ipvlan network driver. The vulnerability is reachable if CONFIG_IPVLAN is enabled.We recommend upgrading past commit 90cbed5247439a966b645b34eb0a2e037836ea8e.(CVE-2023-3090)

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

net: tunnels: annotate lockless accesses to dev->needed_headroom

IP tunnels can apparently update dev->needed_headroom in their xmit path.

This patch takes care of three tunnels xmit, and also the core LLRESERVEDSPACE() and LLRESERVEDSPACE_EXTRA() helpers.

More changes might be needed for completeness.

BUG: KCSAN: data-race in iptunnelxmit / iptunnelxmit

read to 0xffff88815b9da0ec of 2 bytes by task 888 on cpu 1: iptunnelxmit+0x1270/0x1730 net/ipv4/iptunnel.c:803 _grexmit net/ipv4/ipgre.c:469 [inline] ipgrexmit+0x516/0x570 net/ipv4/ipgre.c:661 _netdevstartxmit include/linux/netdevice.h:4881 [inline] netdevstartxmit include/linux/netdevice.h:4895 [inline] xmitone net/core/dev.c:3580 [inline] devhardstartxmit+0x127/0x400 net/core/dev.c:3596 _devqueuexmit+0x1007/0x1eb0 net/core/dev.c:4246 devqueuexmit include/linux/netdevice.h:3051 [inline] neighdirectoutput+0x17/0x20 net/core/neighbour.c:1623 neighoutput include/net/neighbour.h:546 [inline] ipfinishoutput2+0x740/0x840 net/ipv4/ipoutput.c:228 ipfinishoutput+0xf4/0x240 net/ipv4/ipoutput.c:316 NFHOOKCOND include/linux/netfilter.h:291 [inline] ipoutput+0xe5/0x1b0 net/ipv4/ipoutput.c:430 dstoutput include/net/dst.h:444 [inline] iplocalout+0x64/0x80 net/ipv4/ipoutput.c:126 iptunnelxmit+0x34a/0x4b0 net/ipv4/iptunnelcore.c:82 iptunnelxmit+0x1451/0x1730 net/ipv4/iptunnel.c:813 _grexmit net/ipv4/ipgre.c:469 [inline] ipgrexmit+0x516/0x570 net/ipv4/ipgre.c:661 _netdevstartxmit include/linux/netdevice.h:4881 [inline] netdevstartxmit include/linux/netdevice.h:4895 [inline] xmitone net/core/dev.c:3580 [inline] devhardstartxmit+0x127/0x400 net/core/dev.c:3596 _devqueuexmit+0x1007/0x1eb0 net/core/dev.c:4246 devqueuexmit include/linux/netdevice.h:3051 [inline] neighdirectoutput+0x17/0x20 net/core/neighbour.c:1623 neighoutput include/net/neighbour.h:546 [inline] ipfinishoutput2+0x740/0x840 net/ipv4/ipoutput.c:228 ipfinishoutput+0xf4/0x240 net/ipv4/ipoutput.c:316 NFHOOKCOND include/linux/netfilter.h:291 [inline] ipoutput+0xe5/0x1b0 net/ipv4/ipoutput.c:430 dstoutput include/net/dst.h:444 [inline] iplocalout+0x64/0x80 net/ipv4/ipoutput.c:126 iptunnelxmit+0x34a/0x4b0 net/ipv4/iptunnelcore.c:82 iptunnelxmit+0x1451/0x1730 net/ipv4/iptunnel.c:813 _grexmit net/ipv4/ipgre.c:469 [inline] ipgrexmit+0x516/0x570 net/ipv4/ipgre.c:661 _netdevstartxmit include/linux/netdevice.h:4881 [inline] netdevstartxmit include/linux/netdevice.h:4895 [inline] xmitone net/core/dev.c:3580 [inline] devhardstartxmit+0x127/0x400 net/core/dev.c:3596 _devqueuexmit+0x1007/0x1eb0 net/core/dev.c:4246 devqueuexmit include/linux/netdevice.h:3051 [inline] neighdirectoutput+0x17/0x20 net/core/neighbour.c:1623 neighoutput include/net/neighbour.h:546 [inline] ipfinishoutput2+0x740/0x840 net/ipv4/ipoutput.c:228 ipfinishoutput+0xf4/0x240 net/ipv4/ipoutput.c:316 NFHOOKCOND include/linux/netfilter.h:291 [inline] ipoutput+0xe5/0x1b0 net/ipv4/ipoutput.c:430 dstoutput include/net/dst.h:444 [inline] iplocalout+0x64/0x80 net/ipv4/ipoutput.c:126 iptunnelxmit+0x34a/0x4b0 net/ipv4/iptunnelcore.c:82 iptunnelxmit+0x1451/0x1730 net/ipv4/iptunnel.c:813 _grexmit net/ipv4/ipgre.c:469 [inline] ipgrexmit+0x516/0x570 net/ipv4/ipgre.c:661 _netdevstartxmit include/linux/netdevice.h:4881 [inline] netdevstartxmit include/linux/netdevice.h:4895 [inline] xmitone net/core/dev.c:3580 [inline] devhardstartxmit+0x127/0x400 net/core/dev.c:3596 _devqueuexmit+0x1007/0x1eb0 net/core/dev.c:4246 devqueuexmit include/linux/netdevice.h:3051 [inline] neighdirectoutput+0x17/0x20 net/core/neighbour.c:1623 neighoutput include/net/neighbour.h:546 [inline] ipfinishoutput2+0x740/0x840 net/ipv4/ipoutput.c:228 ipfinishoutput+0xf4/0x240 net/ipv4/ipoutput.c:316 NFHOOKCOND include/linux/netfilter.h:291 [inline] ipoutput+0xe5/0x1b0 net/i ---truncated---(CVE-2023-53109)

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

bnxt_en: Fix out-of-bound memcpy() during ethtool -w

When retrieving the FW coredump using ethtool, it can sometimes cause memory corruption:

BUG: KFENCE: memory corruption in _bnxtgetcoredump+0x3ef/0x670 [bnxten] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): _bnxtgetcoredump+0x3ef/0x670 [bnxten] ethtoolgetdumpdata+0xdc/0x1a0 _devethtool+0xa1e/0x1af0 devethtool+0xa8/0x170 devioctl+0x1b5/0x580 sockdoioctl+0xab/0xf0 sockioctl+0x1ce/0x2e0 _x64sysioctl+0x87/0xc0 dosyscall64+0x5c/0xf0 entrySYSCALL64after_hwframe+0x78/0x80

...

This happens when copying the coredump segment list in bnxthwrmdbgdmadata() with the HWRMDBGCOREDUMPLIST FW command. The info->destbuf buffer is allocated based on the number of coredump segments returned by the FW. The segment list is then DMA'ed by the FW and the length of the DMA is returned by FW. The driver then copies this DMA'ed segment list to info->dest_buf.

In some cases, this DMA length may exceed the info->destbuf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->destbuf. The extra DMA data contains no useful information.

This code path is shared for the HWRMDBGCOREDUMPLIST and the HWRMDBGCOREDUMPRETRIEVE FW commands. The buffering is different for these 2 FW commands. To simplify the logic, we need to move the line to adjust the buffer length for HWRMDBGCOREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands.(CVE-2025-37911)

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

schhtb: make htbqlen_notify() idempotent

htbqlennotify() always deactivates the HTB class and in fact could trigger a warning if it is already deactivated. Therefore, it is not idempotent and not friendly to its callers, like fqcodeldequeue().

Let's make it idempotent to ease qdisctreereduce_backlog() callers' life.(CVE-2025-37932)

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

nfs: handle failure of nfsgetlock_context in unlock path

When memory is insufficient, the allocation of nfslockcontext in nfsgetlockcontext() fails and returns -ENOMEM. If we mistakenly treat an nfs4unlockdata structure (whose lctx member has been set to -ENOMEM) as valid and proceed to execute rpcruntask(), this will trigger a NULL pointer dereference in nfs4locku_prepare. For example:

BUG: kernel NULL pointer dereference, address: 000000000000000c PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 Workqueue: rpciod rpcasyncschedule RIP: 0010:nfs4lockuprepare+0x35/0xc2 Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3 RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246 RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40 RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38 R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030 R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30 FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0 Call Trace: <TASK> _rpcexecute+0xbc/0x480 rpcasyncschedule+0x2f/0x40 processonework+0x232/0x5d0 workerthread+0x1da/0x3d0 ? _pfxworkerthread+0x10/0x10 kthread+0x10d/0x240 ? _pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1a/0x30 </TASK> Modules linked in: CR2: 000000000000000c ---[ end trace 0000000000000000 ]---

Free the allocated nfs4unlockdata when nfsgetlockcontext() fails and return NULL to terminate subsequent rpcruntask, preventing NULL pointer dereference.(CVE-2025-38023)

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

RDMA/rxe: Fix slab-use-after-free Read in rxequeuecleanup bug

Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x7d/0xa0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcf/0x610 mm/kasan/report.c:489 kasanreport+0xb5/0xe0 mm/kasan/report.c:602 rxequeuecleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxequeue.c:195 rxecqcleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxecq.c:132 _rxecleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxepool.c:232 rxecreatecq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxeverbs.c:1109 createcq+0x658/0xb90 drivers/infiniband/core/uverbscmd.c:1052 ibuverbscreatecq+0xc7/0x120 drivers/infiniband/core/uverbscmd.c:1095 ibuverbswrite+0x969/0xc90 drivers/infiniband/core/uverbsmain.c:679 vfswrite fs/readwrite.c:677 [inline] vfswrite+0x26a/0xcc0 fs/readwrite.c:659 ksyswrite+0x1b8/0x200 fs/readwrite.c:731 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xaa/0x1b0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

In the function rxecreatecq, when rxecqfrominit fails, the function rxecleanup will be called to handle the allocated resources. In fact, some memory resources have already been freed in the function rxecqfrom_init. Thus, this problem will occur.

The solution is to let rxe_cleanup do all the work.(CVE-2025-38024)

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

dm: fix unconditional IO throttle caused by REQ_PREFLUSH

When a bio with REQPREFLUSH is submitted to dm, _sendemptyflush() generates a flushbio with REQOPWRITE | REQPREFLUSH | REQSYNC, which causes the flushbio to be throttled by wbt_wait().

An example from v5.4, similar problem also exists in upstream:

crash> bt 2091206
PID: 2091206  TASK: ffff2050df92a300  CPU: 109  COMMAND: "kworker/u260:0"
 #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8
 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4
 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4
 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4
 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc
 #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0
 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254
 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38
 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138
 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4
#10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs]
#11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs]
#12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs]
#13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs]
#14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs]
#15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs]
#16 [ffff800084a2fdb0] process_one_work at ffff800040111d08
#17 [ffff800084a2fe00] worker_thread at ffff8000401121cc
#18 [ffff800084a2fe70] kthread at ffff800040118de4

After commit 2def2845cc33 ("xfs: don't allow log IO to be throttled"), the metadata submitted by xlogwriteiclog() should not be throttled. But due to the existence of the dm layer, throttling flush_bio indirectly causes the metadata bio to be throttled.

Fix this by conditionally adding REQIDLE to flushbio.biopf, which makes wbtshouldthrottle() return false to avoid wbtwait().(CVE-2025-38063)

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

crypto: algifhash - fix double free in hashaccept

If accept(2) is called on socket type algifhash with MSGMORE flag set and cryptoahashimport fails, sk2 is freed. However, it is also freed in afalgrelease, leading to slab-use-after-free error.(CVE-2025-38079)