OESA-2025-1730

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

crypto: iaa - Fix potential use after free bug

The freedevicecompressionmode(iaadevice, devicemode) function frees "devicemode" but it iss passed to iaacompressionmodes[i]->free() a few lines later resulting in a use after free.

The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)(CVE-2024-47732)

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

tomoyo: don't emit warning in tomoyowritecontrol()

syzbot is reporting too large allocation warning at tomoyowritecontrol(), for one can write a very very long line without new line character. To fix this warning, I use _GFPNOWARN rather than checking for KMALLOCMAXSIZE, for practically a valid line should be always shorter than 32KB where the "too small to fail" memory-allocation rule applies.

One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOCMAXSIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOCMAXSIZE.(CVE-2024-58085)

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

sockmap, vsock: For connectible sockets allow only connected

sockmap expects all vsocks to have a transport assigned, which is expressed in vsockproto::psockupdateskprot(). However, there is an edge case where an unconnected (connectible) socket may lose its previously assigned transport. This is handled with a NULL check in the vsock/BPF recv path.

Another design detail is that listening vsocks are not supposed to have any transport assigned at all. Which implies they are not supported by the sockmap. But this is complicated by the fact that a socket, before switching to TCP_LISTEN, may have had some transport assigned during a failed connect() attempt. Hence, we may end up with a listening vsock in a sockmap, which blows up quickly:

KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127] CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+ Workqueue: vsock-loopback vsockloopbackwork RIP: 0010:vsockreadskb+0x4b/0x90 Call Trace: skpsockverdictdataready+0xa4/0x2e0 virtiotransportrecvpkt+0x1ca8/0x2acc vsockloopbackwork+0x27d/0x3f0 processonework+0x846/0x1420 workerthread+0x5b3/0xf80 kthread+0x35a/0x700 retfromfork+0x2d/0x70 retfromfork_asm+0x1a/0x30

For connectible sockets, instead of relying solely on the state of vsk->transport, tell sockmap to only allow those representing established connections. This aligns with the behaviour for AFINET and AFUNIX.(CVE-2025-21854)

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

mm/migratedevice: don't add folio to be freed to LRU in migratedevice_finalize()

If migration succeeded, we called foliomigrateflags()->memcgroupmigrate() to migrate the memcg from the old to the new folio. This will set memcg_data of the old folio to 0.

Similarly, if migration failed, memcg_data of the dst folio is left unset.

If we call folioputbacklru() on such folios (memcg_data == 0), we will add the folio to be freed to the LRU, making memcg code unhappy. Running the hmm selftests:

# ./hmm-tests ... # RUN hmm.hmmdeviceprivate.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VMWARNONONCEFOLIO(!memcg && !memcgroupdisabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 foliolruveclockirqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:foliolruveclockirqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] <TASK> [ 102.115397][T14893] ? foliolruveclockirqsave+0x10e/0x170 [ 102.116547][T14893] ? _warn.cold+0x110/0x210 [ 102.117461][T14893] ? foliolruveclockirqsave+0x10e/0x170 [ 102.118667][T14893] ? reportbug+0x1b9/0x320 [ 102.119571][T14893] ? handlebug+0x54/0x90 [ 102.120494][T14893] ? excinvalidop+0x17/0x50 [ 102.121433][T14893] ? asmexcinvalidop+0x1a/0x20 [ 102.122435][T14893] ? _wakeupklogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dumppage+0x4f/0x60 [ 102.124352][T14893] ? foliolruveclockirqsave+0x10e/0x170 [ 102.125500][T14893] foliobatchmovelru+0xd4/0x200 [ 102.126577][T14893] ? _pfxlruadd+0x10/0x10 [ 102.127505][T14893] _foliobatchaddandmove+0x391/0x720 [ 102.128633][T14893] ? _pfxlruadd+0x10/0x10 [ 102.129550][T14893] folioputbacklru+0x16/0x80 [ 102.130564][T14893] migratedevicefinalize+0x9b/0x530 [ 102.131640][T14893] dmirrormigratetodevice.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirrorfopsunlocked_ioctl+0x89b/0xc80

Likely, nothing else goes wrong: putting the last folio reference will remove the folio from the LRU again. So besides memcg complaining, adding the folio to be freed to the LRU is just an unnecessary step.

The new flow resembles what we have in migratefoliomove(): add the dst to the lru, rem ---truncated---(CVE-2025-21861)

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

ksmbd: fix bug on trap in smb2_lock

If lock count is greater than 1, flags could be old value. It should be checked with flags of smblock, not flags. It will cause bug-on trap from locksfree_lock in error handling routine.(CVE-2025-21944)

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

drm/radeon: fix uninitialized size issue in radeonvcecs_parse()

On the off chance that command stream passed from userspace via ioctl() call to radeonvcecsparse() is weirdly crafted and first command to execute is to encode (case 0x03000001), the function in question will attempt to call radeonvcecsreloc() with size argument that has not been properly initialized. Specifically, 'size' will point to 'tmp' variable before the latter had a chance to be assigned any value.

Play it safe and init 'tmp' with 0, thus ensuring that radeonvcecs_reloc() will catch an early error in cases like these.

Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.

(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)(CVE-2025-21996)

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

tpm: do not start chip while suspended

Checking TPMCHIPFLAGSUSPENDED after the call to tpmfindgetops() can lead to a spurious tpmchipstart() call:

[35985.503771] i2c i2c-1: Transfer while suspended [35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 i2ctransfer+0xbe/0x810 [35985.503802] Modules linked in: [35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f [35985.503814] Tainted: [W]=WARN [35985.503817] Hardware name: Google Morphius/Morphius, BIOS GoogleMorphius.13434.858.0 10/26/2023 [35985.503819] RIP: 0010:i2ctransfer+0xbe/0x810 [35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5 [35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246 [35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000 [35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001 [35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820 [35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120 [35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000 [35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0 [35985.503855] Call Trace: [35985.503859] <TASK> [35985.503863] ? _warn+0xd4/0x260 [35985.503868] ? _i2ctransfer+0xbe/0x810 [35985.503874] ? reportbug+0xf3/0x210 [35985.503882] ? handlebug+0x63/0xb0 [35985.503887] ? excinvalidop+0x16/0x50 [35985.503892] ? asmexcinvalidop+0x16/0x20 [35985.503904] ? _i2ctransfer+0xbe/0x810 [35985.503913] tpmcr50i2ctransfermessage+0x24/0xf0 [35985.503920] tpmcr50i2cread+0x8e/0x120 [35985.503928] tpmcr50requestlocality+0x75/0x170 [35985.503935] tpmchipstart+0x116/0x160 [35985.503942] tpmtrygetops+0x57/0x90 [35985.503948] tpmfindgetops+0x26/0xd0 [35985.503955] tpmget_random+0x2d/0x80

Don't move forward with tpmchipstart() inside tpmtrygetops(), unless TPMCHIPFLAGSUSPENDED is not set. tpmfindget_ops() will return NULL in such a failure case.(CVE-2025-23149)

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

KVM: arm64: Tear down vGIC on failed vCPU creation

If kvmarchvcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU.

Add the missing cleanup to kvmarchvcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.(CVE-2025-37849)

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

drm/nouveau: Fix WARNON in nouveaufencecontextkill()

Nouveau is mostly designed in a way that it's expected that fences only ever get signaled through nouveaufencesignal(). However, in at least one other place, nouveaufencedone(), can signal fences, too. If that happens (race) a signaled fence remains in the pending list for a while, until it gets removed by nouveaufenceupdate().

Should nouveaufencecontext_kill() run in the meantime, this would be a bug because the function would attempt to set an error code on an already signaled fence.

Have nouveaufencecontext_kill() check for a fence being signaled.(CVE-2025-37930)

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

objtool, media: dib8000: Prevent divide-by-zero in dib8000setdds()

If dib8000setdds()'s call to dib8000_read32() returns zero, the result is a divide-by-zero. Prevent that from happening.

Fixes the following warning with an UBSAN kernel:

drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000tune() falls through to next function dib8096pcfg_DibRx()(CVE-2025-37937)

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

arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs

A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next.

On exit from a BPF program, emit the BHB mititgation sequence.

This is only applied for 'classic' cBPF programs that are loaded by seccomp.(CVE-2025-37948)

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

arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users

Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB.

In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless.(CVE-2025-37963)

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

HID: uclogic: Add NULL check in uclogicinputconfigured()

devmkasprintf() returns NULL when memory allocation fails. Currently, uclogicinput_configured() does not check for this case, which results in a NULL pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue.(CVE-2025-38007)

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

padata: do not leak refcount in reorder_work

A recent patch that addressed a UAF introduced a reference count leak: the paralleldata refcount is incremented unconditionally, regardless of the return value of queuework(). If the work item is already queued, the incremented refcount is never decremented.

Fix this by checking the return value of queue_work() and decrementing the refcount when necessary.

Resolves:

Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgrprobe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): _kmalloccachenoprof+0x284/0x320 padataallocpd+0x20/0x1e0 padataallocshell+0x3b/0xa0 0xffffffffc040a54d cryptomgrprobe+0x43/0xc0 kthread+0xf6/0x1f0 retfromfork+0x2f/0x50 retfromforkasm+0x1a/0x30(CVE-2025-38031)

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

btrfs: correct the order of prelimref arguments in btrfsprelimref

btrfsprelimref() calls the old and new reference variables in the incorrect order. This causes a NULL pointer dereference because oldref is passed as NULL to tracebtrfsprelimrefinsert().

Note, tracebtrfsprelimrefinsert() is being called with newref as oldref (and oldref as NULL) on purpose in order to print out the values of newref.

To reproduce: echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfsprelimref_insert/enable

Perform some writeback operations.

Backtrace: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 RIP: 0010:traceeventraweventbtrfsprelimref+0x72/0x130 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> prelimrefinsert+0x1c1/0x270 findparentnodes+0x12a6/0x1ee0 ? _entrytextend+0x101f06/0x101f09 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 btrfsisdataextentshared+0x167/0x640 ? fiemapprocesshole+0xd0/0x2c0 extentfiemap+0xa5c/0xbc0 ? _entrytextend+0x101f05/0x101f09 btrfsfiemap+0x7e/0xd0 dovfsioctl+0x425/0x9d0 _x64sys_ioctl+0x75/0xc0(CVE-2025-38034)

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

bpf: copyverifierstate() should copy 'loop_entry' field

The bpfverifierstate.loopentry state should be copied by copyverifierstate(). Otherwise, .loopentry values from unrelated states would poison env->cur_state.

Additionally, env->stack should not contain any states with .loopentry != NULL. The states in env->stack are yet to be verified, while .loopentry is set for states that reached an equivalent state. This means that env->curstate->loopentry should always be NULL after pop_stack().

See the selftest in the next commit for an example of the program that is not safe yet is accepted by verifier w/o this fix.

This change has some verification performance impact for selftests:

File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)

arenahtab.bpf.o arenahtabllvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arenahtabasm.bpf.o arenahtabasm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arenalist.bpf.o arenalistdel 309 279 -30 (-9.71%) 23 14 -9 (-39.13%) iters.bpf.o itersubprogcheckstacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%) iters.bpf.o itersubprogiters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%) iters.bpf.o loopstatedeps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%) kmemcacheiter.bpf.o opencodediter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) verifierbitsiter.bpf.o maxwords 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifieriteratingcallbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%)

And significant negative impact for sched_ext:

File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)

bpf.bpf.o lavdinit 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%) bpf.bpf.o layereddispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%) bpf.bpf.o layereddump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%) bpf.bpf.o layeredenqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%) bpf.bpf.o p2dqdispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%) bpf.bpf.o p2dqinit 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%) bpf.bpf.o refreshlayercpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%) bpf.bpf.o rustyselectcpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%) scxcentral.bpf.o centraldispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%) scxnest.bpf.o nestinit 636 815 +179 (+28.14%) 60 73 +13 (+21.67%) scxqmap.bpf.o qmapdispatch
---truncated---(CVE-2025-38060)

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

orangefs: Do not truncate file size

'len' is used to store the result of isizeread(), so making 'len' a size_t results in truncation to 4GiB on 32-bit systems.(CVE-2025-38065)

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

vhost-scsi: protect vq->log_used with vq->mutex

The vhost-scsi completion path may access vq->logbase when vq->logused is already set to false.

vhost-thread                       QEMU-thread

vhostscsicompletecmdwork() -> vhostaddused() -> vhostaddusedn() if (unlikely(vq->logused)) QEMU disables vq->logused via VHOSTSETVRINGADDR. mutexlock(&vq->mutex); vq->logused = false now! mutex_unlock(&vq->mutex);

                  QEMU gfree(vq->log_base)
    log_used()
    -> log_write(vq->log_base)

Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace.

The control queue path has the same issue.(CVE-2025-38074)

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

ALSA: pcm: Fix race of buffer access at PCM OSS layer

The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of sndpcmformatsetsilence() with runtime->dmaarea. But this may lead to a UAF because the accessed runtime->dmaarea might be freed concurrently, as it's performed outside the PCM ops.

For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation.(CVE-2025-38078)

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

drm/amd/display: Increase block_sequence array size

[Why] It's possible to generate more than 50 steps in hwssbuildfastsequence, for example with a 6-pipe asic where all pipes are in one MPC chain. This overflows the blocksequence buffer and corrupts blocksequencesteps, causing a crash.

[How] Expand block_sequence to 100 items. A naive upper bound on the possible number of steps for a 6-pipe asic, ignoring the potential for steps to be mutually exclusive, is 91 with current code, therefore 100 is sufficient.(CVE-2025-38080)

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

remoteproc: core: Clear tablesz when rprocshutdown

There is case as below could trigger kernel dump: Use U-Boot to start remote processor(rproc) with resource table published to a fixed address by rproc. After Kernel boots up, stop the rproc, load a new firmware which doesn't have resource table ,and start rproc.

When starting rproc with a firmware not have resource table, memcpy(loaded_table, rproc->cached_table, rproc->table_sz) will trigger dump, because rproc->cachetable is set to NULL during the last stop operation, but rproc->tablesz is still valid.

This issue is found on i.MX8MP and i.MX9.

Dump as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _pimemcpygeneric+0x110/0x22c lr : rprocstart+0x88/0x1e0 Call trace: _pimemcpygeneric+0x110/0x22c (P) rprocboot+0x198/0x57c statestore+0x40/0x104 devattrstore+0x18/0x2c sysfskfwrite+0x7c/0x94 kernfsfopwriteiter+0x120/0x1cc vfswrite+0x240/0x378 ksyswrite+0x70/0x108 _arm64syswrite+0x1c/0x28 invokesyscall+0x48/0x10c el0svccommon.constprop.0+0xc0/0xe0 doel0svc+0x1c/0x28 el0svc+0x30/0xcc el0t64synchandler+0x10c/0x138 el0t64sync+0x198/0x19c

Clear rproc->table_sz to address the issue.(CVE-2025-38152)

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

jfs: fix slab-out-of-bounds read in ea_get()

During the "sizecheck" label in eaget(), the code checks if the extended attribute list (xattr) size matches easize. If not, it logs "eaget: invalid extended attribute" and calls printhexdump().

Here, EALISTSIZE(eabuf->xattr) returns 4110417968, which exceeds INTMAX (2,147,483,647). Then easize is clamped:

int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr));

Although clampt aims to bound easize between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328).

The "size" is then passed to printhexdump() (called "len" in printhexdump()), it is passed as type sizet (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hexdumptobuffer(). In printhexdump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hexdumpto_buffer() on each iteration:

for (i = 0; i < len; i += rowsize) {
    linelen = min(remaining, rowsize);
    remaining -= rowsize;

    hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
               linebuf, sizeof(linebuf), ascii);

    ...
}

The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hexdumptobuffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hexdumptobuffer() in the following for loop:

for (j = 0; j < len; j++) {
        if (linebuflen < lx + 2)
            goto overflow2;
        ch = ptr[j];
    ...
}

To fix this we should validate "EALISTSIZE(eabuf->xattr)" before it is utilised.(CVE-2025-39735)

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

objtool, spi: amd: Fix out-of-bounds stack access in amdsetspi_freq()

If speedhz < AMDSPIMINHZ, amdsetspifreq() iterates over the entire amdspi_freq array without breaking out early, causing 'i' to go beyond the array bounds.

Fix that by stopping the loop when it gets to the last entry, so the low speedhz value gets clamped up to AMDSPIMINHZ.

Fixes the following warning with an UBSAN kernel:

drivers/spi/spi-amd.o: error: objtool: amdsetspifreq() falls through to next function amdspisetopcode()(CVE-2025-40014)

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

iouring: fix ioreqprepasync with provided buffers

ioreqprep_async() can import provided buffers, commit the ring state by giving up on that before, it'll be reimported later if needed.(CVE-2025-40364)