OESA-2026-1231

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

scsi: libsas: Fix use-after-free bug in smpexecutetask_sg()

When executing SMP task failed, the smpexecutetasksg() calls deltimer() to delete "slowtask->timer". However, if the timer handler sastaskinternaltimedout() is running, the deltimer() in smpexecutetasksg() will not stop it and a UAF will happen. The process is shown below:

  (thread 1)               |        (thread 2)

smpexecutetasksg() | sastaskinternaltimedout() ... | deltimer() | ... | ... sasfreetask(task) | kfree(task->slowtask) //FREE| | task->slow_task->... //USE

Fix by calling deltimersync() in smpexecutetasksg(), which makes sure the timer handler have finished before the "task->slowtask" is deallocated.(CVE-2022-50422)

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

ppp: associate skb with a device at tx

Syzkaller triggered flow dissector warning with the following:

r0 = openat$ppp(0xffffffffffffff9c, &(0x7f0000000000), 0xc0802, 0x0) ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0)) ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]}) pwritev(r0, &(0x7f0000000040)=[{&(0x7f0000000140)='\x00!', 0x2}], 0x1, 0x0, 0x0)

[ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flowdissector.c:1016 _skbflowdissect+0x1ee0/0x1fa0 [ 9.485929] skbgetpoff+0x53/0xa0 [ 9.485937] bpfskbgetpayoffset+0xe/0x20 [ 9.485944] ? pppsendframe+0xc2/0x5b0 [ 9.485949] ? rawspinunlockirqrestore+0x40/0x60 [ 9.485958] ? _pppxmitprocess+0x7a/0xe0 [ 9.485968] ? pppxmitprocess+0x5b/0xb0 [ 9.485974] ? pppwrite+0x12a/0x190 [ 9.485981] ? doiterwrite+0x18e/0x2d0 [ 9.485987] ? _importiovec+0x30/0x130 [ 9.485997] ? dopwritev+0x1b6/0x240 [ 9.486016] ? tracehardirqson+0x47/0x50 [ 9.486023] ? _x64syspwritev+0x24/0x30 [ 9.486026] ? dosyscall64+0x3d/0x80 [ 9.486031] ? entrySYSCALL64afterhwframe+0x63/0xcd

Flow dissector tries to find skb net namespace either via device or via socket. Neigher is set in pppsendframe, so let's manually use ppp->dev.(CVE-2022-50655)

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

RDMA/rxe: Fix "kernel NULL pointer dereference" error

When rxequeueinit in the function rxeqpinit_req fails, both qp->req.task.func and qp->req.task.arg are not initialized.

Because of creation of qp fails, the function rxecreateqp will call rxeqpdo_cleanup to handle allocated resource.

Before calling _rxedo_task, both qp->req.task.func and qp->req.task.arg should be checked.(CVE-2022-50671)

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

usb: idmouse: fix an uninit-value in idmouse_open

In idmousecreateimage, if any ftipcommand fails, it will go to the reset label. However, this leads to the data in bulkin_buffer[HEADER..IMGSIZE] uninitialized. And the check for valid image incurs an uninitialized dereference.

Fix this by moving the check before reset label since this check only be valid if the data after bulkinbuffer[HEADER] has concrete data.

Note that this is found by KMSAN, so only kernel compilation is tested.(CVE-2022-50733)

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

acct: fix potential integer overflow in encodecompt()

The integer overflow is descripted with following codes: > 317 static compt encodecomp_t(u64 value) > 318 { > 319 int exp, rnd; ...... > 341 exp <<= MANTSIZE; > 342 exp += value; > 343 return exp; > 344 }

Currently compt is defined as type of '_u16', but the variable 'exp' is type of 'int', so overflow would happen when variable 'exp' in line 343 is greater than 65535.(CVE-2022-50749)

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

udf: Avoid double brelse() in udf_rename()

syzbot reported a warning like below [1]:

VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 7301 at fs/buffer.c:1145 _brelse+0x67/0xa0 ... Call Trace: <TASK> invalidatebhlru+0x99/0x150 smpcallfunctionmanycond+0xe2a/0x10c0 ? genericremapfilerangeprep+0x50/0x50 ? _brelse+0xa0/0xa0 ? _mutexlock+0x21c/0x12d0 ? smpcalloncpu+0x250/0x250 ? rcureadlockschedheld+0xb/0x60 ? lockrelease+0x587/0x810 ? _brelse+0xa0/0xa0 ? genericremapfilerangeprep+0x50/0x50 oneachcpucondmask+0x3c/0x80 blkdevflushmapping+0x13a/0x2f0 blkdevputwhole+0xd3/0xf0 blkdevput+0x222/0x760 deactivatelockedsuper+0x96/0x160 deactivatesuper+0xda/0x100 cleanupmnt+0x222/0x3d0 taskworkrun+0x149/0x240 ? taskworkcancel+0x30/0x30 doexit+0xb29/0x2a40 ? reacquireheldlocks+0x4a0/0x4a0 ? dorawspinlock+0x12a/0x2b0 ? mmupdatenextowner+0x7c0/0x7c0 ? rwlockbug.part.0+0x90/0x90 ? zapotherthreads+0x234/0x2d0 dogroupexit+0xd0/0x2a0 _x64sysexitgroup+0x3a/0x50 dosyscall64+0x34/0xb0 entrySYSCALL64afterhwframe+0x63/0xcd

The cause of the issue is that brelse() is called on both ofibh.sbh and ofibh.ebh by udffindentry() when it returns NULL. However, brelse() is called by udfrename(), too. So, bcount on buffer_head becomes unbalanced.

This patch fixes the issue by not calling brelse() by udfrename() when udffind_entry() returns NULL.(CVE-2022-50755)

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

drm: Prevent drmcopyfield() to attempt copying a NULL pointer

There are some struct drmdriver fields that are required by drivers since drmcopyfield() attempts to copy them to user-space via DRMIOCTL_VERSION.

But it can be possible that a driver has a bug and did not set some of the fields, which leads to drmcopyfield() attempting to copy a NULL pointer:

[ +10.395966] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000 [ +0.010955] Mem abort info: [ +0.002835] ESR = 0x0000000096000004 [ +0.003872] EC = 0x25: DABT (current EL), IL = 32 bits [ +0.005395] SET = 0, FnV = 0 [ +0.003113] EA = 0, S1PTW = 0 [ +0.003182] FSC = 0x04: level 0 translation fault [ +0.004964] Data abort info: [ +0.002919] ISV = 0, ISS = 0x00000004 [ +0.003886] CM = 0, WnR = 0 [ +0.003040] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000115dad000 [ +0.006536] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ +0.006925] Internal error: Oops: 96000004 [#1] SMP ... [ +0.011113] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ +0.007061] pc : _pistrlen+0x14/0x150 [ +0.003895] lr : drmcopyfield+0x30/0x1a4 [ +0.004156] sp : ffff8000094b3a50 [ +0.003355] x29: ffff8000094b3a50 x28: ffff8000094b3b70 x27: 0000000000000040 [ +0.007242] x26: ffff443743c2ba00 x25: 0000000000000000 x24: 0000000000000040 [ +0.007243] x23: ffff443743c2ba00 x22: ffff8000094b3b70 x21: 0000000000000000 [ +0.007241] x20: 0000000000000000 x19: ffff8000094b3b90 x18: 0000000000000000 [ +0.007241] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab14b9af40 [ +0.007241] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ +0.007239] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa524ad67d4d8 [ +0.007242] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 6c6e6263606e7141 [ +0.007239] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ +0.007241] x2 : 0000000000000000 x1 : ffff8000094b3b90 x0 : 0000000000000000 [ +0.007240] Call trace: [ +0.002475] _pistrlen+0x14/0x150 [ +0.003537] drmversion+0x84/0xac [ +0.003448] drmioctlkernel+0xa8/0x16c [ +0.003975] drmioctl+0x270/0x580 [ +0.003448] _arm64sysioctl+0xb8/0xfc [ +0.003978] invokesyscall+0x78/0x100 [ +0.003799] el0svccommon.constprop.0+0x4c/0xf4 [ +0.004767] doel0svc+0x38/0x4c [ +0.003357] el0svc+0x34/0x100 [ +0.003185] el0t64synchandler+0x11c/0x150 [ +0.004418] el0t64sync+0x190/0x194 [ +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02) [ +0.006180] ---[ end trace 0000000000000000 ]---(CVE-2022-50884)

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

crypto: lib/mpi - avoid null pointer deref in mpicmpui()

During NVMeTCP Authentication a controller can trigger a kernel oops by specifying the 8192 bit Diffie Hellman group and passing a correctly sized, but zeroed Diffie Hellamn value. mpicmpui() was detecting this if the second parameter was 0, but 1 is passed from dhispubkeyvalid(). This causes the null pointer u->d to be dereferenced towards the end of mpicmp_ui()(CVE-2023-53817)

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

ip6vti: fix slab-use-after-free in decodesession6

When ipv6vti device is set to the qdisc of the sfb type, the cb field of the sent skb may be modified during enqueuing. Then, slab-use-after-free may occur when ipv6vti device sends IPv6 packets.

The stack information is as follows: BUG: KASAN: slab-use-after-free in decodesession6+0x103f/0x1890 Read of size 1 at addr ffff88802e08edc2 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0-next-20230707-00001-g84e2cad7f979 #410 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <IRQ> dumpstacklvl+0xd9/0x150 printaddressdescription.constprop.0+0x2c/0x3c0 kasanreport+0x11d/0x130 decodesession6+0x103f/0x1890 xfrmdecodesession+0x54/0xb0 vti6tnlxmit+0x3e6/0x1ee0 devhardstartxmit+0x187/0x700 schdirectxmit+0x1a3/0xc30 _qdiscrun+0x510/0x17a0 _devqueuexmit+0x2215/0x3b10 neighconnectedoutput+0x3c2/0x550 ip6finishoutput2+0x55a/0x1550 ip6finishoutput+0x6b9/0x1270 ip6output+0x1f1/0x540 ndiscsendskb+0xa63/0x1890 ndiscsendrs+0x132/0x6f0 addrconfrstimer+0x3f1/0x870 calltimerfn+0x1a0/0x580 expiretimers+0x29b/0x4b0 runtimersoftirq+0x326/0x910 _dosoftirq+0x1d4/0x905 irqexitrcu+0xb7/0x120 sysvecapictimerinterrupt+0x97/0xc0 </IRQ> Allocated by task 9176: kasansavestack+0x22/0x40 kasansettrack+0x25/0x30 _kasanslaballoc+0x7f/0x90 kmemcacheallocnode+0x1cd/0x410 kmallocreserve+0x165/0x270 _allocskb+0x129/0x330 netlinksendmsg+0x9b1/0xe30 socksendmsg+0xde/0x190 _syssendmsg+0x739/0x920 syssendmsg+0x110/0x1b0 _syssendmsg+0xf7/0x1c0 dosyscall64+0x39/0xb0 entrySYSCALL64afterhwframe+0x63/0xcd Freed by task 9176: kasansavestack+0x22/0x40 kasansettrack+0x25/0x30 kasansavefreeinfo+0x2b/0x40 kasanslabfree+0x160/0x1c0 slabfreefreelisthook+0x11b/0x220 kmemcachefree+0xf0/0x490 skbfreehead+0x17f/0x1b0 skbreleasedata+0x59c/0x850 consumeskb+0xd2/0x170 netlinkunicast+0x54f/0x7f0 netlinksendmsg+0x926/0xe30 socksendmsg+0xde/0x190 syssendmsg+0x739/0x920 syssendmsg+0x110/0x1b0 _syssendmsg+0xf7/0x1c0 dosyscall64+0x39/0xb0 entrySYSCALL64afterhwframe+0x63/0xcd The buggy address belongs to the object at ffff88802e08ed00 which belongs to the cache skbuffsmallhead of size 640 The buggy address is located 194 bytes inside of freed 640-byte region [ffff88802e08ed00, ffff88802e08ef80)

As commit f855691975bb ("xfrm6: Fix the nexthdr offset in decodesession6.") showed, xfrmdecodesession was originally intended only for the receive path. IP6CB(skb)->nhoff is not set during transmission. Therefore, set the cb field in the skb to 0 before sending packets.(CVE-2023-53821)

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

ubi: Fix UAF wear-leveling entry in eraseblkcountseq_show()

Wear-leveling entry could be freed in error path, which may be accessed again in eraseblkcountseq_show(), for example:

_eraseworker eraseblkcountseqshow wl = ubi->lookuptbl[*blocknumber] if (wl) wlentrydestroy ubi->lookuptbl[e->pnum] = NULL kmemcachefree(ubiwlentryslab, e) erasecount = wl->ec // UAF!

Wear-leveling entry updating/accessing in ubi->lookuptbl should be protected by ubi->wllock, fix it by adding ubi->wllock to serialize wl entry accessing between wlentrydestroy() and eraseblkcountseq_show().

Fetch a reproducer in [Link].(CVE-2023-53826)

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

md/raid10: fix null-ptr-deref in raid10syncrequest

initresync() inits mempool and sets conf->havereplacemnt at the beginning of sync, close_sync() frees the mempool when sync is completed.

After [1] recovery might be skipped and initresync() is called but closesync() is not. null-ptr-deref occurs with r10bio->dev[i].repl_bio.

The following is one way to reproduce the issue.

1) create a array, wait for resync to complete, mddev->recoverycp is set to MaxSector. 2) recovery is woken and it is skipped. conf->havereplacement is set to 0 in initresync(). closesync() not called. 3) some io errors and rdev A is set to WantReplacement. 4) a new device is added and set to A's replacement. 5) recovery is woken, A have replacement, but conf->havereplacemnt is 0. r10bio->dev[i].replbio will not be alloced and null-ptr-deref occurs.

Fix it by not calling init_resync() if recovery skipped.

[1] commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled")(CVE-2023-53832)

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

hwrng: virtio - Fix race on data_avail and actual data

The virtio rng device kicks off a new entropy request whenever the data available reaches zero. When a new request occurs at the end of a read operation, that is, when the result of that request is only needed by the next reader, then there is a race between the writing of the new data and the next reader.

This is because there is no synchronisation whatsoever between the writer and the reader.

Fix this by writing dataavail with smpstorerelease and reading it with smpload_acquire when we first enter read. The subsequent reads are safe because they're either protected by the first load acquire, or by the completion mechanism.

Also remove the redundant zeroing of dataidx in randomrecvdone (dataidx must already be zero at this point) and dataavail in requestentropy (ditto).(CVE-2023-53998)

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

scsi: qla2xxx: Check valid rport returned by fcbsgto_rport()

Klocwork reported warning of rport maybe NULL and will be dereferenced. rport returned by call to fcbsgto_rport() could be NULL and dereferenced.

Check valid rport returned by fcbsgto_rport().(CVE-2023-54014)

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

drm/client: Fix memory leak in drmclienttarget_cloned

dmt_mode is allocated and never freed in this function. It was found with the ast driver, but most drivers using generic fbdev setup are probably affected.

This fixes the following kmemleak report: backtrace: [<00000000b391296d>] drmmodeduplicate+0x45/0x220 [drm] [<00000000e45bb5b3>] drmclienttargetcloned.constprop.0+0x27b/0x480 [drm] [<00000000ed2d3a37>] drmclientmodesetprobe+0x6bd/0xf50 [drm] [<0000000010e5cc9d>] _drmfbhelperinitialconfigandunlock+0xb4/0x2c0 [drmkmshelper] [<00000000909f82ca>] drmfbdevclienthotplug+0x2bc/0x4d0 [drmkmshelper] [<00000000063a69aa>] drmclientregister+0x169/0x240 [drm] [<00000000a8c61525>] astpciprobe+0x142/0x190 [ast] [<00000000987f19bb>] localpciprobe+0xdc/0x180 [<000000004fca231b>] workforcpufn+0x4e/0xa0 [<0000000000b85301>] processonework+0x8b7/0x1540 [<000000003375b17c>] workerthread+0x70a/0xed0 [<00000000b0d43cd9>] kthread+0x29f/0x340 [<000000008d770833>] retfromfork+0x1f/0x30 unreferenced object 0xff11000333089a00 (size 128):(CVE-2023-54091)

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

md/raid10: fix memleak for 'conf->bio_split'

In the error path of raid10run(), 'conf' need be freed, however, 'conf->biosplit' is missed and memory will be leaked.

Since there are 3 places to free 'conf', factor out a helper to fix the problem.(CVE-2023-54123)

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

firmware: arm_sdei: Fix sleep from invalid context BUG

Running a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altra triggers:

BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:46 inatomic(): 0, irqsdisabled(): 128, nonblock: 0, pid: 24, name: cpuhp/0 preemptcount: 0, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by cpuhp/0/24: #0: ffffda30217c70d0 (cpuhotpluglock){++++}-{0:0}, at: cpuhpthreadfun+0x5c/0x248 #1: ffffda30217c7120 (cpuhpstate-up){+.+.}-{0:0}, at: cpuhpthreadfun+0x5c/0x248 #2: ffffda3021c711f0 (sdeilistlock){....}-{3:3}, at: sdeicpuhpup+0x3c/0x130 irq event stamp: 36 hardirqs last enabled at (35): [<ffffda301e85b7bc>] finishtaskswitch+0xb4/0x2b0 hardirqs last disabled at (36): [<ffffda301e812fec>] cpuhpthreadfun+0x21c/0x248 softirqs last enabled at (0): [<ffffda301e80b184>] copyprocess+0x63c/0x1ac0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...] Hardware name: WIWYNN Mt.Jade Server [...] Call trace: dumpbacktrace+0x114/0x120 showstack+0x20/0x70 dumpstacklvl+0x9c/0xd8 dumpstack+0x18/0x34 _mightresched+0x188/0x228 rtspinlock+0x70/0x120 sdeicpuhpup+0x3c/0x130 cpuhpinvokecallback+0x250/0xf08 cpuhpthreadfun+0x120/0x248 smpbootthreadfn+0x280/0x320 kthread+0x130/0x140 retfromfork+0x10/0x20

sdeicpuhpup() is called in the STARTING hotplug section, which runs with interrupts disabled. Use a CPUHPAPONLINE_DYN entry instead to execute the cpuhp cb later, with preemption enabled.

SDEI originally got its own cpuhp slot to allow interacting with perf. It got superseded by pNMI and this early slot is not relevant anymore. [1]

Some SDEI calls (e.g. SDEI10FNSDEIPEMASK) take actions on the calling CPU. It is checked that preemption is disabled for them. ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'. Preemption is enabled in those threads, but their cpumask is limited to 1 CPU. Move 'WARNON_ONCE(preemptible())' statements so that SDEI cpuhp cb don't trigger them.

Also add a check for the SDEI10FNSDEIPRIVATERESET SDEI call which acts on the calling CPU.

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

fbdev: bitblit: bound-check glyph index in bit_putcs*

bitputcsaligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address.

This fixes a global out-of-bounds read reported by syzbot.(CVE-2025-40322)