OESA-2025-1247

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

afpacket: avoid erroring out after sockinitdata() in packetcreate()

After sockinitdata() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free.(CVE-2024-56606)

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

iio: imu: kmx61: fix information leak in triggered buffer

The 'buffer' local array is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iioforeachactivechannel() to assign new values.

Initialize the array to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57908)

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

iio: pressure: zpa2326: fix information leak in triggered buffer

The 'sample' local struct is used to push data to user space from a triggered buffer, but it has a hole between the temperature and the timestamp (u32 pressure, u16 temperature, GAP, u64 timestamp). This hole is never initialized.

Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57912)

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:

net: hns3: fixed hclgefetchpf_reg accesses bar space out of bounds issue

The TQP BAR space is divided into two segments. TQPs 0-1023 and TQPs 1024-1279 are in different BAR space addresses. However, hclgefetchpfreg does not distinguish the tqp space information when reading the tqp space information. When the number of TQPs is greater than 1024, access bar space overwriting occurs. The problem of different segments has been considered during the initialization of tqp.iobase. Therefore, tqp.iobase is directly used when the queue is read in hclgefetchpfreg.

The error message:

Unable to handle kernel paging request at virtual address ffff800037200000 pc : hclgefetchpfreg+0x138/0x250 [hclge] lr : hclgegetregs+0x84/0x1d0 [hclge] Call trace: hclgefetchpfreg+0x138/0x250 [hclge] hclgegetregs+0x84/0x1d0 [hclge] hns3getregs+0x2c/0x50 [hns3] ethtoolgetregs+0xf4/0x270 devethtool+0x674/0x8a0 devioctl+0x270/0x36c sockdoioctl+0x110/0x2a0 sockioctl+0x2ac/0x530 _arm64sysioctl+0xa8/0x100 invokesyscall+0x4c/0x124 el0svccommon.constprop.0+0x140/0x15c doel0svc+0x30/0xd0 el0svc+0x1c/0x2c el0synchandler+0xb0/0xb4 el0_sync+0x168/0x180(CVE-2025-21650)

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

net: hns3: don't auto enable misc vector

Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below:

[ 16.324639] Call trace: [ 16.324641] _queuedelayedwork+0xb8/0xe0 [ 16.324643] moddelayedworkon+0x78/0xd0 [ 16.324655] hclgeerrhandtaskschedule+0x58/0x90 [hclge] [ 16.324662] hclgemiscirqhandle+0x168/0x240 [hclge] [ 16.324666] _handleirqeventpercpu+0x64/0x1e0 [ 16.324667] handleirqevent+0x80/0x170 [ 16.324670] handlefasteoiedgeirq+0x110/0x2bc [ 16.324671] _handledomainirq+0x84/0xfc [ 16.324673] gichandleirq+0x88/0x2c0 [ 16.324674] el1irq+0xb8/0x140 [ 16.324677] archcpuidle+0x18/0x40 [ 16.324679] defaultidlecall+0x5c/0x1bc [ 16.324682] cpuidleidlecall+0x18c/0x1c4 [ 16.324684] doidle+0x174/0x17c [ 16.324685] cpustartupentry+0x30/0x6c [ 16.324687] secondarystartkernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]---

So don't auto enable misc vector when request irq..(CVE-2025-21651)

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)