OESA-2025-2406

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

memory: of: Fix refcount leak bug in ofgetddr_timings()

We should add the ofnodeput() when breaking out of foreachchildofnode() as it will automatically increase and decrease the refcount.(CVE-2022-50249)

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

drm/radeon: Add the missed acpiputtable() to fix memory leak

When the radeon driver reads the bios information from ACPI table in radeonacpivfctbios(), it misses to call acpiputtable() to release the ACPI memory after the init, so add acpiput_table() properly to fix the memory leak.

v2: fix text formatting (Alex)(CVE-2022-50275)

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

wifi: rtlwifi: Fix global-out-of-bounds bug in rtl8812aephysettxpower_limit()

There is a global-out-of-bounds reported by KASAN:

BUG: KASAN: global-out-of-bounds in rtl8812aeeqnbyte.part.0+0x3d/0x84 [rtl8821ae] Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411

CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D 6.1.0-rc8+ #144 e15588508517267d37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), Call Trace: <TASK> ... kasanreport+0xbb/0x1c0 _rtl8812aeeqnbyte.part.0+0x3d/0x84 [rtl8821ae] rtl8821aephybbconfig.cold+0x346/0x641 [rtl8821ae] rtl8821aehw_init+0x1f5e/0x79b0 [rtl8821ae] ... </TASK>

The root cause of the problem is that the comparison order of "pratesection" in _rtl8812aephysettxpowerlimit() is wrong. The _rtl8812aeeqnbyte() is used to compare the first n bytes of the two strings from tail to head, which causes the problem. In the rtl8812aephysettxpowerlimit(), it was originally intended to meet this requirement by carefully designing the comparison order. For example, "pregulation" and "pbandwidth" are compared in order of length from small to large, first is 3 and last is 4. However, the comparison order of "pratesection" dose not obey such order requirement, therefore when "pratesection" is "HT", when comparing from tail to head, it will lead to access out of bounds in _rtl8812aeeqnbyte(). As mentioned above, the rtl8812aeeqnbyte() has the same function as strcmp(), so just strcmp() is enough.

Fix it by removing rtl8812aeeqnbyte() and use strcmp() barely. Although it can be fixed by adjusting the comparison order of "pratesection", this may cause the value of "ratesection" to not be from 0 to 5. In addition, commit "21e4b0726dc6" not only moved driver from staging to regular tree, but also added setting txpower limit function during the driver config phase, so the problem was introduced by this commit.(CVE-2022-50279)

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

wifi: ath9k: verify the expected usb_endpoints are present

The bug arises when a USB device claims to be an ATH9K but doesn't have the expected endpoints. (In this case there was an interrupt endpoint where the driver expected a bulk endpoint.) The kernel needs to be able to handle such devices without getting an internal error.

usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usbsubmiturb+0xce2/0x1430 drivers/usb/core/urb.c:493 Modules linked in: CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events requestfirmwareworkfunc RIP: 0010:usbsubmiturb+0xce2/0x1430 drivers/usb/core/urb.c:493 Call Trace: ath9khifusballocrxurbs drivers/net/wireless/ath/ath9k/hifusb.c:908 [inline] ath9khifusballocurbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hifusb.c:1019 ath9khifusbdevinit drivers/net/wireless/ath/ath9k/hifusb.c:1109 [inline] ath9khifusbfirmwarecb+0x142/0x530 drivers/net/wireless/ath/ath9k/hifusb.c:1242 requestfirmwareworkfunc+0x12e/0x240 drivers/base/firmwareloader/main.c:1097 processonework+0x9af/0x1600 kernel/workqueue.c:2279 workerthread+0x61d/0x12f0 kernel/workqueue.c:2425 kthread+0x3b4/0x4a0 kernel/kthread.c:313 retfromfork+0x22/0x30 arch/x86/entry/entry64.S:299

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2022-50297)

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

ata: ahci: Match EMMAXSLOTS with SATAPMPMAX_PORTS

UBSAN complains about array-index-out-of-bounds: [ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41 [ 1.980709] kernel: index 15 is out of range for type 'ahciempriv [8]' [ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsieh8 Not tainted 5.15.0-25-generic #25-Ubuntu [ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010 [ 1.980718] kernel: Call Trace: [ 1.980721] kernel: <TASK> [ 1.980723] kernel: showstack+0x52/0x58 [ 1.980729] kernel: dumpstacklvl+0x4a/0x5f [ 1.980734] kernel: dumpstack+0x10/0x12 [ 1.980736] kernel: ubsanepilogue+0x9/0x45 [ 1.980739] kernel: _ubsanhandleoutofbounds.cold+0x44/0x49 [ 1.980742] kernel: ahciqcissue+0x166/0x170 [libahci] [ 1.980748] kernel: ataqcissue+0x135/0x240 [ 1.980752] kernel: ataexecinternalsg+0x2c4/0x580 [ 1.980754] kernel: ? vprintkdefault+0x1d/0x20 [ 1.980759] kernel: ataexecinternal+0x67/0xa0 [ 1.980762] kernel: satapmpread+0x8d/0xc0 [ 1.980765] kernel: satapmpreadgscr+0x3c/0x90 [ 1.980768] kernel: satapmpattach+0x8b/0x310 [ 1.980771] kernel: ataehrevalidateandattach+0x28c/0x4b0 [ 1.980775] kernel: ataehrecover+0x6b6/0xb30 [ 1.980778] kernel: ? ahcidohardreset+0x180/0x180 [libahci] [ 1.980783] kernel: ? ahcistopengine+0xb0/0xb0 [libahci] [ 1.980787] kernel: ? ahcidosoftreset+0x290/0x290 [libahci] [ 1.980792] kernel: ? traceeventraweventataehlinkautopsyqc+0xe0/0xe0 [ 1.980795] kernel: satapmpehrecover.isra.0+0x214/0x560 [ 1.980799] kernel: satapmperrorhandler+0x23/0x40 [ 1.980802] kernel: ahcierrorhandler+0x43/0x80 [libahci] [ 1.980806] kernel: atascsiporterrorhandler+0x2b1/0x600 [ 1.980810] kernel: atascsierror+0x9c/0xd0 [ 1.980813] kernel: scsierrorhandler+0xa1/0x180 [ 1.980817] kernel: ? scsiunjamhost+0x1c0/0x1c0 [ 1.980820] kernel: kthread+0x12a/0x150 [ 1.980823] kernel: ? setkthreadstruct+0x50/0x50 [ 1.980826] kernel: retfrom_fork+0x22/0x30 [ 1.980831] kernel: </TASK>

This happens because satapmpinitlinks() initialize link->pmp up to SATAPMPMAXPORTS while em_priv is declared as 8 elements array.

I can't find the maximum Enclosure Management ports specified in AHCI spec v1.3.1, but "12.2.1 LED message type" states that "Port Multiplier Information" can utilize 4 bits, which implies it can support up to 16 ports. Hence, use SATAPMPMAXPORTS as EMMAX_SLOTS to resolve the issue.

BugLink: https://bugs.launchpad.net/bugs/1970074(CVE-2022-50315)

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

crypto: cavium - prevent integer overflow loading firmware

The "code_length" value comes from the firmware file. If your firmware is untrusted realistically there is probably very little you can do to protect yourself. Still we try to limit the damage as much as possible. Also Smatch marks any data read from the filesystem as untrusted and prints warnings if it not capped correctly.

The "ntohl(ucode->code_length) * 2" multiplication can have an integer overflow.(CVE-2022-50330)

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

scsi: target: iscsi: Fix a race condition between login_work and the login thread

In case a malicious initiator sends some random data immediately after a login PDU; the iscsitargetskdataready() callback will schedule the loginwork and, at the same time, the negotiation may end without clearing the LOGINFLAGSINITIALPDU flag (because no additional PDU exchanges are required to complete the login).

The login has been completed but the loginwork function will find the LOGINFLAGSINITIALPDU flag set and will never stop from rescheduling itself; at this point, if the initiator drops the connection, the iscsitconn structure will be freed, loginwork will dereference a released socket structure and the kernel crashes.

BUG: kernel NULL pointer dereference, address: 0000000000000230 PF: supervisor write access in kernel mode PF: errorcode(0x0002) - not-present page Workqueue: events iscsitargetdologinrx [iscsitargetmod] RIP: 0010:rawreadlockbh+0x15/0x30 Call trace: iscsitargetdologinrx+0x75/0x3f0 [iscsitargetmod] processone_work+0x1e8/0x3c0

Fix this bug by forcing login_work to stop after the login has been completed and the socket callbacks have been restored.

Add a comment to clearify the return values of iscsitargetdo_login()(CVE-2022-50350)

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

Bluetooth: hci{ldisc,serdev}: check percpuinit_rwsem() failure

syzbot is reporting NULL pointer dereference at hciuartttyclose() [1], for rcusyncenter() is called without rcusyncinit() due to hciuartttyopen() ignoring percpuinitrwsem() failure.

While we are at it, fix that hciuartregisterdevice() ignores percpuinitrwsem() failure and hciuartunregisterdevice() does not call percpufreerwsem().(CVE-2022-50374)

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

staging: vmeuser: Fix possible UAF in tsi148dmalistadd

Smatch report warning as follows:

drivers/staging/vmeuser/vmetsi148.c:1757 tsi148dmalist_add() warn: '&entry->list' not removed from list

In tsi148dmalistadd(), the error path "goto errdma" will not remove entry->list from list->entries, but entry will be freed, then list traversal may cause UAF.

Fix by removeing it from list->entries before free().(CVE-2022-50384)

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

wifi: brcmfmac: fix use-after-free bug in brcmfnetdevstart_xmit()

> ret = brcmfprototxqueuedata(drvr, ifp->ifidx, skb);

may be schedule, and then complete before the line

> ndev->stats.tx_bytes += skb->len;

[ 46.912801] ================================================================== [ 46.920552] BUG: KASAN: use-after-free in brcmfnetdevstartxmit+0x718/0x8c8 [brcmfmac] [ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328 [ 46.935991] [ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1 [ 46.947255] Hardware name: [REDACTED] [ 46.954568] Call trace: [ 46.957037] dumpbacktrace+0x0/0x2b8 [ 46.960719] showstack+0x24/0x30 [ 46.964052] dumpstack+0x128/0x194 [ 46.967557] printaddressdescription.isra.0+0x64/0x380 [ 46.972877] _kasanreport+0x1d4/0x240 [ 46.976723] kasanreport+0xc/0x18 [ 46.980138] _asanreportload4noabort+0x18/0x20 [ 46.985027] brcmfnetdevstartxmit+0x718/0x8c8 [brcmfmac] [ 46.990613] devhardstartxmit+0x1bc/0xda0 [ 46.994894] schdirectxmit+0x198/0xd08 [ 46.998827] _qdiscrun+0x37c/0x1dc0 [ 47.002500] _devqueuexmit+0x1528/0x21f8 [ 47.006692] devqueuexmit+0x24/0x30 [ 47.010366] neighresolveoutput+0x37c/0x678 [ 47.014734] ipfinishoutput2+0x598/0x2458 [ 47.018927] _ipfinishoutput+0x300/0x730 [ 47.023118] ipoutput+0x2e0/0x430 [ 47.026530] iplocalout+0x90/0x140 [ 47.030117] igmpv3sendpack+0x14c/0x228 [ 47.034049] igmpv3sendcr+0x384/0x6b8 [ 47.037895] igmpifctimerexpire+0x4c/0x118 [ 47.042262] calltimerfn+0x1cc/0xbe8 [ 47.046021] _runtimers+0x4d8/0xb28 [ 47.049693] runtimersoftirq+0x24/0x40 [ 47.053626] _dosoftirq+0x2c0/0x117c [ 47.057387] irqexit+0x2dc/0x388 [ 47.060715] _handledomainirq+0xb4/0x158 [ 47.064908] gichandleirq+0x58/0xb0 [ 47.068581] el0irqnaked+0x50/0x5c [ 47.072162] [ 47.073665] Allocated by task 328: [ 47.077083] savestack+0x24/0xb0 [ 47.080410] _kasankmalloc.isra.0+0xc0/0xe0 [ 47.084776] kasanslaballoc+0x14/0x20 [ 47.088622] kmemcachealloc+0x15c/0x468 [ 47.092643] _allocskb+0xa4/0x498 [ 47.096142] igmpv3newpack+0x158/0xd78 [ 47.099987] addgrhead+0x210/0x288 [ 47.103485] addgrec+0x6b0/0xb70 [ 47.106811] igmpv3sendcr+0x2e0/0x6b8 [ 47.110657] igmpifctimerexpire+0x4c/0x118 [ 47.115027] calltimerfn+0x1cc/0xbe8 [ 47.118785] _runtimers+0x4d8/0xb28 [ 47.122457] runtimersoftirq+0x24/0x40 [ 47.126389] _dosoftirq+0x2c0/0x117c [ 47.130142] [ 47.131643] Freed by task 180: [ 47.134712] savestack+0x24/0xb0 [ 47.138041] _kasanslabfree+0x108/0x180 [ 47.142146] kasanslabfree+0x10/0x18 [ 47.145904] slabfreefreelisthook+0xa4/0x1b0 [ 47.150444] kmemcachefree+0x8c/0x528 [ 47.154292] kfreeskbmem+0x94/0x108 [ 47.157880] consumeskb+0x10c/0x5a8 [ 47.161466] _devkfreeskbany+0x88/0xa0 [ 47.165598] brcmupktbuffreeskb+0x44/0x68 [brcmutil] [ 47.171023] brcmftxfinalize+0xec/0x190 [brcmfmac] [ 47.176016] brcmfprotobcdctxcomplete+0x1c0/0x210 [brcmfmac] [ 47.182056] brcmfsdiosendfromq+0x8dc/0x1e80 [brcmfmac] [ 47.187568] brcmfsdiodpc+0xb48/0x2108 [brcmfmac] [ 47.192529] brcmfsdiodataworker+0xc8/0x238 [brcmfmac] [ 47.197859] processonework+0x7fc/0x1a80 [ 47.201965] workerthread+0x31c/0xc40 [ 47.205726] kthread+0x2d8/0x370 [ 47.208967] retfromfork+0x10/0x18 [ 47.212546] [ 47.214051] The buggy address belongs to the object at ffffff803f588280 [ 47.214051] which belongs to the cache skbuffhead_cache of size 208 [ 47.227086] The buggy address is located 104 bytes inside of [ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350) [ 47.238814] The buggy address belongs to the page: [ 47.243618] page:ffffffff00dd6200 refcount:1 mapcou ---truncated---(CVE-2022-50408)

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

Bluetooth: hcisysfs: Fix attempting to call deviceadd multiple times

device_add shall not be called multiple times as stated in its documentation:

'Do not call this routine or device_register() more than once for any device structure'

Syzkaller reports a bug as follows [1]: ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:33! invalid opcode: 0000 [#1] PREEMPT SMP KASAN [...] Call Trace: <TASK> _listadd include/linux/list.h:69 [inline] listaddtail include/linux/list.h:102 [inline] kobjksetjoin lib/kobject.c:164 [inline] kobjectaddinternal+0x18f/0x8f0 lib/kobject.c:214 kobjectaddvarg lib/kobject.c:358 [inline] kobjectadd+0x150/0x1c0 lib/kobject.c:410 deviceadd+0x368/0x1e90 drivers/base/core.c:3452 hciconnaddsysfs+0x9b/0x1b0 net/bluetooth/hcisysfs.c:53 hcilecisestabilishedevt+0x57c/0xae0 net/bluetooth/hcievent.c:6799 hcilemetaevt+0x2b8/0x510 net/bluetooth/hcievent.c:7110 hcieventfunc net/bluetooth/hcievent.c:7440 [inline] hcieventpacket+0x63d/0xfd0 net/bluetooth/hcievent.c:7495 hcirxwork+0xae7/0x1230 net/bluetooth/hcicore.c:4007 processonework+0x991/0x1610 kernel/workqueue.c:2289 workerthread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK>(CVE-2022-50419)

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

scsi: qla2xxx: Pointer may be dereferenced

Klocwork tool reported pointer 'rport' returned from call to function fcbsgto_rport() may be NULL and will be dereferenced.

Add a fix to validate rport before dereferencing.(CVE-2023-53150)

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

udf: Fix uninitialized array access for some pathnames

For filenames that begin with . and are between 2 and 5 characters long, UDF charset conversion code would read uninitialized memory in the output buffer. The only practical impact is that the name may be prepended a "unification hash" when it is not actually needed but still it is good to fix this.(CVE-2023-53165)

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

sched/fair: Don't balance task to its current running CPU

We've run into the case that the balancer tries to balance a migration disabled task and trigger the warning in settaskcpu() like below:

------------[ cut here ]------------ WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 settaskcpu+0x188/0x240 Modules linked in: hclgevf xtCHECKSUM iptREJECT nfrejectipv4 <...snip> CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1 Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021 pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : settaskcpu+0x188/0x240 lr : loadbalance+0x5d0/0xc60 sp : ffff80000803bc70 x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040 x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001 x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78 x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000 x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530 x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001 Call trace: settaskcpu+0x188/0x240 loadbalance+0x5d0/0xc60 rebalancedomains+0x26c/0x380 _nohzidlebalance.isra.0+0x1e0/0x370 runrebalancedomains+0x6c/0x80 dosoftirq+0x128/0x3d8 dosoftirq+0x18/0x24 callonirqstack+0x2c/0x38 dosoftirqownstack+0x24/0x3c _irqexitrcu+0xcc/0xf4 irqexitrcu+0x18/0x24 el1interrupt+0x4c/0xe4 el1h64irqhandler+0x18/0x2c el1h64irq+0x74/0x78 archcpuidle+0x18/0x4c defaultidlecall+0x58/0x194 doidle+0x244/0x2b0 cpustartupentry+0x30/0x3c secondarystartkernel+0x14c/0x190 _secondary_switched+0xb0/0xb4 ---[ end trace 0000000000000000 ]---

Further investigation shows that the warning is superfluous, the migration disabled task is just going to be migrated to its current running CPU. This is because that on load balance if the dstcpu is not allowed by the task, we'll re-select a newdstcpu as a candidate. If no task can be balanced to dstcpu we'll try to balance the task to the newdstcpu instead. In this case when the migration disabled task is not on CPU it only allows to run on its current CPU, load balance will select its current CPU as newdstcpu and later triggers the warning above.

The newdstcpu is chosen from the env->dstgrpmask. Currently it contains CPUs in schedgroupspan() and if we have overlapped groups it's possible to run into this case. This patch makes env->dstgrpmask of groupbalancemask() which exclude any CPUs from the busiest group and solve the issue. For balancing in a domain with no overlapped groups the behaviour keeps same as before.(CVE-2023-53215)

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

nfsd: call oprelease, even when opfunc returns an error

For ops with "trivial" replies, nfsd4encodeoperation will shortcut most of the encoding work and skip to just marshalling up the status. One of the things it skips is calling op_release. This could cause a memory leak in the layoutget codepath if there is an error at an inopportune time.

Have the compound processing engine always call oprelease, even when opfunc sets an error in op->status. With this change, we also need nfsd4blockgetdeviceinfoscsi to set the gddevice pointer to NULL on error to avoid a double free.(CVE-2023-53241)

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

VMCI: check context->notifypage after call to getuserpagesfast() to avoid GPF

The call to getuserpagesfast() in vmcihostsetupnotify() can return NULL context->notifypage causing a GPF. To avoid GPF check if context->notifypage == NULL and return error if so.

general protection fault, probably for non-canonical address 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0x0005088000000300- 0x0005088000000307] CPU: 2 PID: 26180 Comm: repro34802241 Not tainted 6.1.0-rc4 #1 Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014 RIP: 0010:vmcictxchecksignalnotify+0x91/0xe0 Call Trace: <TASK> vmcihostunlockedioctl+0x362/0x1f40 _x64sysioctl+0x1a1/0x230 dosyscall64+0x3a/0x90 entrySYSCALL64after_hwframe+0x63/0xcd(CVE-2023-53259)

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

udf: Do not update file length for failed writes to inline files

When write to inline file fails (or happens only partly), we still updated length of inline data as if the whole write succeeded. Fix the update of length of inline data to happen only if the write succeeds.(CVE-2023-53295)

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

rbd: avoid use-after-free in dorbdadd() when rbddevcreate() fails

If getting an ID or setting up a work queue in rbddevcreate() fails, use-after-free on rbddev->rbdclient, rbddev->spec and rbddev->opts is triggered in dorbdadd(). The root cause is that the ownership of these structures is transfered to rbddev prematurely and they all end up getting freed when rbddevcreate() calls rbddevfree() prior to returning to dorbd_add().

Found by Linux Verification Center (linuxtesting.org) with SVACE, an incomplete patch submitted by Natalia Petrova <(CVE-2023-53307)

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

recordmcount: Fix memory leaks in the uwrite function

Common realloc mistake: 'file_append' nulled but not freed upon failure(CVE-2023-53318)

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

btrfs: fix BUGON condition in btrfscancel_balance

Pausing and canceling balance can race to interrupt balance lead to BUGON panic in btrfscancelbalance. The BUGON condition in btrfscancelbalance does not take this race scenario into account.

However, the race condition has no other side effects. We can fix that.

Reproducing it with panic trace like this:

kernel BUG at fs/btrfs/volumes.c:4618! RIP: 0010:btrfscancelbalance+0x5cf/0x6a0 Call Trace: <TASK> ? donanosleep+0x60/0x120 ? hrtimernanosleep+0xb7/0x1a0 ? schedcoreclonecookie+0x70/0x70 btrfsioctlbalancectl+0x55/0x70 btrfsioctl+0xa46/0xd20 _x64sysioctl+0x7d/0xa0 dosyscall64+0x38/0x80 entrySYSCALL64afterhwframe+0x63/0xcd

Race scenario as follows: > mutexunlock(&fsinfo->balancemutex); > -------------------- > .......issue pause and cancel req in another thread > -------------------- > ret = _btrfsbalance(fsinfo); > > mutexlock(&fsinfo->balancemutex); > if (ret == -ECANCELED && atomicread(&fsinfo->balancepausereq)) { > btrfsinfo(fsinfo, "balance: paused"); > btrfsexclopbalance(fsinfo, BTRFSEXCLOPBALANCE_PAUSED); > }(CVE-2023-53339)

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

ALSA: hda: Fix Oops by 9.1 surround channel names

getlineout_pfx() may trigger an Oops by overflowing the static array with more than 8 channels. This was reported for MacBookPro 12,1 with Cirrus codec.

As a workaround, extend for the 9.1 channels and also fix the potential Oops by unifying the code paths accessing the same array with the proper size check.(CVE-2023-53400)

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

firewire: net: fix use after free in fwnetfinishincoming_packet()

The netif_rx() function frees the skb so we can't dereference it to save the skb->len.(CVE-2023-53432)

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

media: uvcvideo: Handle cameras with invalid descriptors

If the source entity does not contain any pads, do not create a link.(CVE-2023-53437)

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

x86/MCE: Always save CS register on AMD Zen IF Poison errors

The Instruction Fetch (IF) units on current AMD Zen-based systems do not guarantee a synchronous #MC is delivered for poison consumption errors. Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the microarchitecture does guarantee that the exception is delivered within the same context. In other words, the exact rIP is not known, but the context is known to not have changed.

There is no architecturally-defined method to determine this behavior.

The Code Segment (CS) register is always valid on such IF unit poison errors regardless of the value of MCG_STATUS[EIPV|RIPV].

Add a quirk to save the CS register for poison consumption from the IF unit banks.

This is needed to properly determine the context of the error. Otherwise, the severity grading function will assume the context is IN_KERNEL due to the m->cs value being 0 (the initialized value). This leads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in kernel context.(CVE-2023-53438)

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

nfsd: handle getclientlocked() failure in nfsd4setclientidconfirm()

Lei Lu recently reported that nfsd4setclientidconfirm() did not check the return value from getclientlocked(). a SETCLIENTID_CONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF.

Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all.

In the case where the unconfirmed client is expiring, just fail and return the result from getclientlocked().(CVE-2025-38724)

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

tee: fix NULL pointer dereference in teeshmput

teeshmput have NULL pointer dereference:

_opteedisableshmcache --> shm = regpairtoptr(...);//shm maybe return NULL teeshmfree(shm); --> teeshm_put(shm);//crash

Add check in teeshmput to fix it.

panic log: Unable to handle kernel paging request at virtual address 0000000000100cca Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000 [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ---- 6.6.0-39-generic #38 Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07 Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0 10/26/2022 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : teeshmput+0x24/0x188 lr : teeshmfree+0x14/0x28 sp : ffff001f98f9faf0 x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000 x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048 x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88 x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003 x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101 x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca Call trace: teeshmput+0x24/0x188 teeshmfree+0x14/0x28 _opteedisableshmcache+0xa8/0x108 opteeshutdown+0x28/0x38 platformshutdown+0x28/0x40 deviceshutdown+0x144/0x2b0 kernelpoweroff+0x3c/0x80 hibernate+0x35c/0x388 statestore+0x64/0x80 kobjattrstore+0x14/0x28 sysfskfwrite+0x48/0x60 kernfsfopwriteiter+0x128/0x1c0 vfswrite+0x270/0x370 ksyswrite+0x6c/0x100 _arm64syswrite+0x20/0x30 invokesyscall+0x4c/0x120 el0svccommon.constprop.0+0x44/0xf0 doel0svc+0x24/0x38 el0svc+0x24/0x88 el0t64synchandler+0x134/0x150 el0t64_sync+0x14c/0x15(CVE-2025-39865)

In the Linux kernel, a use-after-free vulnerability exists in the markinodedirty() function. The issue occurs when _markinodedirty() obtains a bdiwriteback that is in the process of switching. This is a race condition vulnerability between inodeswitchwbsworkfn() and markinode_dirty(), causing the old writeback structure to be accessed after it has been released, triggering a use-after-free vulnerability.(CVE-2025-39866)

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

mm/memory-failure: fix VMBUGON_PAGE(PagePoisoned(page)) when unpoison memory

When I did memory failure tests, below panic occurs:

page dumped because: VMBUGONPAGE(PagePoisoned(page)) kernel BUG at include/linux/page-flags.h:616! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40 RIP: 0010:unpoisonmemory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Call Trace: <TASK> unpoisonmemory+0x2f3/0x590 simpleattrwritexsigned.constprop.0.isra.0+0xb3/0x110 debugfsattrwrite+0x42/0x60 fullproxywrite+0x5b/0x80 vfswrite+0xd5/0x540 ksyswrite+0x64/0xe0 dosyscall64+0xb9/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f08f0314887 RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887 RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001 RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009 R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 </TASK> Modules linked in: hwpoisoninject ---[ end trace 0000000000000000 ]--- RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---

The root cause is that unpoisonmemory() tries to check the PGHWPoison flags of an uninitialized page. So VMBUGON_PAGE(PagePoisoned(page)) is triggered. This can be reproduced by below steps:

1.Offline memory block:

echo offline > /sys/devices/system/memory/memory12/state

2.Get offlined memory pfn:

page-types -b n -rlN

3.Write pfn to unpoison-pfn

echo <pfn> > /sys/kernel/debug/hwpoison/unpoison-pfn

This scenario can be identified by pfntoonlinepage() returning NULL. And ZONEDEVICE pages are never expected, so we can simply fail if pfntoonline_page() == NULL to fix the bug.(CVE-2025-39883)