OESA-2025-2699

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:ntbhwswitchtec: Fix shift-out-of-bounds in switchtecntbmwsettransThere is a kernel API ntbmwcleartrans() would pass 0 to both addr andsize. This would make xlatepos negative.[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000[ 23.734158] ================================================================================[ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntbhwswitchtec.c:293:7[ 23.734418] shift exponent -1 is negativeEnsuring xlate_pos is a positive or zero before BIT.(CVE-2023-53034)

In the Linux kernel, the following vulnerability has been resolved:slimbus: messaging: Free transaction ID in delayed interrupt scenarioIn case of interrupt delay for any reason, slimdotransfer()returns timeout error but the transaction ID (TID) is not freed.This results into invalid memory access insideqcomslimngdrxmsgqcb() due to invalid TID.Fix the issue by freeing the TID in slimdotransfer() beforereturning timeout error to avoid invalid memory access.Call trace:memcpyfromio+0x20/0x190qcomslimngdrxmsgqcb+0x130/0x290 [slimqcomngdctrl]vchancomplete+0x2a0/0x4a0taskletactioncommon+0x274/0x700taskletaction+0x28/0x3cstext+0x188/0x620runksoftirqd+0x34/0x74smpbootthreadfn+0x1d8/0x464kthread+0x178/0x238retfromfork+0x10/0x20Code: aa0003e8 91000429 f100044a 3940002b (3800150b)---[ end trace 0fe00bec2b975c99 ]---Kernel panic - not syncing: Oops: Fatal exception in interrupt.(CVE-2025-21914)

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

usb: dwc3: gadget: check that event count does not exceed event buffer length

The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3checkevent_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: _memcpy+0x114/0x180 dwc3interrupt+0x24/0x34(CVE-2025-37810)

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

ALSA: usb-audio: Validate UAC3 cluster segment descriptors

UAC3 class segment descriptors need to be verified whether their sizes match with the declared lengths and whether they fit with the allocated buffer sizes, too. Otherwise malicious firmware may lead to the unexpected OOB accesses.(CVE-2025-39757)

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

scsi: mpt3sas: Fix crash in transport port remove by using ioc_info()

During mpt3sastransportportremove(), messages were logged with devprintk() against &mpt3sas_port->port->dev. At this point the SAS transport device may already be partially unregistered or freed, leading to a crash when accessing its struct device.

Using ioc_info(), which logs via the PCI device (ioc->pdev->dev), guaranteed to remain valid until driver removal.

[83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI [83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary) [83428.295792] Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE [83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024 [83428.295799] RIP: 0010:__devprintk+0x1f/0x70 [83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff [83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206 [83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32 [83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845 [83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8 [83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000 [83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30 [83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000 [83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0 [83428.295844] PKRU: 55555554 [83428.295846] Call Trace: [83428.295848] <TASK> [83428.295850] devprintk+0x5c/0x80 [83428.295857] ? srsoalias_returnthunk+0x5/0xfbef5 [83428.295863] mpt3sastransportportremove+0x1c7/0x420 [mpt3sas] [83428.295882] scsihremovedevice+0x21b/0x280 [mpt3sas] [83428.295894] ? scsihexpandernoderemove+0x108/0x140 [mpt3sas] [83428.295906] ? srsoaliasreturnthunk+0x5/0xfbef5 [83428.295910] mpt3sasdeviceremovebysasaddress.part.0+0x8f/0x110 [mpt3sas] [83428.295921] scsihexpandernoderemove+0x129/0x140 [mpt3sas] [83428.295933] scsihexpandernoderemove+0x6a/0x140 [mpt3sas] [83428.295944] scsihremove+0x3f0/0x4a0 [mpt3sas] [83428.295957] pcideviceremove+0x3b/0xb0 [83428.295962] devicereleasedriverinternal+0x193/0x200 [83428.295968] driverdetach+0x44/0x90 [83428.295971] busremovedriver+0x69/0xf0 [83428.295975] pciunregisterdriver+0x2a/0xb0 [83428.295979] mpt3sasexit+0x1f/0x300 [mpt3sas] [83428.295991] __dosysdeletemodule.constprop.0+0x174/0x310 [83428.295997] ? srsoaliasreturnthunk+0x5/0xfbef5 [83428.296000] ? __x64sysgetdents64+0x9a/0x110 [83428.296005] ? srsoaliasreturnthunk+0x5/0xfbef5 [83428.296009] ? syscalltraceenter+0xf6/0x1b0 [83428.296014] dosyscall64+0x7b/0x2c0 [83428.296019] ? srsoaliasreturnthunk+0x5/0xfbef5 [83428.296023] entrySYSCALL64afterhwframe+0x76/0x7e(CVE-2025-40115)

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

bpf: Enforce expectedattachtype for tailcall compatibility

Yinhao et al. recently reported:

Our fuzzer tool discovered an uninitialized pointer issue in the bpfprogtestrunxdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.

The test initializes two programs of BPFPROGTYPEXDP: progA acts as the entry point for bpfprogtestrunxdp() and its expectedattachtype can neither be of be BPFXDPDEVMAP nor BPFXDPCPUMAP. progA calls into a slot of a tailcall map it owns. progB's expectedattachtype must be BPFXDPDEVMAP to pass xdpisvalidaccess() validation. The program returns struct xdpmd's egressifindex, and the latter is only allowed to be accessed under mentioned expectedattachtype. progB is then inserted into the tailcall which progA calls.

The underlying issue goes beyond XDP though. Another example are programs of type BPFPROGTYPECGROUPSOCKADDR. sockaddrisvalidaccess() as well as sockaddrfuncproto() have different logic depending on the programs' expectedattachtype. Similarly, a program attached to BPFCGROUPINET4GETPEERNAME should not be allowed doing a tailcall into a program which calls bpfbind() out of BPF which is only enabled for BPFCGROUPINET4_CONNECT.

In short, specifying expectedattachtype allows to open up additional functionality or restrictions beyond what the basic bpfprogtype enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expectedattachtype in _bpfprogmapcompatible().

Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through devmapbpfprogrun*() and cpumapbpfprogrun*() which set up a new environment / context and therefore these situations are not prone to this issue.(CVE-2025-40123)

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

EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller

When loading the i10nm_edac driver on some Intel Granite Rapids servers, a call trace may appear as follows:

UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsanhandleshiftoutofbounds+0x1e3/0x390 skxgetdimminfo.cold+0x47/0xd40 [skxedaccommon] i10nmgetdimmconfig+0x23e/0x390 [i10nmedac] skxregistermci+0x159/0x220 [skxedaccommon] i10nminit+0xcb0/0x1ff0 [i10nmedac] ...

This occurs because some BIOS may disable a memory controller if there aren't any memory DIMMs populated on this memory controller. The DIMMMTR register of this disabled memory controller contains the invalid value ~0, resulting in the call trace above.

Fix this call trace by skipping DIMM enumeration on a disabled memory controller.(CVE-2025-40157)

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

fs: quota: create dedicated workqueue for quotareleasework

There is a kernel panic due to WARNONCE when panicon_warn is set.

This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WBREASONSYNC). When f2fs balance is needed at sync path, flush for quotareleasework is triggered. By default quotareleasework is queued to "eventsunbound" queue which does not have WQMEMRECLAIM flag. During f2fs balance "writeback" workqueue tries to flush quotareleasework causing kernel panic due to MEMRECLAIM flag mismatch errors.

This patch creates dedicated workqueue with WQMEMRECLAIM flag for work quotareleasework.

------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 checkflushdependency+0x13c/0x148 Call trace: checkflushdependency+0x13c/0x148 __flushwork+0xd0/0x398 flushdelayed_work+0x44/0x5c dquotwritebackdquots+0x54/0x318 f2fsdoquotasync+0xb8/0x1a8 f2fswritecheckpoint+0x3cc/0x99c f2fsgc+0x190/0x750 f2fsbalancefs+0x110/0x168 f2fswritesingledatapage+0x474/0x7dc f2fswritedatapages+0x7d0/0xd0c dowritepages+0xe0/0x2f4 _writebacksingleinode+0x44/0x4ac writebacksbinodes+0x30c/0x538 wbwriteback+0xf4/0x440 wbworkfn+0x128/0x5d4 processscheduledworks+0x1c4/0x45c workerthread+0x32c/0x3e8 kthread+0x11c/0x1b0 retfromfork+0x10/0x20 Kernel panic - not syncing: kernel: paniconwarn set ...(CVE-2025-40196)