🛡️ OESA-2025-1285 — kernel (CVE-2023-52926 +18 more)

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

IORING_OP_READ did not correctly consume the provided buffer list when

read i/o returned < 0 (except for -EAGAIN and -EIOCBQUEUED return).

This can lead to a potential use-after-free when the completion via

io_rw_done runs at separate context.(CVE-2023-52926)

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

NFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client()

name is char[64] where the size of clnt->cl_program->name remains

unknown. Invoking strcat() directly will also lead to potential buffer

overflow. Change them to strscpy() and strncat() to fix potential

issues.(CVE-2024-54456)

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

wifi: mac80211: fix mbss changed flags corruption on 32 bit systems

On 32-bit systems, the size of an unsigned long is 4 bytes,

while a u64 is 8 bytes. Therefore, when using

or_each_set_bit(bit, &bits, sizeof(changed) * BITS_PER_BYTE),

the code is incorrectly searching for a bit in a 32-bit

variable that is expected to be 64 bits in size,

leading to incorrect bit finding.

Solution: Ensure that the size of the bits variable is correctly

adjusted for each architecture.

Call Trace:

? show_regs+0x54/0x58

? __warn+0x6b/0xd4

? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]

? report_bug+0x113/0x150

? exc_overflow+0x30/0x30

? handle_bug+0x27/0x44

? exc_invalid_op+0x18/0x50

? handle_exception+0xf6/0xf6

? exc_overflow+0x30/0x30

? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]

? exc_overflow+0x30/0x30

? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211]

? ieee80211_mesh_work+0xff/0x260 [mac80211]

? cfg80211_wiphy_work+0x72/0x98 [cfg80211]

? process_one_work+0xf1/0x1fc

? worker_thread+0x2c0/0x3b4

? kthread+0xc7/0xf0

? mod_delayed_work_on+0x4c/0x4c

? kthread_complete_and_exit+0x14/0x14

? ret_from_fork+0x24/0x38

? kthread_complete_and_exit+0x14/0x14

? ret_from_fork_asm+0xf/0x14

? entry_INT80_32+0xf0/0xf0

[restore no-op path for no changes](CVE-2024-57899)

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

usb: xhci: Fix NULL pointer dereference on certain command aborts

If a command is queued to the final usable TRB of a ring segment, the

enqueue pointer is advanced to the subsequent link TRB and no further.

If the command is later aborted, when the abort completion is handled

the dequeue pointer is advanced to the first TRB of the next segment.

If no further commands are queued, xhci_handle_stopped_cmd_ring() sees

the ring pointers unequal and assumes that there is a pending command,

so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.

Don&apos;t attempt timer setup if cur_cmd is NULL. The subsequent doorbell

ring likely is unnecessary too, but it&apos;s harmless. Leave it alone.

This is probably Bug 219532, but no confirmation has been received.

The issue has been independently reproduced and confirmed fixed using

a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.

Everything continued working normally after several prevented crashes.(CVE-2024-57981)

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

ocfs2: handle a symlink read error correctly

Patch series "Convert ocfs2 to use folios".

Mark did a conversion of ocfs2 to use folios and sent it to me as a

giant patch for review ;-)

So I&apos;ve redone it as individual patches, and credited Mark for the patches

where his code is substantially the same. It&apos;s not a bad way to do it;

his patch had some bugs and my patches had some bugs. Hopefully all our

bugs were different from each other. And hopefully Mark likes all the

changes I made to his code!

This patch (of 23):

If we can&apos;t read the buffer, be sure to unlock the page before returning.(CVE-2024-58001)

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

bpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT

In PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible

context. bpf_mem_alloc must be used in PREEMPT_RT. This patch is

to enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT

is enabled.

[ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48

[ 35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs

[ 35.118569] preempt_count: 1, expected: 0

[ 35.118571] RCU nest depth: 1, expected: 1

[ 35.118577] INFO: lockdep is turned off.

...

[ 35.118647] __might_resched+0x433/0x5b0

[ 35.118677] rt_spin_lock+0xc3/0x290

[ 35.118700] ___slab_alloc+0x72/0xc40

[ 35.118723] __kmalloc_noprof+0x13f/0x4e0

[ 35.118732] bpf_map_kzalloc+0xe5/0x220

[ 35.118740] bpf_selem_alloc+0x1d2/0x7b0

[ 35.118755] bpf_local_storage_update+0x2fa/0x8b0

[