OESA-2025-1370

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ath5k: fix OOB in ath5keepromreadpcalinfo_5111

The bug was found during fuzzing. Stacktrace locates it in ath5keepromconvertpcalinfo5111. When none of the curve is selected in the loop, idx can go up to AR5KEEPROMNPDCURVES. The line makes pd out of bound. pd = &chinfo[pier].pdcurves[idx];

There are many OOB writes using pd later in the code. So I added a sanity check for idx. Checks for other loops involving AR5KEEPROMNPDCURVES are not needed as the loop index is not used outside the loops.

The patch is NOT tested with real device.

The following is the fuzzing report

BUG: KASAN: slab-out-of-bounds in ath5keepromreadpcalinfo_5111+0x126a/0x1390 [ath5k] Write of size 1 at addr ffff8880174a4d60 by task modprobe/214

CPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1 Call Trace: dumpstack+0x76/0xa0 printaddressdescription.constprop.0+0x16/0x200 ? ath5keepromreadpcalinfo5111+0x126a/0x1390 [ath5k] ? ath5keepromreadpcalinfo5111+0x126a/0x1390 [ath5k] _kasanreport.cold+0x37/0x7c ? ath5keepromreadpcalinfo5111+0x126a/0x1390 [ath5k] kasanreport+0xe/0x20 ath5keepromreadpcalinfo5111+0x126a/0x1390 [ath5k] ? apictimerinterrupt+0xa/0x20 ? ath5keeprominit11apcalfreq+0xbc0/0xbc0 [ath5k] ? ath5kpcieepromread+0x228/0x3c0 [ath5k] ath5keeprominit+0x2513/0x6290 [ath5k] ? ath5keeprominit11apcalfreq+0xbc0/0xbc0 [ath5k] ? usleeprange+0xb8/0x100 ? apictimerinterrupt+0xa/0x20 ? ath5keepromreadpcalinfo2413+0x2f20/0x2f20 [ath5k] ath5khwinit+0xb60/0x1970 [ath5k] ath5kinitah+0x6fe/0x2530 [ath5k] ? kasprintf+0xa6/0xe0 ? ath5kstop+0x140/0x140 [ath5k] ? devnotice+0xf6/0xf6 ? apictimerinterrupt+0xa/0x20 ath5kpciprobe.cold+0x29a/0x3d6 [ath5k] ? ath5kpcieepromread+0x3c0/0x3c0 [ath5k] ? mutexlock+0x89/0xd0 ? ath5kpcieepromread+0x3c0/0x3c0 [ath5k] localpciprobe+0xd3/0x160 pcideviceprobe+0x23f/0x3e0 ? pcideviceremove+0x280/0x280 ? pcideviceremove+0x280/0x280 reallyprobe+0x209/0x5d0(CVE-2021-47633)

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

scsi: zorro7xx: Fix a resource leak in zorro7xxremoveone()

The error handling path of the probe releases a resource that is not freed in the remove function. In some cases, a ioremap() must be undone.

Add the missing iounmap() call in the remove function.(CVE-2022-49095)

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

ath9k_htc: fix uninit value bugs

Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing field initialization.

In htcconnectservice() svcmetalen and pad are not initialized. Based on code it looks like in current skb there is no service data, so simply initialize svcmetalen to 0.

htcissuesend() does not initialize htcframehdr::control array. Based on firmware code, it will initialize it by itself, so simply zero whole array to make KMSAN happy

Fail logs:

BUG: KMSAN: kernel-usb-infoleak in usbsubmiturb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usbsubmiturb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hifusbsendregout drivers/net/wireless/ath/ath9k/hifusb.c:127 [inline] hifusbsend+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hifusb.c:479 htcissuesend drivers/net/wireless/ath/ath9k/htchst.c:34 [inline] htcconnectservice+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ...

Uninit was created at: slabpostallochook mm/slab.h:524 [inline] slaballocnode mm/slub.c:3251 [inline] _kmallocnodetrackcaller+0xe0c/0x1510 mm/slub.c:4974 kmallocreserve net/core/skbuff.c:354 [inline] _allocskb+0x545/0xf90 net/core/skbuff.c:426 allocskb include/linux/skbuff.h:1126 [inline] htcconnectservice+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htchst.c:258 ...

Bytes 4-7 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00

BUG: KMSAN: kernel-usb-infoleak in usbsubmiturb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usbsubmiturb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hifusbsendregout drivers/net/wireless/ath/ath9k/hifusb.c:127 [inline] hifusbsend+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hifusb.c:479 htcissuesend drivers/net/wireless/ath/ath9k/htchst.c:34 [inline] htcconnectservice+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ...

Uninit was created at: slabpostallochook mm/slab.h:524 [inline] slaballocnode mm/slub.c:3251 [inline] _kmallocnodetrackcaller+0xe0c/0x1510 mm/slub.c:4974 kmallocreserve net/core/skbuff.c:354 [inline] _allocskb+0x545/0xf90 net/core/skbuff.c:426 allocskb include/linux/skbuff.h:1126 [inline] htcconnectservice+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htchst.c:258 ...

Bytes 16-17 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00(CVE-2022-49235)

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

media: stk1160: If start stream fails, return buffers with VB2BUFSTATE_QUEUED

If the callback 'startstreaming' fails, then all queued buffers in the driver should be returned with state 'VB2BUFSTATEQUEUED'. Currently, they are returned with 'VB2BUFSTATE_ERROR' which is wrong. Fix this. This also fixes the warning:

[ 65.583633] WARNING: CPU: 5 PID: 593 at drivers/media/common/videobuf2/videobuf2-core.c:1612 vb2startstreaming+0xd4/0x160 [videobuf2common] [ 65.585027] Modules linked in: sndusbaudio sndhwdep sndusbmidilib sndrawmidi sndsochdmicodec dwhdmii2saudio saa7115 stk1160 videobuf2vmalloc videobuf2memops videobuf2v4l2 videobuf2common videodev mc crct10difce panfrost sndsocsimplecard sndsocaudiographcard sndsocspdiftx sndsocsimplecardutils gpusched phyrockchippcie sndsocrockchipi2s rockchipdrm analogixdp dwmipidsi dwhdmi cec drmkmshelper drm rtcrk808 rockchipsaradc industrialiotriggeredbuffer kfifobuf rockchipthermal pcierockchiphost iptables xtables ipv6 [ 65.589383] CPU: 5 PID: 593 Comm: v4l2src0:src Tainted: G W 5.16.0-rc4-62408-g32447129cb30-dirty #14 [ 65.590293] Hardware name: Radxa ROCK Pi 4B (DT) [ 65.590696] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 65.591304] pc : vb2startstreaming+0xd4/0x160 [videobuf2common] [ 65.591850] lr : vb2startstreaming+0x6c/0x160 [videobuf2common] [ 65.592395] sp : ffff800012bc3ad0 [ 65.592685] x29: ffff800012bc3ad0 x28: 0000000000000000 x27: ffff800012bc3cd8 [ 65.593312] x26: 0000000000000000 x25: ffff00000d8a7800 x24: 0000000040045612 [ 65.593938] x23: ffff800011323000 x22: ffff800012bc3cd8 x21: ffff00000908a8b0 [ 65.594562] x20: ffff00000908a8c8 x19: 00000000fffffff4 x18: ffffffffffffffff [ 65.595188] x17: 000000040044ffff x16: 00400034b5503510 x15: ffff800011323f78 [ 65.595813] x14: ffff000013163886 x13: ffff000013163885 x12: 00000000000002ce [ 65.596439] x11: 0000000000000028 x10: 0000000000000001 x9 : 0000000000000228 [ 65.597064] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff726c5e78 [ 65.597690] x5 : ffff800012bc3990 x4 : 0000000000000000 x3 : ffff000009a34880 [ 65.598315] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000007cd99f0 [ 65.598940] Call trace: [ 65.599155] vb2startstreaming+0xd4/0x160 [videobuf2common] [ 65.599672] vb2corestreamon+0x17c/0x1a8 [videobuf2common] [ 65.600179] vb2streamon+0x54/0x88 [videobuf2v4l2] [ 65.600619] vb2ioctlstreamon+0x54/0x60 [videobuf2v4l2] [ 65.601103] v4lstreamon+0x3c/0x50 [videodev] [ 65.601521] _videodoioctl+0x1a4/0x428 [videodev] [ 65.601977] videousercopy+0x320/0x828 [videodev] [ 65.602419] videoioctl2+0x3c/0x58 [videodev] [ 65.602830] v4l2ioctl+0x60/0x90 [videodev] [ 65.603227] _arm64sysioctl+0xa8/0xe0 [ 65.603576] invokesyscall+0x54/0x118 [ 65.603911] el0svccommon.constprop.3+0x84/0x100 [ 65.604332] doel0svc+0x34/0xa0 [ 65.604625] el0svc+0x1c/0x50 [ 65.604897] el0t64synchandler+0x88/0xb0 [ 65.605264] el0t64sync+0x16c/0x170 [ 65.605587] ---[ end trace 578e0ba07742170d ]---(CVE-2022-49247)

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

can: mcan: mcantxhandler(): fix use after free of skb

canputechoskb() will clone skb then free the skb. Move the canputechoskb() for the m_can version 3.0.x directly before the start of the xmit in hardware, similar to the 3.1.x branch.(CVE-2022-49275)

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

ocfs2: dlmfs: fix error handling of userdlmdestroy_lock

When userdlmdestroylock failed, it didn't clean up the flags it set before exit. For USERLOCKINTEARDOWN, if this function fails because of lock is still in used, next time when unlink invokes this function, it will return succeed, and then unlink will remove inode and dentry if lock is not in used(file closed), but the dlm lock is still linked in dlm lock resource, then when bast come in, it will trigger a panic due to user-after-free. See the following panic call trace. To fix this, USERLOCKINTEARDOWN should be reverted if fail. And also error should be returned if USERLOCKINTEARDOWN is set to let user know that unlink fail.

For the case of ocfs2dlmunlock failure, besides USERLOCKINTEARDOWN, USERLOCKBUSY is also required to be cleared. Even though spin lock is released in between, but USERLOCKINTEARDOWN is still set, for USERLOCKBUSY, if before every place that waits on this flag, USERLOCKINTEARDOWN is checked to bail out, that will make sure no flow waits on the busy flag set by userdlmdestroylock(), then we can simplely revert USERLOCKBUSY when ocfs2dlmunlock fails. Fix userdlmcluster_lock() which is the only function not following this.

[ 941.336392] (python,26174,16):dlmfsunlink:562 ERROR: unlink 004fb0000060000b5a90b8c847b72e1, error -16 from destroy [ 989.757536] ------------[ cut here ]------------ [ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173! [ 989.757876] invalid opcode: 0000 [#1] SMP [ 989.758027] Modules linked in: ksplice2zhuk2jribipoibnew(O) ksplice2zhuk2jr(O) mptctl mptbase xennetback xenblkback xengntalloc xengntdev xenevtchn cdcether usbnet mii ocfs2 jbd2 rpcsecgsskrb5 authrpcgss nfsv4 nfsv3 nfsacl nfs fscache lockd grace ocfs2dlmfs ocfs2stacko2cb ocfs2dlm ocfs2nodemanager ocfs2stackglue configfs bnx2fc fcoe libfcoe libfc scsitransportfc sunrpc ipmidevintf bridge stp llc rdsrdma rds bonding ibsdp ibipoib rdmaucm ibucm ibuverbs ibumad rdmacm ibcm iwcm falconlsmserviceable(PE) falconnfnetcontain(PE) mlx4vnic falconkal(E) falconlsmpinned13402(E) mlx4ib ibsa ibmad ibcore ibaddr xenfs xenprivcmd dmmultipath iTCOwdt iTCOvendorsupport pcspkr sbedac edaccore i2ci801 lpcich mfdcore ipmissif i2ccore ipmisi ipmimsghandler [ 989.760686] ioatdma sg ext3 jbd mbcache sdmod ahci libahci ixgbe dca ptp ppscore vxlan udptunnel ip6udptunnel megaraidsas mlx4core crc32cintel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsitcp qla4xxx iscsibootsysfs libiscsi scsitransportiscsi wmi dmmirror dmregionhash dmlog dmmod [last unloaded: ksplice2zhuk2jribipoibold] [ 989.761987] CPU: 10 PID: 19102 Comm: dlmthread Tainted: P OE 4.1.12-124.57.1.el6uek.x8664 #2 [ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021 [ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti: ffff88017f7c8000 [ 989.762848] RIP: e030:[<ffffffffc07d4316>] [<ffffffffc07d4316>] _userdlmqueuelockres.part.4+0x76/0x80 [ocfs2dlmfs] [ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246 [ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX: 0000000000000003 [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI: ffff880174d48170 [ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09: 0000000000000000 [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12: ffff880174d48008 [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15: ffff88021db7a000 [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000) knlGS:ffff880247480000 [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4: 0000000000042660 [ 989.765081] Stack: [ 989.765167] 00000000000 ---truncated---(CVE-2022-49337)

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

ata: pataocteoncf: Fix refcount leak in octeoncfprobe

offinddevicebynode() takes reference, we should use putdevice() to release it when not need anymore. Add missing putdevice() to avoid refcount leak.(CVE-2022-49354)

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

net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxxmdiosregister

ofgetchildbyname() returns a node pointer with refcount incremented, we should use ofnodeput() on it when done.

mv88e6xxxmdioregister() pass the device node to ofmdiobusregister(). We don't need the device node after it.

Add missing ofnodeput() to avoid refcount leak.(CVE-2022-49367)

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

um: Fix out-of-bounds read in LDT setup

syscallstubdata() expects the data_count parameter to be the number of longs, not bytes.

================================================================== BUG: KASAN: stack-out-of-bounds in syscallstubdata+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1

CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: showstack.cold+0x166/0x2a7 _dumpstack+0x3a/0x43 dumpstacklvl+0x1f/0x27 printreport.cold+0xdb/0xf81 kasanreport+0x119/0x1f0 kasancheckrange+0x3a3/0x440 memcpy+0x52/0x140 syscallstubdata+0x70/0xe0 writeldtentry+0xac/0x190 initnewldt+0x515/0x960 initnewcontext+0x2c4/0x4d0 mminit.constprop.0+0x5ed/0x760 mmalloc+0x118/0x170 0x60033f48 dooneinitcall+0x1d7/0x860 0x60003e7b kernelinit+0x6e/0x3d4 newthreadhandler+0x1e7/0x2c0

The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: initnewldt+0x0/0x960

This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ==================================================================(CVE-2022-49395)

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

phy: qcom-qmp: fix struct clk leak on probe errors

Make sure to release the pipe clock reference in case of a late probe error (e.g. probe deferral).(CVE-2022-49397)

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

dlm: fix plock invalid read

This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plockop" and a followed sendop() will append it to a global sendlist data structure. In some cases a followed devread() moves it to recvlist and devwrite() will cast it to "struct plock_xop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields.

To fix this issue the "callback" field is moved to "struct plockop" to indicate that a cast to "plockxop" is allowed and does the additional "plock_xop" handling if set.

Example of the KASAN output which showed the invalid read:

[ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in devwrite+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlmcontrold/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlmcontrold Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dumpstacklvl+0x56/0x7b [ 2064.313150] printaddressdescription.constprop.8+0x21/0x150 [ 2064.314578] ? devwrite+0x52b/0x5a0 [dlm] [ 2064.315610] ? devwrite+0x52b/0x5a0 [dlm] [ 2064.316595] kasanreport.cold.14+0x7f/0x11b [ 2064.317674] ? devwrite+0x52b/0x5a0 [dlm] [ 2064.318687] devwrite+0x52b/0x5a0 [dlm] [ 2064.319629] ? devread+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpflsmkernfsinitsecurity+0x10/0x10 [ 2064.321926] vfswrite+0x17e/0x930 [ 2064.322769] ? _fgetlight+0x1aa/0x220 [ 2064.323753] ksyswrite+0xf1/0x1c0 [ 2064.324548] ? _ia32sysread+0xb0/0xb0 [ 2064.325464] dosyscall64+0x3a/0x80 [ 2064.326387] entrySYSCALL64afterhwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIGRAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasansavestack+0x1c/0x40 [ 2064.345079] _kasankmalloc+0x84/0xa0 [ 2064.345933] kmemcachealloctrace+0x13b/0x220 [ 2064.346953] dlmposixunlock+0xec/0x720 [dlm] [ 2064.348811] dolockfilewait.part.32+0xca/0x1d0 [ 2064.351070] fcntlsetlk+0x281/0xbc0 [ 2064.352879] dofcntl+0x5e4/0xfe0 [ 2064.354657] _x64sysfcntl+0x11f/0x170 [ 2064.356550] dosyscall64+0x3a/0x80 [ 2064.358259] entrySYSCALL64afterhwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasansavestack+0x1c/0x40 [ 2064.365811] _kasanrecordauxstack+0xaf/0xc0 [ 2064.368100] callrcu+0x11b/0xf70 [ 2064.369785] dlmprocessincomingbuffer+0x47d/0xfd0 [dlm] [ 2064.372404] receivefromsock+0x290/0x770 [dlm] [ 2064.374607] processrecvsockets+0x32/0x40 [dlm] [ 2064.377290] processonework+0x9a8/0x16e0 [ 2064.379357] workerthread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] retfromfork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasansavestack+0x1c/0x40 [ 2064.391043] _kasanrecordauxstack+0xaf/0xc0 [ 2064.393303] callrcu+0x11b/0xf70 [ 2064.394885] dlmprocessincomingbuffer+0x47d/0xfd0 [dlm] [ 2064.397694] receivefrom_sock+0x290/0x770 ---truncated---(CVE-2022-49407)

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

wifi: mac80211: fix use-after-free in chanctx code

In ieee80211vifusereservedcontext(), when we have an old context and the new context's replacestate is set to IEEE80211CHANCTXREPLACENONE, we free the old context in ieee80211vifusereservedreassign(). Therefore, we cannot check the old_ctx anymore, so we should set it to NULL after this point.

However, since the newctx replace state is clearly not IEEE80211CHANCTXREPLACESOTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed old_ctx.(CVE-2022-49416)

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

f2fs: fix dereference of stale list iterator after loop body

The list iterator variable will be a bogus pointer if no break was hit. Dereferencing it (cur->page in this case) could load an out-of-bounds/undefined value making it unsafe to use that in the comparision to determine if the specific element was found.

Since 'cur->page' can be out-ouf-bounds it cannot be guaranteed that by chance (or intention of an attacker) it matches the value of 'page' even though the correct element was not found.

This is fixed by using a separate list iterator variable for the loop and only setting the original variable if a suitable element was found. Then determing if the element was found is simply checking if the variable is set.(CVE-2022-49425)

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

ARM: versatile: Add missing ofnodeput in dcscb_init

The devicenode pointer is returned by offindcompatiblenode with refcount incremented. We should use ofnodeput() to avoid the refcount leak.(CVE-2022-49457)

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

media: pvrusb2: fix array-index-out-of-bounds in pvr2i2ccore_init

Syzbot reported that -1 is used as array index. The problem was in missing validation check.

hdw->unit_number is initialized with -1 and then if init table walk fails this value remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the easiest fix for that.

hdw->workpoll initialization moved upper to prevent warning in _flushwork.(CVE-2022-49478)

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

ASoC: mxs-saif: Fix refcount leak in mxssaifprobe

ofparsephandle() returns a node pointer with refcount incremented, we should use ofnodeput() on it when done.(CVE-2022-49482)

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

ath9khtc: fix potential out of bounds access with invalid rxstatus->rskeyix

The "rxstatus->rskeyix" eventually gets passed to testbit() so we need to ensure that it is within the bitmap.

drivers/net/wireless/ath/ath9k/common.c:46 ath9kcmnrxaccept() error: passing untrusted data 'rxstats->rskeyix' to 'testbit()'(CVE-2022-49503)

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

ASoC: mediatek: Fix missing ofnodeput in mt2701wm8960machine_probe

This node pointer is returned by ofparsephandle() with refcount incremented in this function. Calling ofnodeput() to avoid the refcount leak.(CVE-2022-49517)

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

net: sfp: fix memory leak in sfp_probe()

sfpprobe() allocates a memory chunk from sfp with sfpalloc(). When devmaddaction() fails, sfp is not freed, which leads to a memory leak.

We should use devmaddactionorreset() instead of devmaddaction().(CVE-2022-49619)

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

tty: goldfish: Fix free_irq() on remove

Pass the correct devid to freeirq() to fix this splat when the driver is unbound:

WARNING: CPU: 0 PID: 30 at kernel/irq/manage.c:1895 freeirq Trying to free already-free IRQ 65 Call Trace: warnslowpathfmt freeirq goldfishttyremove platformremove deviceremove devicereleasedriverinternal devicedriverdetach unbindstore drvattrstore ...(CVE-2022-49724)

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

traceeventshist: add check for return value of 'createhistfield'

Function 'createhistfield' is called recursively at traceeventshist.c:1954 and can return NULL-value that's why we have to check it to avoid null pointer dereference.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-53005)

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

tracing: Make sure trace_printk() can output as soon as it can be used

Currently traceprintk() can be used as soon as earlytraceinit() is called from startkernel(). But if a crash happens, and "ftracedumpon_oops" is set on the kernel command line, all you get will be:

[ 0.456075] <idle>-0 0dN.2. 347519us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 353141us : Unknown type 6 [ 0.456075] <idle>-0 0dN.2. 358684us : Unknown type 6

This is because the traceprintk() event (type 6) hasn't been registered yet. That gets done via an earlyinitcall(), which may be early, but not early enough.

Instead of registering the traceprintk() event (and other ftrace events, which are not trace events) via an earlyinitcall(), have them registered at the same time that traceprintk() can be used. This way, if there is a crash before earlyinitcall(), then the trace_printk()s will actually be useful.(CVE-2023-53007)

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

nilfs2: do not force clear folio if buffer is referenced

Patch series "nilfs2: protect busy buffer heads from being force-cleared".

This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue.

This patch (of 2):

Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur.

One of the inconsistencies is that when nilfs2 calls markbufferdirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state:

WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 markbufferdirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: <TASK> nilfspalloccommitallocentry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfsifilecreateinode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfsnewinode+0x254/0x830 fs/nilfs2/inode.c:344 nilfsmkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfsmkdir+0x2f9/0x4f0 fs/namei.c:4257 domkdirat+0x264/0x3a0 fs/namei.c:4280 _dosysmkdirat fs/namei.c:4295 [inline] _sesysmkdirat fs/namei.c:4293 [inline] _x64sysmkdirat+0x87/0xa0 fs/namei.c:4293 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

The other is when nilfsbtreepropagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be:

WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfsbtreepropagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: <TASK> nilfsbmappropagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfscollectfiledata+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfssegctorapplybuffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfssegctorscanfile+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfssegctorcollectblocks fs/nilfs2/segment.c:1216 [inline] nilfssegctorcollect fs/nilfs2/segment.c:1540 [inline] nilfssegctordoconstruct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfssegctorconstruct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfssegctorthreadconstruct fs/nilfs2/segment.c:2587 [inline] nilfssegctorthread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 </TASK>

Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback.

Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.(CVE-2025-21722)

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

arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array

The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).(CVE-2025-21785)