OESA-2025-1245

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

video: fbdev: smscufx: Fix null-ptr-deref in ufxusbprobe()

I got a null-ptr-deref report:

BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:fbdestroymodelist+0x38/0x100 ... Call Trace: ufxusbprobe.cold+0x2b5/0xac1 [smscufx] usbprobeinterface+0x1aa/0x3c0 [usbcore] reallyprobe+0x167/0x460 ... retfrom_fork+0x1f/0x30

If fballoccmap() fails in ufxusbprobe(), fbdestroymodelist() will be called to destroy modelist in the error handling path. But modelist has not been initialized yet, so it will result in null-ptr-deref.

Initialize modelist before calling fballoccmap() to fix this bug.(CVE-2021-47652)

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

ata: satadwc460ex: Fix crash due to OOB write

the driver uses libata's "tag" values from in various arrays. Since the mentioned patch bumped the ATATAGINTERNAL to 32, the value of the SATADWCQCMD_MAX needs to account for that.

Otherwise ATATAGINTERNAL usage cause similar crashes like this as reported by Tice Rex on the OpenWrt Forum and reproduced (with symbols) here:

| BUG: Kernel NULL pointer dereference at 0x00000000 | Faulting instruction address: 0xc03ed4b8 | Oops: Kernel access of bad area, sig: 11 [#1] | BE PAGESIZE=4K PowerPC 44x Platform | CPU: 0 PID: 362 Comm: scsieh1 Not tainted 5.4.163 #0 | NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c | REGS: cfa59950 TRAP: 0300 Not tainted (5.4.163) | MSR: 00021000 <CE,ME> CR: 42000222 XER: 00000000 | DEAR: 00000000 ESR: 00000000 | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...] | [..] | NIP [c03ed4b8] satadwcqcissue+0x14c/0x254 | LR [c03d27e8] ataqcissue+0x1c8/0x2dc | Call Trace: | [cfa59a08] [c003f4e0] _cancelworktimer+0x124/0x194 (unreliable) | [cfa59a78] [c03d27e8] ataqcissue+0x1c8/0x2dc | [cfa59a98] [c03d2b3c] ataexecinternalsg+0x240/0x524 | [cfa59b08] [c03d2e98] ataexecinternal+0x78/0xe0 | [cfa59b58] [c03d30fc] atareadlogpage.part.38+0x1dc/0x204 | [cfa59bc8] [c03d324c] ataidentifypagesupported+0x68/0x130 | [...]

This is because satadwcdmaxfercomplete() NULLs the dmapending's next neighbour "chan" (a *dmachan struct) in this '32' case right here (line ~735): > hsdevp->dmapending[tag] = SATADWCDMAPENDING_NONE;

Then the next time, a dma gets issued; dmadwcxfersetup() passes the NULL'd hsdevp->chan to the dmaengineslave_config() which then causes the crash.

With this patch, SATADWCQCMDMAX is now set to ATAMAXQUEUE + 1. This avoids the OOB. But please note, there was a worthwhile discussion on what ATATAGINTERNAL and ATAMAX_QUEUE is. And why there should not be a "fake" 33 command-long queue size.

Ideally, the dw driver should account for the ATATAGINTERNAL. In Damien Le Moal's words: "... having looked at the driver, it is a bigger change than just faking a 33rd "tag" that is in fact not a command tag at all."

BugLink: https://github.com/openwrt/openwrt/issues/9505(CVE-2022-49073)

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

drm/imx: Fix memory leak in imxpdconnectorgetmodes

Avoid leaking the display mode variable if ofgetdrmdisplaymode fails.

Addresses-Coverity-ID: 1443943 ("Resource leak")(CVE-2022-49091)

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

blk-iolatency: Fix inflight count imbalances and IO hangs on offline

iolatency needs to track the number of inflight IOs per cgroup. As this tracking can be expensive, it is disabled when no cgroup has iolatency configured for the device. To ensure that the inflight counters stay balanced, iolatencysetlimit() freezes the request_queue while manipulating the enabled counter, which ensures that no IO is in flight and thus all counters are zero.

Unfortunately, iolatencysetlimit() isn't the only place where the enabled counter is manipulated. iolatencypdoffline() can also dec the counter and trigger disabling. As this disabling happens without freezing the q, this can easily happen while some IOs are in flight and thus leak the counts.

This can be easily demonstrated by turning on iolatency on an one empty cgroup while IOs are in flight in other cgroups and then removing the cgroup. Note that iolatency shouldn't have been enabled elsewhere in the system to ensure that removing the cgroup disables iolatency for the whole device.

The following keeps flipping on and off iolatency on sda:

echo +io > /sys/fs/cgroup/cgroup.subtree_control while true; do mkdir -p /sys/fs/cgroup/test echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency sleep 1 rmdir /sys/fs/cgroup/test sleep 1 done

and there's concurrent fio generating direct rand reads:

fio --name test --filename=/dev/sda --direct=1 --rw=randread \ --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k

while monitoring with the following drgn script:

while True: for css in cssforeachdescendantpre(prog['blkcgroot'].css.addressof()): for pos in hlistforeach(containerof(css, 'struct blkcg', 'css').blkglist): blkg = containerof(pos, 'struct blkcggq', 'blkcgnode') pd = blkg.pd[prog['blkcgpolicyiolatency'].plid] if pd.value() == 0: continue iolat = containerof(pd, 'struct iolatencygrp', 'pd') inflight = iolat.rqwait.inflight.counter.value() if inflight: print(f'inflight={inflight} {diskname(blkg.q.disk).decode("utf-8")} ' f'{cgroup_path(css.cgroup).decode("utf-8")}') time.sleep(1)

The monitoring output looks like the following:

inflight=1 sda /user.slice inflight=1 sda /user.slice ... inflight=14 sda /user.slice inflight=13 sda /user.slice inflight=17 sda /user.slice inflight=15 sda /user.slice inflight=18 sda /user.slice inflight=17 sda /user.slice inflight=20 sda /user.slice inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 inflight=19 sda /user.slice inflight=19 sda /user.slice

If a cgroup with stuck inflight ends up getting throttled, the throttled IOs will never get issued as there's no completion event to wake it up leading to an indefinite hang.

This patch fixes the bug by unifying enable handling into a work item which is automatically kicked off from iolatencysetminlatnsec() which is called from both iolatencysetlimit() and iolatencypdoffline() paths. Punting to a work item is necessary as iolatencypdoffline() is called under spinlocks while freezing a request_queue requires a sleepable context.

This also simplifies the code reducing LOC sans the comments and avoids the unnecessary freezes which were happening whenever a cgroup's latency target is newly set or cleared.(CVE-2022-49394)

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

mm: hugetlb: independent PMD page table shared count

The folio refcount may be increased unexpectly through trygetfolio() by caller such as splithugepages. In hugepmdunshare(), we use refcount to check whether a pmd page table is shared. The check is incorrect if the refcount is increased by the above caller, and this can cause the page table leaked:

BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) pagetype: f2(table) raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BADPAGE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: showstack+0x20/0x38 (C) dumpstacklvl+0x80/0xf8 dumpstack+0x18/0x28 badpage+0x8c/0x130 freepageisbadreport+0xa4/0xb0 freeunrefpage+0x3cc/0x620 _folioput+0xf4/0x158 splithugepagesall+0x1e0/0x3e8 splithugepageswrite+0x25c/0x2d8 fullproxywrite+0x64/0xd8 vfswrite+0xcc/0x280 ksyswrite+0x70/0x110 _arm64syswrite+0x24/0x38 invokesyscall+0x50/0x120 el0svccommon.constprop.0+0xc8/0xf0 doel0svc+0x24/0x38 el0svc+0x34/0x128 el0t64synchandler+0xc8/0xd0 el0t64_sync+0x190/0x198

The issue may be triggered by damon, offlinepage, pageidle, etc, which will increase the refcount of page table.

1. The page table itself will be discarded after reporting the "nonzero mapcount".

2. The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared and a shared page table will not be unmapped.

Fix it by introducing independent PMD page table shared count. As described by comment, ptindex/ptmm/ptfragrefcount are used for s390 gmap, x86 pgds and powerpc, ptsharecount is used for x86/arm64/riscv pmds, so we can reuse the field as ptsharecount.(CVE-2024-57883)

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

memcg: fix soft lockup in the OOM process

A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered.

watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:consoleunlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIGRAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintkemit+0x193/0x280 printk+0x52/0x6e dumptask+0x114/0x130 memcgroupscantasks+0x76/0x100 dumpheader+0x1fe/0x210 oomkillprocess+0xd1/0x100 outofmemory+0x125/0x570 memcgroupoutofmemory+0xb5/0xd0 trycharge+0x720/0x770 memcgrouptrycharge+0x86/0x180 memcgrouptrychargedelay+0x1c/0x40 doanonymouspage+0xb5/0x390 handlemmfault+0xc4/0x1f0

This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process.

To fix this issue, call 'condresched' in the 'memcgroupscantasks' function per 1000 iterations. For global OOM, call 'touchsoftlockupwatchdog' per 1000 iterations to avoid this issue.(CVE-2024-57977)

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

nbd: don't allow reconnect after disconnect

Following process can cause nbd_config UAF:

1) grab nbd_config temporarily;

2) nbdgenldisconnect() flush all recv_work() and release the initial reference:

nbdgenldisconnect nbddisconnectandput nbddisconnect flushworkqueue(nbd->recvworkq) if (testandclearbit(NBDRTHASCONFIGREF, ...)) nbdconfig_put -> due to step 1), reference is still not zero

3) nbdgenlreconfigure() queue recv_work() again;

nbdgenlreconfigure config = nbdgetconfigunlocked(nbd) if (!config) -> succeed if (!testbit(NBDRTBOUND, ...)) -> succeed nbdreconnectsocket queuework(nbd->recvworkq, &args->work)

4) step 1) release the reference;

5) Finially, recv_work() will trigger UAF:

recvwork nbdconfigput(nbd) -> nbdconfig is freed atomicdec(&config->recvthreads) -> UAF

Fix the problem by clearing NBDRTBOUND in nbdgenldisconnect(), so that nbdgenlreconfigure() will fail.(CVE-2025-21731)

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

mm/compaction: fix UBSAN shift-out-of-bounds warning

syzkaller reported a UBSAN shift-out-of-bounds warning of (1UL << order) in isolatefreepagesblock(). The bogus compoundorder can be any value because it is union with flags. Add back the MAXPAGE_ORDER check to fix the warning.(CVE-2025-21815)