{"schema_version":"1.7.2","id":"OESA-2025-1730","modified":"2025-07-04T14:43:38Z","published":"2025-07-04T14:43:38Z","upstream":["CVE-2024-47732","CVE-2024-58085","CVE-2025-21854","CVE-2025-21861","CVE-2025-21944","CVE-2025-21996","CVE-2025-23149","CVE-2025-37849","CVE-2025-37930","CVE-2025-37937","CVE-2025-37948","CVE-2025-37963","CVE-2025-38007","CVE-2025-38031","CVE-2025-38034","CVE-2025-38060","CVE-2025-38065","CVE-2025-38074","CVE-2025-38078","CVE-2025-38080","CVE-2025-38152","CVE-2025-39735","CVE-2025-40014","CVE-2025-40364"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: iaa - Fix potential use after free bug\n\nThe free_device_compression_mode(iaa_device, device_mode) function frees\n\u0026quot;device_mode\u0026quot; but it iss passed to iaa_compression_modes[i]-\u0026gt;free() a few\nlines later resulting in a use after free.\n\nThe good news is that, so far as I can tell, nothing implements the\n-\u0026gt;free() function and the use after free happens in dead code.  But, with\nthis fix, when something does implement it, we\u0026apos;ll be ready.  :)(CVE-2024-47732)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntomoyo: don\u0026apos;t emit warning in tomoyo_write_control()\n\nsyzbot is reporting too large allocation warning at tomoyo_write_control(),\nfor one can write a very very long line without new line character. To fix\nthis warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE,\nfor practically a valid line should be always shorter than 32KB where the\n\u0026quot;too small to fail\u0026quot; memory-allocation rule applies.\n\nOne might try to write a valid line that is longer than 32KB, but such\nrequest will likely fail with -ENOMEM. Therefore, I feel that separately\nreturning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant.\nThere is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.(CVE-2024-58085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsockmap, vsock: For connectible sockets allow only connected\n\nsockmap expects all vsocks to have a transport assigned, which is expressed\nin vsock_proto::psock_update_sk_prot(). However, there is an edge case\nwhere an unconnected (connectible) socket may lose its previously assigned\ntransport. This is handled with a NULL check in the vsock/BPF recv path.\n\nAnother design detail is that listening vsocks are not supposed to have any\ntransport assigned at all. Which implies they are not supported by the\nsockmap. But this is complicated by the fact that a socket, before\nswitching to TCP_LISTEN, may have had some transport assigned during a\nfailed connect() attempt. Hence, we may end up with a listening vsock in a\nsockmap, which blows up quickly:\n\nKASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127]\nCPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+\nWorkqueue: vsock-loopback vsock_loopback_work\nRIP: 0010:vsock_read_skb+0x4b/0x90\nCall Trace:\n sk_psock_verdict_data_ready+0xa4/0x2e0\n virtio_transport_recv_pkt+0x1ca8/0x2acc\n vsock_loopback_work+0x27d/0x3f0\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x35a/0x700\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n\nFor connectible sockets, instead of relying solely on the state of\nvsk-\u0026gt;transport, tell sockmap to only allow those representing established\nconnections. This aligns with the behaviour for AF_INET and AF_UNIX.(CVE-2025-21854)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/migrate_device: don\u0026apos;t add folio to be freed to LRU in migrate_device_finalize()\n\nIf migration succeeded, we called\nfolio_migrate_flags()-\u0026gt;mem_cgroup_migrate() to migrate the memcg from the\nold to the new folio.  This will set memcg_data of the old folio to 0.\n\nSimilarly, if migration failed, memcg_data of the dst folio is left unset.\n\nIf we call folio_putback_lru() on such folios (memcg_data == 0), we will\nadd the folio to be freed to the LRU, making memcg code unhappy.  Running\nthe hmm selftests:\n\n  # ./hmm-tests\n  ...\n  #  RUN           hmm.hmm_device_private.migrate ...\n  [  102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00\n  [  102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff)\n  [  102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9\n  [  102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000\n  [  102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg \u0026amp;\u0026amp; !mem_cgroup_disabled())\n  [  102.087230][T14893] ------------[ cut here ]------------\n  [  102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170\n  [  102.090478][T14893] Modules linked in:\n  [  102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151\n  [  102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\n  [  102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170\n  [  102.096104][T14893] Code: ...\n  [  102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293\n  [  102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426\n  [  102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880\n  [  102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000\n  [  102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8\n  [  102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000\n  [  102.108830][T14893] FS:  00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000\n  [  102.110643][T14893] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [  102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0\n  [  102.113478][T14893] PKRU: 55555554\n  [  102.114172][T14893] Call Trace:\n  [  102.114805][T14893]  \u0026lt;TASK\u0026gt;\n  [  102.115397][T14893]  ? folio_lruvec_lock_irqsave+0x10e/0x170\n  [  102.116547][T14893]  ? __warn.cold+0x110/0x210\n  [  102.117461][T14893]  ? folio_lruvec_lock_irqsave+0x10e/0x170\n  [  102.118667][T14893]  ? report_bug+0x1b9/0x320\n  [  102.119571][T14893]  ? handle_bug+0x54/0x90\n  [  102.120494][T14893]  ? exc_invalid_op+0x17/0x50\n  [  102.121433][T14893]  ? asm_exc_invalid_op+0x1a/0x20\n  [  102.122435][T14893]  ? __wake_up_klogd.part.0+0x76/0xd0\n  [  102.123506][T14893]  ? dump_page+0x4f/0x60\n  [  102.124352][T14893]  ? folio_lruvec_lock_irqsave+0x10e/0x170\n  [  102.125500][T14893]  folio_batch_move_lru+0xd4/0x200\n  [  102.126577][T14893]  ? __pfx_lru_add+0x10/0x10\n  [  102.127505][T14893]  __folio_batch_add_and_move+0x391/0x720\n  [  102.128633][T14893]  ? __pfx_lru_add+0x10/0x10\n  [  102.129550][T14893]  folio_putback_lru+0x16/0x80\n  [  102.130564][T14893]  migrate_device_finalize+0x9b/0x530\n  [  102.131640][T14893]  dmirror_migrate_to_device.constprop.0+0x7c5/0xad0\n  [  102.133047][T14893]  dmirror_fops_unlocked_ioctl+0x89b/0xc80\n\nLikely, nothing else goes wrong: putting the last folio reference will\nremove the folio from the LRU again.  So besides memcg complaining, adding\nthe folio to be freed to the LRU is just an unnecessary step.\n\nThe new flow resembles what we have in migrate_folio_move(): add the dst\nto the lru, rem\n---truncated---(CVE-2025-21861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix bug on trap in smb2_lock\n\nIf lock count is greater than 1, flags could be old value.\nIt should be checked with flags of smb_lock, not flags.\nIt will cause bug-on trap from locks_free_lock in error handling\nroutine.(CVE-2025-21944)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()\n\nOn the off chance that command stream passed from userspace via\nioctl() call to radeon_vce_cs_parse() is weirdly crafted and\nfirst command to execute is to encode (case 0x03000001), the function\nin question will attempt to call radeon_vce_cs_reloc() with size\nargument that has not been properly initialized. Specifically, \u0026apos;size\u0026apos;\nwill point to \u0026apos;tmp\u0026apos; variable before the latter had a chance to be\nassigned any value.\n\nPlay it safe and init \u0026apos;tmp\u0026apos; with 0, thus ensuring that\nradeon_vce_cs_reloc() will catch an early error in cases like these.\n\nFound by Linux Verification Center (linuxtesting.org) with static\nanalysis tool SVACE.\n\n(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)(CVE-2025-21996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: do not start chip while suspended\n\nChecking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can\nlead to a spurious tpm_chip_start() call:\n\n[35985.503771] i2c i2c-1: Transfer while suspended\n[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810\n[35985.503802] Modules linked in:\n[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G        W          6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f\n[35985.503814] Tainted: [W]=WARN\n[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023\n[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810\n[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 \u0026lt;0f\u0026gt; 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5\n[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246\n[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000\n[35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001\n[35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000\n[35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820\n[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120\n[35985.503846] FS:  0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000\n[35985.503849] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0\n[35985.503855] Call Trace:\n[35985.503859]  \u0026lt;TASK\u0026gt;\n[35985.503863]  ? __warn+0xd4/0x260\n[35985.503868]  ? __i2c_transfer+0xbe/0x810\n[35985.503874]  ? report_bug+0xf3/0x210\n[35985.503882]  ? handle_bug+0x63/0xb0\n[35985.503887]  ? exc_invalid_op+0x16/0x50\n[35985.503892]  ? asm_exc_invalid_op+0x16/0x20\n[35985.503904]  ? __i2c_transfer+0xbe/0x810\n[35985.503913]  tpm_cr50_i2c_transfer_message+0x24/0xf0\n[35985.503920]  tpm_cr50_i2c_read+0x8e/0x120\n[35985.503928]  tpm_cr50_request_locality+0x75/0x170\n[35985.503935]  tpm_chip_start+0x116/0x160\n[35985.503942]  tpm_try_get_ops+0x57/0x90\n[35985.503948]  tpm_find_get_ops+0x26/0xd0\n[35985.503955]  tpm_get_random+0x2d/0x80\n\nDon\u0026apos;t move forward with tpm_chip_start() inside tpm_try_get_ops(), unless\nTPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in\nsuch a failure case.(CVE-2025-23149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Tear down vGIC on failed vCPU creation\n\nIf kvm_arch_vcpu_create() fails to share the vCPU page with the\nhypervisor, we propagate the error back to the ioctl but leave the\nvGIC vCPU data initialised. Note only does this leak the corresponding\nmemory when the vCPU is destroyed but it can also lead to use-after-free\nif the redistributor device handling tries to walk into the vCPU.\n\nAdd the missing cleanup to kvm_arch_vcpu_create(), ensuring that the\nvGIC vCPU structures are destroyed on error.(CVE-2025-37849)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()\n\nNouveau is mostly designed in a way that it\u0026apos;s expected that fences only\never get signaled through nouveau_fence_signal(). However, in at least\none other place, nouveau_fence_done(), can signal fences, too. If that\nhappens (race) a signaled fence remains in the pending list for a while,\nuntil it gets removed by nouveau_fence_update().\n\nShould nouveau_fence_context_kill() run in the meantime, this would be\na bug because the function would attempt to set an error code on an\nalready signaled fence.\n\nHave nouveau_fence_context_kill() check for a fence being signaled.(CVE-2025-37930)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()\n\nIf dib8000_set_dds()\u0026apos;s call to dib8000_read32() returns zero, the result\nis a divide-by-zero.  Prevent that from happening.\n\nFixes the following warning with an UBSAN kernel:\n\n  drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()(CVE-2025-37937)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: bpf: Add BHB mitigation to the epilogue for cBPF programs\n\nA malicious BPF program may manipulate the branch history to influence\nwhat the hardware speculates will happen next.\n\nOn exit from a BPF program, emit the BHB mititgation sequence.\n\nThis is only applied for \u0026apos;classic\u0026apos; cBPF programs that are loaded by\nseccomp.(CVE-2025-37948)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: bpf: Only mitigate cBPF programs loaded by unprivileged users\n\nSupport for eBPF programs loaded by unprivileged users is typically\ndisabled. This means only cBPF programs need to be mitigated for BHB.\n\nIn addition, only mitigate cBPF programs that were loaded by an\nunprivileged user. Privileged users can also load the same program\nvia eBPF, making the mitigation pointless.(CVE-2025-37963)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: uclogic: Add NULL check in uclogic_input_configured()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\nuclogic_input_configured() does not check for this case, which results\nin a NULL pointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue.(CVE-2025-38007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: do not leak refcount in reorder_work\n\nA recent patch that addressed a UAF introduced a reference count leak:\nthe parallel_data refcount is incremented unconditionally, regardless\nof the return value of queue_work(). If the work item is already queued,\nthe incremented refcount is never decremented.\n\nFix this by checking the return value of queue_work() and decrementing\nthe refcount when necessary.\n\nResolves:\n\nUnreferenced object 0xffff9d9f421e3d80 (size 192):\n  comm \u0026quot;cryptomgr_probe\u0026quot;, pid 157, jiffies 4294694003\n  hex dump (first 32 bytes):\n    80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff  ...A............\n    d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00  ..............#.\n  backtrace (crc 838fb36):\n    __kmalloc_cache_noprof+0x284/0x320\n    padata_alloc_pd+0x20/0x1e0\n    padata_alloc_shell+0x3b/0xa0\n    0xffffffffc040a54d\n    cryptomgr_probe+0x43/0xc0\n    kthread+0xf6/0x1f0\n    ret_from_fork+0x2f/0x50\n    ret_from_fork_asm+0x1a/0x30(CVE-2025-38031)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref\n\nbtrfs_prelim_ref() calls the old and new reference variables in the\nincorrect order. This causes a NULL pointer dereference because oldref\nis passed as NULL to trace_btrfs_prelim_ref_insert().\n\nNote, trace_btrfs_prelim_ref_insert() is being called with newref as\noldref (and oldref as NULL) on purpose in order to print out\nthe values of newref.\n\nTo reproduce:\necho 1 \u0026gt; /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable\n\nPerform some writeback operations.\n\nBacktrace:\nBUG: kernel NULL pointer dereference, address: 0000000000000018\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0\n Oops: Oops: 0000 [#1] SMP NOPTI\n CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary)  7ca2cef72d5e9c600f0c7718adb6462de8149622\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014\n RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130\n 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 \u0026lt;49\u0026gt; 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88\n RSP: 0018:ffffce44820077a0 EFLAGS: 00010286\n RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b\n RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010\n RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010\n R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000\n R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540\n FS:  00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0\n PKRU: 55555554\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  prelim_ref_insert+0x1c1/0x270\n  find_parent_nodes+0x12a6/0x1ee0\n  ? __entry_text_end+0x101f06/0x101f09\n  ? srso_alias_return_thunk+0x5/0xfbef5\n  ? srso_alias_return_thunk+0x5/0xfbef5\n  ? srso_alias_return_thunk+0x5/0xfbef5\n  ? srso_alias_return_thunk+0x5/0xfbef5\n  btrfs_is_data_extent_shared+0x167/0x640\n  ? fiemap_process_hole+0xd0/0x2c0\n  extent_fiemap+0xa5c/0xbc0\n  ? __entry_text_end+0x101f05/0x101f09\n  btrfs_fiemap+0x7e/0xd0\n  do_vfs_ioctl+0x425/0x9d0\n  __x64_sys_ioctl+0x75/0xc0(CVE-2025-38034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: copy_verifier_state() should copy \u0026apos;loop_entry\u0026apos; field\n\nThe bpf_verifier_state.loop_entry state should be copied by\ncopy_verifier_state(). Otherwise, .loop_entry values from unrelated\nstates would poison env-\u0026gt;cur_state.\n\nAdditionally, env-\u0026gt;stack should not contain any states with\n.loop_entry != NULL. The states in env-\u0026gt;stack are yet to be verified,\nwhile .loop_entry is set for states that reached an equivalent state.\nThis means that env-\u0026gt;cur_state-\u0026gt;loop_entry should always be NULL after\npop_stack().\n\nSee the selftest in the next commit for an example of the program that\nis not safe yet is accepted by verifier w/o this fix.\n\nThis change has some verification performance impact for selftests:\n\nFile                                Program                       Insns (A)  Insns (B)  Insns   (DIFF)  States (A)  States (B)  States (DIFF)\n----------------------------------  ----------------------------  ---------  ---------  --------------  ----------  ----------  -------------\narena_htab.bpf.o                    arena_htab_llvm                     717        426  -291 (-40.59%)          57          37  -20 (-35.09%)\narena_htab_asm.bpf.o                arena_htab_asm                      597        445  -152 (-25.46%)          47          37  -10 (-21.28%)\narena_list.bpf.o                    arena_list_del                      309        279    -30 (-9.71%)          23          14   -9 (-39.13%)\niters.bpf.o                         iter_subprog_check_stacksafe        155        141    -14 (-9.03%)          15          14    -1 (-6.67%)\niters.bpf.o                         iter_subprog_iters                 1094       1003    -91 (-8.32%)          88          83    -5 (-5.68%)\niters.bpf.o                         loop_state_deps2                    479        725  +246 (+51.36%)          46          63  +17 (+36.96%)\nkmem_cache_iter.bpf.o               open_coded_iter                      63         59     -4 (-6.35%)           7           6   -1 (-14.29%)\nverifier_bits_iter.bpf.o            max_words                            92         84     -8 (-8.70%)           8           7   -1 (-12.50%)\nverifier_iterating_callbacks.bpf.o  cond_break2                         113        107     -6 (-5.31%)          12          12    +0 (+0.00%)\n\nAnd significant negative impact for sched_ext:\n\nFile               Program                 Insns (A)  Insns (B)  Insns         (DIFF)  States (A)  States (B)  States      (DIFF)\n-----------------  ----------------------  ---------  ---------  --------------------  ----------  ----------  ------------------\nbpf.bpf.o          lavd_init                    7039      14723      +7684 (+109.16%)         490        1139     +649 (+132.45%)\nbpf.bpf.o          layered_dispatch            11485      10548         -937 (-8.16%)         848         762       -86 (-10.14%)\nbpf.bpf.o          layered_dump                 7422    1000001  +992579 (+13373.47%)         681       31178  +30497 (+4478.27%)\nbpf.bpf.o          layered_enqueue             16854      71127     +54273 (+322.02%)        1611        6450    +4839 (+300.37%)\nbpf.bpf.o          p2dq_dispatch                 665        791        +126 (+18.95%)          68          78       +10 (+14.71%)\nbpf.bpf.o          p2dq_init                    2343       2980        +637 (+27.19%)         201         237       +36 (+17.91%)\nbpf.bpf.o          refresh_layer_cpumasks      16487     674760   +658273 (+3992.68%)        1770       65370  +63600 (+3593.22%)\nbpf.bpf.o          rusty_select_cpu             1937      40872    +38935 (+2010.07%)         177        3210   +3033 (+1713.56%)\nscx_central.bpf.o  central_dispatch              636       2687      +2051 (+322.48%)          63         227     +164 (+260.32%)\nscx_nest.bpf.o     nest_init                     636        815        +179 (+28.14%)          60          73       +13 (+21.67%)\nscx_qmap.bpf.o     qmap_dispatch      \n---truncated---(CVE-2025-38060)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\norangefs: Do not truncate file size\n\n\u0026apos;len\u0026apos; is used to store the result of i_size_read(), so making \u0026apos;len\u0026apos;\na size_t results in truncation to 4GiB on 32-bit systems.(CVE-2025-38065)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: protect vq-\u0026gt;log_used with vq-\u0026gt;mutex\n\nThe vhost-scsi completion path may access vq-\u0026gt;log_base when vq-\u0026gt;log_used is\nalready set to false.\n\n    vhost-thread                       QEMU-thread\n\nvhost_scsi_complete_cmd_work()\n-\u0026gt; vhost_add_used()\n   -\u0026gt; vhost_add_used_n()\n      if (unlikely(vq-\u0026gt;log_used))\n                                      QEMU disables vq-\u0026gt;log_used\n                                      via VHOST_SET_VRING_ADDR.\n                                      mutex_lock(\u0026amp;vq-\u0026gt;mutex);\n                                      vq-\u0026gt;log_used = false now!\n                                      mutex_unlock(\u0026amp;vq-\u0026gt;mutex);\n\n\t\t\t\t      QEMU gfree(vq-\u0026gt;log_base)\n        log_used()\n        -\u0026gt; log_write(vq-\u0026gt;log_base)\n\nAssuming the VMM is QEMU. The vq-\u0026gt;log_base is from QEMU userpace and can be\nreclaimed via gfree(). As a result, this causes invalid memory writes to\nQEMU userspace.\n\nThe control queue path has the same issue.(CVE-2025-38074)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: pcm: Fix race of buffer access at PCM OSS layer\n\nThe PCM OSS layer tries to clear the buffer with the silence data at\ninitialization (or reconfiguration) of a stream with the explicit call\nof snd_pcm_format_set_silence() with runtime-\u0026gt;dma_area.  But this may\nlead to a UAF because the accessed runtime-\u0026gt;dma_area might be freed\nconcurrently, as it\u0026apos;s performed outside the PCM ops.\n\nFor avoiding it, move the code into the PCM core and perform it inside\nthe buffer access lock, so that it won\u0026apos;t be changed during the\noperation.(CVE-2025-38078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Increase block_sequence array size\n\n[Why]\nIt\u0026apos;s possible to generate more than 50 steps in hwss_build_fast_sequence,\nfor example with a 6-pipe asic where all pipes are in one MPC chain. This\noverflows the block_sequence buffer and corrupts block_sequence_steps,\ncausing a crash.\n\n[How]\nExpand block_sequence to 100 items. A naive upper bound on the possible\nnumber of steps for a 6-pipe asic, ignoring the potential for steps to be\nmutually exclusive, is 91 with current code, therefore 100 is sufficient.(CVE-2025-38080)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Clear table_sz when rproc_shutdown\n\nThere is case as below could trigger kernel dump:\nUse U-Boot to start remote processor(rproc) with resource table\npublished to a fixed address by rproc. After Kernel boots up,\nstop the rproc, load a new firmware which doesn\u0026apos;t have resource table\n,and start rproc.\n\nWhen starting rproc with a firmware not have resource table,\n`memcpy(loaded_table, rproc-\u0026gt;cached_table, rproc-\u0026gt;table_sz)` will\ntrigger dump, because rproc-\u0026gt;cache_table is set to NULL during the last\nstop operation, but rproc-\u0026gt;table_sz is still valid.\n\nThis issue is found on i.MX8MP and i.MX9.\n\nDump as below:\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000000\nMem abort info:\n  ESR = 0x0000000096000004\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x04: level 0 translation fault\nData abort info:\n  ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n  CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000\n[0000000000000000] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nModules linked in:\nCPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38\nHardware name: NXP i.MX8MPlus EVK board (DT)\npstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __pi_memcpy_generic+0x110/0x22c\nlr : rproc_start+0x88/0x1e0\nCall trace:\n __pi_memcpy_generic+0x110/0x22c (P)\n rproc_boot+0x198/0x57c\n state_store+0x40/0x104\n dev_attr_store+0x18/0x2c\n sysfs_kf_write+0x7c/0x94\n kernfs_fop_write_iter+0x120/0x1cc\n vfs_write+0x240/0x378\n ksys_write+0x70/0x108\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x30/0xcc\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n\nClear rproc-\u0026gt;table_sz to address the issue.(CVE-2025-38152)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: fix slab-out-of-bounds read in ea_get()\n\nDuring the \u0026quot;size_check\u0026quot; label in ea_get(), the code checks if the extended\nattribute list (xattr) size matches ea_size. If not, it logs\n\u0026quot;ea_get: invalid extended attribute\u0026quot; and calls print_hex_dump().\n\nHere, EALIST_SIZE(ea_buf-\u0026gt;xattr) returns 4110417968, which exceeds\nINT_MAX (2,147,483,647). Then ea_size is clamped:\n\n\tint size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf-\u0026gt;xattr));\n\nAlthough clamp_t aims to bound ea_size between 0 and 4110417968, the upper\nlimit is treated as an int, causing an overflow above 2^31 - 1. This leads\n\u0026quot;size\u0026quot; to wrap around and become negative (-184549328).\n\nThe \u0026quot;size\u0026quot; is then passed to print_hex_dump() (called \u0026quot;len\u0026quot; in\nprint_hex_dump()), it is passed as type size_t (an unsigned\ntype), this is then stored inside a variable called\n\u0026quot;int remaining\u0026quot;, which is then assigned to \u0026quot;int linelen\u0026quot; which\nis then passed to hex_dump_to_buffer(). In print_hex_dump()\nthe for loop, iterates through 0 to len-1, where len is\n18446744073525002176, calling hex_dump_to_buffer()\non each iteration:\n\n\tfor (i = 0; i \u0026lt; len; i += rowsize) {\n\t\tlinelen = min(remaining, rowsize);\n\t\tremaining -= rowsize;\n\n\t\thex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,\n\t\t\t\t   linebuf, sizeof(linebuf), ascii);\n\n\t\t...\n\t}\n\nThe expected stopping condition (i \u0026lt; len) is effectively broken\nsince len is corrupted and very large. This eventually leads to\nthe \u0026quot;ptr+i\u0026quot; being passed to hex_dump_to_buffer() to get closer\nto the end of the actual bounds of \u0026quot;ptr\u0026quot;, eventually an out of\nbounds access is done in hex_dump_to_buffer() in the following\nfor loop:\n\n\tfor (j = 0; j \u0026lt; len; j++) {\n\t\t\tif (linebuflen \u0026lt; lx + 2)\n\t\t\t\tgoto overflow2;\n\t\t\tch = ptr[j];\n\t\t...\n\t}\n\nTo fix this we should validate \u0026quot;EALIST_SIZE(ea_buf-\u0026gt;xattr)\u0026quot;\nbefore it is utilised.(CVE-2025-39735)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()\n\nIf speed_hz \u0026lt; AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the\nentire amd_spi_freq array without breaking out early, causing \u0026apos;i\u0026apos; to go\nbeyond the array bounds.\n\nFix that by stopping the loop when it gets to the last entry, so the low\nspeed_hz value gets clamped up to AMD_SPI_MIN_HZ.\n\nFixes the following warning with an UBSAN kernel:\n\n  drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()(CVE-2025-40014)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix io_req_prep_async with provided buffers\n\nio_req_prep_async() can import provided buffers, commit the ring state\nby giving up on that before, it\u0026apos;ll be reimported later if needed.(CVE-2025-40364)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-99.0.0.102.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","kernel-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","perf-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-99.0.0.102.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-99.0.0.102.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","kernel-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","perf-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-99.0.0.102.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1730"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47732"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58085"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21854"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21861"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21944"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21996"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23149"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37849"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37930"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37937"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37948"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37963"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38007"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38031"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38034"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38060"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38065"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38074"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38078"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38080"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38152"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39735"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40014"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40364"}],"database_specific":{"severity":"High"}}