OESA-2026-1228

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: fec: remove .ndopollcontroller to avoid deadlocks

There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndopollcontroller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disableirq() is called by .ndopollcontroller interface of sungem driver, however, disableirq() might sleep. After analyzing the implementation of fecpollcontroller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndopollcontroller is unnecessary to be implemented in the fec driver, so fecpollcontroller() can be safely removed.(CVE-2024-38553)

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

ceph: give up on paths longer than PATH_MAX

If the full path to be built by cephmdscbuildpath() happens to be longer than PATHMAX, then this function will enter an endless (retry) loop, effectively blocking the whole task. Most of the machine becomes unusable, making this a very simple and effective DoS vulnerability.

I cannot imagine why this retry was ever implemented, but it seems rather useless and harmful to me. Let's remove it and fail with ENAMETOOLONG instead.(CVE-2024-53685)

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

Bluetooth: hcicore: Disable works on hciunregister_dev

This make use of disablework* on hciunregisterdev since the hci_dev is about to be freed new submissions are not disarable.(CVE-2024-58241)

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

ipvlan: Fix use-after-free in ipvlangetiflink().

syzbot presented an use-after-free report [0] regarding ipvlan and linkwatch.

ipvlan does not hold a refcnt of the lower device unlike vlan and macvlan.

If the linkwatch work is triggered for the ipvlan dev, the lower dev might have already been freed, resulting in UAF of ipvlan->phydev in ipvlanget_iflink().

We can delay the lower dev unregistration like vlan and macvlan by holding the lower dev's refcnt in dev->netdevops->ndoinit() and releasing it in dev->priv_destructor().

Jakub pointed out calling .ndoXXX after unregisternetdevice() has returned is error prone and suggested [1] addressing this UAF in the core by taking commit 750e51603395 ("net: avoid potential UAF in default_operstate()") further.

Let's assume unregistering devices DOWN and use RCU protection in default_operstate() not to race with the device unregistration.

Read of size 4 at addr ffff0000d768c0e0 by task kworker/u8:35/6944

CPU: 0 UID: 0 PID: 6944 Comm: kworker/u8:35 Not tainted 6.13.0-rc2-g9bc5c9515b48 #12 4c3cb9e8b4565456f6a355f312ff91f4f29b3c47 Hardware name: linux,dummy-virt (DT) Workqueue: eventsunbound linkwatchevent Call trace: showstack+0x38/0x50 arch/arm64/kernel/stacktrace.c:484 (C) _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0xbc/0x108 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x16c/0x6f0 mm/kasan/report.c:489 kasanreport+0xc0/0x120 mm/kasan/report.c:602 _asanreportload4noabort+0x20/0x30 mm/kasan/reportgeneric.c:380 ipvlangetiflink+0x84/0x88 drivers/net/ipvlan/ipvlanmain.c:353 devgetiflink+0x7c/0xd8 net/core/dev.c:674 defaultoperstate net/core/linkwatch.c:45 [inline] rfc2863policy+0x144/0x360 net/core/linkwatch.c:72 linkwatchdodev+0x60/0x228 net/core/linkwatch.c:175 _linkwatchrunqueue+0x2f4/0x5b8 net/core/linkwatch.c:239 linkwatchevent+0x64/0xa8 net/core/linkwatch.c:282 processonework+0x700/0x1398 kernel/workqueue.c:3229 processscheduledworks kernel/workqueue.c:3310 [inline] workerthread+0x8c4/0xe10 kernel/workqueue.c:3391 kthread+0x2b0/0x360 kernel/kthread.c:389 retfrom_fork+0x10/0x20 arch/arm64/kernel/entry.S:862

Allocated by task 9303: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x30/0x68 mm/kasan/common.c:68 kasansaveallocinfo+0x44/0x58 mm/kasan/generic.c:568 poisonkmallocredzone mm/kasan/common.c:377 [inline] _kasankmalloc+0x84/0xa0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] _dokmallocnode mm/slub.c:4283 [inline] _kmallocnodenoprof+0x2a0/0x560 mm/slub.c:4289 _kvmallocnodenoprof+0x9c/0x230 mm/util.c:650 allocnetdevmqs+0xb4/0x1118 net/core/dev.c:11209 rtnlcreatelink+0x2b8/0xb60 net/core/rtnetlink.c:3595 rtnlnewlinkcreate+0x19c/0x868 net/core/rtnetlink.c:3771 _rtnlnewlink net/core/rtnetlink.c:3896 [inline] rtnlnewlink+0x122c/0x15c0 net/core/rtnetlink.c:4011 rtnetlinkrcvmsg+0x61c/0x918 net/core/rtnetlink.c:6901 netlinkrcvskb+0x1dc/0x398 net/netlink/afnetlink.c:2542 rtnetlinkrcv+0x34/0x50 net/core/rtnetlink.c:6928 netlinkunicastkernel net/netlink/afnetlink.c:1321 [inline] netlinkunicast+0x618/0x838 net/netlink/afnetlink.c:1347 netlinksendmsg+0x5fc/0x8b0 net/netlink/afnetlink.c:1891 socksendmsgnosec net/socket.c:711 [inline] _socksendmsg net/socket.c:726 [inline] _syssendto+0x2ec/0x438 net/socket.c:2197 _dosyssendto net/socket.c:2204 [inline] _sesyssendto net/socket.c:2200 [inline] _arm64syssendto+0xe4/0x110 net/socket.c:2200 _invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0svccommon+0x13c/0x250 arch/arm64/kernel/syscall.c:132 doel0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el ---truncated---(CVE-2025-21652)

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

ksmbd: fix use-after-free in _smb2leasebreaknoti()

Move tcptransport free to ksmbdconnfree. If ksmbd connection is referenced when ksmbd server thread terminates, It will not be freed, but conn->tcptransport is freed. _smb2leasebreaknoti can be performed asynchronously when the connection is disconnected. _smb2leasebreaknoti calls ksmbdconnwrite, which can cause use-after-free when conn->ksmbd_transport is already freed.(CVE-2025-37777)

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

dm-bufio: don't schedule in atomic context

A BUG was reported as below when CONFIGDEBUGATOMICSLEEP and tryverifyintasklet are enabled. [ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421 [ 129.444723][ T934] inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 934, name: kworker/1:4 [ 129.444740][ T934] preemptcount: 201, expected: 0 [ 129.444756][ T934] RCU nest depth: 0, expected: 0 [ 129.444781][ T934] Preemption disabled at: [ 129.444789][ T934] [<ffffffd816231900>] shrinkwork+0x21c/0x248 [ 129.445167][ T934] kernel BUG at kernel/sched/walt/waltdebug.c:16! [ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0 [ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8 [ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT) [ 129.447373][ T934] Workqueue: dmbufiocache shrinkwork [ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 129.447406][ T934] pc : androidrvhschedulebug+0x0/0x8 [schedwaltdebug] [ 129.447435][ T934] lr : _traceiterandroidrvhschedulebug+0x44/0x6c [ 129.447451][ T934] sp : ffffffc0843dbc90 [ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b [ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68 [ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900 [ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030 [ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358 [ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003 [ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400 [ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8 [ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0 [ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000 [ 129.447647][ T934] Call trace: [ 129.447655][ T934] androidrvhschedulebug+0x0/0x8 [schedwaltdebug 1400000003000000474e550080cce8a8a78606b6] [ 129.447681][ T934] _mightresched+0x190/0x1a8 [ 129.447694][ T934] shrinkwork+0x180/0x248 [ 129.447706][ T934] processonework+0x260/0x624 [ 129.447718][ T934] workerthread+0x28c/0x454 [ 129.447729][ T934] kthread+0x118/0x158 [ 129.447742][ T934] retfromfork+0x10/0x20 [ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000) [ 129.447772][ T934] ---[ end trace 0000000000000000 ]---

dmbufiolock will call spinlockbh when tryverifyintasklet is enabled, and _scan will be called in atomic context.(CVE-2025-37928)

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

USB: wdm: close race between wdmopen and wdmwwanportstop

Clearing WDMWWANIN_USE must be the last action or we can open a chardev whose URBs are still poisoned(CVE-2025-37985)

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

mm/page_alloc: fix race condition in unaccepted memory handling

The page allocator tracks the number of zones that have unaccepted memory using staticbranchenc/dec() and uses that static branch in hot paths to determine if it needs to deal with unaccepted memory.

Borislav and Thomas pointed out that the tracking is racy: operations on static_branch are not serialized against adding/removing unaccepted pages to/from the zone.

Sanity checks inside static_branch machinery detects it:

WARNING: CPU: 0 PID: 10 at kernel/jumplabel.c:276 _statickeyslowdeccpuslocked+0x8e/0xa0

The comment around the WARN() explains the problem:

/*
 * Warn about the '-1' case though; since that means a
 * decrement is concurrent with a first (0->1) increment. IOW
 * people are trying to disable something that wasn't yet fully
 * enabled. This suggests an ordering problem on the user side.
 */

The effect of this static_branch optimization is only visible on microbenchmark.

Instead of adding more complexity around it, remove it altogether.(CVE-2025-38008)

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

drm/scheduler: signal scheduled fence when kill job

When an entity from application B is killed, drmschedentitykill() removes all jobs belonging to that entity through drmschedentitykilljobswork(). If application A's job depends on a scheduled fence from application B's job, and that fence is not properly signaled during the killing process, application A's dependency cannot be cleared.

This leads to application A hanging indefinitely while waiting for a dependency that will never be resolved. Fix this issue by ensuring that scheduled fences are properly signaled when an entity is killed, allowing dependent applications to continue execution.(CVE-2025-38436)

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

ksmbd: limit repeated connections from clients with the same IP

Repeated connections from clients with the same IP address may exhaust the max connections and prevent other normal client connections. This patch limit repeated connections from clients with the same IP.(CVE-2025-38501)

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

ppp: fix race conditions in pppfillforward_path

pppfillforward_path() has two race conditions:

1. The ppp->channels list can change between listempty() and listfirstentry(), as ppplock() is not held. If the only channel is deleted in pppdisconnectchannel(), listfirstentry() may access an empty head or a freed entry, and trigger a panic.

2. pch->chan can be NULL. When pppunregisterchannel() is called, pch->chan is set to NULL before pch is removed from ppp->channels.

Fix these by using a lockless RCU approach: - Use listfirstornullrcu() to safely test and access the first list entry. - Convert list modifications on ppp->channels to their RCU variants and add synchronize_net() after removal. - Check for a NULL pch->chan before dereferencing it.(CVE-2025-39673)

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

xfs: do not propagate ENODATA disk errors into xattr code

ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code; namely, that the requested attribute name could not be found.

However, a medium error from disk may also return ENODATA. At best, this medium error may escape to userspace as "attribute not found" when in fact it's an IO (disk) error.

At worst, we may oops in xfsattrleaf_get() when we do:

error = xfs_attr_leaf_hasname(args, &bp);
if (error == -ENOATTR)  {
    xfs_trans_brelse(args->trans, bp);
    return error;
}

because an ENODATA/ENOATTR error from disk leaves us with a null bp, and the xfstransbrelse will then null-deref it.

As discussed on the list, we really need to modify the lower level IO functions to trap all disk errors and ensure that we don't let unique errors like this leak up into higher xfs functions - many like this should be remapped to EIO.

However, this patch directly addresses a reported bug in the xattr code, and should be safe to backport to stable kernels. A larger-scope patch to handle more unique errors at lower levels can follow later.

(Note, prior to 07120f1abdff we did not oops, but we did return the wrong error code to userspace.)(CVE-2025-39835)

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

can: j1939: implement NETDEV_UNREGISTER notification handler

syzbot is reporting

unregister_netdevice: waiting for vcan0 to become free. Usage count = 2

problem, for j1939 protocol did not have NETDEVUNREGISTER notification handler for undoing changes made by j1939sk_bind().

Commit 25fe97cb7620 ("can: j1939: move j1939privput() into skdestruct callback") expects that a call to j1939privput() can be unconditionally delayed until j1939sksockdestruct() is called. But we need to call j1939privput() against an extra ref held by j1939skbind() call (as a part of undoing changes made by j1939skbind()) as soon as NETDEVUNREGISTER notification fires (i.e. before j1939sksockdestruct() is called via j1939skrelease()). Otherwise, the extra ref on "struct j1939priv" held by j1939skbind() call prevents "struct netdevice" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue.

mkl: remove space in front of label

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

net: atlantic: fix fragment overflow handling in RX path

The atlantic driver can receive packets with more than MAXSKBFRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skbaddrxfragnetmem() leading to kernel panic.

The issue occurs because the driver doesn't check the total number of fragments before calling skbaddrxfrag(). When a packet requires more than MAXSKB_FRAGS fragments, the fragment index exceeds the array bounds.

Fix by assuming there will be an extra frag if buff->len > AQCFGRXHDRSIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path.

This crash occurred in production with an Aquantia AQC113 10G NIC.

Stack trace from production environment:

RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0
Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89
ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90
c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48
89 fa 83
RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287
RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:
fffffffe0a0c8000
RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:
0000000000037a40
RBP: 0000000000000024 R08: 0000000000000000 R09:
0000000000000021
R10: 0000000000000848 R11: 0000000000000000 R12:
ffffa9bec02a8e24
R13: ffff925ad8615570 R14: 0000000000000000 R15:
ffff925b22e80a00
FS: 0000000000000000(0000)
GS:ffff925e47880000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:
0000000000f72ef0
PKRU: 55555554
Call Trace:
<IRQ>
aq_ring_rx_clean+0x175/0xe60 [atlantic]
? aq_ring_rx_clean+0x14d/0xe60 [atlantic]
? aq_ring_tx_clean+0xdf/0x190 [atlantic]
? kmem_cache_free+0x348/0x450
? aq_vec_poll+0x81/0x1d0 [atlantic]
? __napi_poll+0x28/0x1c0
? net_rx_action+0x337/0x420

Changes in v4: - Add Fixes: tag to satisfy patch validation requirements.

Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQCFGRXHDRSIZE, then all fragments are accounted for.(CVE-2025-68301)