OESA-2026-1230

The Linux Kernel, the operating system core itself.

Security Fix(es):

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:

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:

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