{"schema_version":"1.7.2","id":"OESA-2025-1870","modified":"2025-07-18T14:51:03Z","published":"2025-07-18T14:51:03Z","upstream":["CVE-2024-47732","CVE-2025-21861","CVE-2025-21996","CVE-2025-22033","CVE-2025-22101","CVE-2025-22108","CVE-2025-23141","CVE-2025-23149","CVE-2025-37739","CVE-2025-37784","CVE-2025-37808","CVE-2025-37810","CVE-2025-37842","CVE-2025-37849","CVE-2025-37854","CVE-2025-37887","CVE-2025-37930","CVE-2025-37933","CVE-2025-37937","CVE-2025-37948","CVE-2025-37951","CVE-2025-37963","CVE-2025-37968","CVE-2025-37984","CVE-2025-37991","CVE-2025-38007","CVE-2025-38023","CVE-2025-38034","CVE-2025-38060","CVE-2025-38065","CVE-2025-38067","CVE-2025-38072","CVE-2025-38074","CVE-2025-38078","CVE-2025-38080","CVE-2025-38081","CVE-2025-38090","CVE-2025-38094","CVE-2025-38095","CVE-2025-38099","CVE-2025-38108","CVE-2025-38118","CVE-2025-38142","CVE-2025-38146","CVE-2025-38152","CVE-2025-38159","CVE-2025-38163","CVE-2025-38170","CVE-2025-38182","CVE-2025-38195","CVE-2025-38197","CVE-2025-38202","CVE-2025-38229","CVE-2025-38279","CVE-2025-38280","CVE-2025-38320","CVE-2025-38322","CVE-2025-38346","CVE-2025-39735","CVE-2025-40014"],"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\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\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\narm64: Don\u0026apos;t call NULL in do_compat_alignment_fixup()\n\ndo_alignment_t32_to_handler() only fixes up alignment faults for\nspecific instructions; it returns NULL otherwise (e.g. LDREX). When\nthat\u0026apos;s the case, signal to the caller that it needs to proceed with the\nregular alignment fault handling (i.e. SIGBUS). Without this patch, the\nkernel panics:\n\n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n  Mem abort info:\n    ESR = 0x0000000086000006\n    EC = 0x21: IABT (current EL), IL = 32 bits\n    SET = 0, FnV = 0\n    EA = 0, S1PTW = 0\n    FSC = 0x06: level 2 translation fault\n  user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000\n  [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000\n  Internal error: Oops: 0000000086000006 [#1] SMP\n  Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa\u0026gt;\n   libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c\u0026gt;\n  CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1  Debian 6.1.128-1\n  Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021\n  pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : 0x0\n  lr : do_compat_alignment_fixup+0xd8/0x3dc\n  sp : ffff80000f973dd0\n  x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000\n  x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n  x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001\n  x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000\n  x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n  x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488\n  x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\n  x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000\n  x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001\n  Call trace:\n   0x0\n   do_alignment_fault+0x40/0x50\n   do_mem_abort+0x4c/0xa0\n   el0_da+0x48/0xf0\n   el0t_32_sync_handler+0x110/0x140\n   el0t_32_sync+0x190/0x194\n  Code: bad PC value\n  ---[ end trace 0000000000000000 ]---(CVE-2025-22033)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: libwx: fix Tx L4 checksum\n\nThe hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol.\nThere was a bug to set Tx checksum flag for the other protocol that results\nin Tx ring hang. Fix to compute software checksum for these packets.(CVE-2025-22101)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Mask the bd_cnt field in the TX BD properly\n\nThe bd_cnt field in the TX BD specifies the total number of BDs for\nthe TX packet.  The bd_cnt field has 5 bits and the maximum number\nsupported is 32 with the value 0.\n\nCONFIG_MAX_SKB_FRAGS can be modified and the total number of SKB\nfragments can approach or exceed the maximum supported by the chip.\nAdd a macro to properly mask the bd_cnt field so that the value 32\nwill be properly masked and set to 0 in the bd_cnd field.\n\nWithout this patch, the out-of-range bd_cnt value will corrupt the\nTX BD and may cause TX timeout.\n\nThe next patch will check for values exceeding 32.(CVE-2025-22108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses\n\nAcquire a lock on kvm-\u0026gt;srcu when userspace is getting MP state to handle a\nrather extreme edge case where \u0026quot;accepting\u0026quot; APIC events, i.e. processing\npending INIT or SIPI, can trigger accesses to guest memory.  If the vCPU\nis in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP\nstate will trigger a nested VM-Exit by way of -\u0026gt;check_nested_events(), and\nemuating the nested VM-Exit can access guest memory.\n\nThe splat was originally hit by syzkaller on a Google-internal kernel, and\nreproduced on an upstream kernel by hacking the triple_fault_event_test\nselftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a\nmemory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.\n\n  =============================\n  WARNING: suspicious RCU usage\n  6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted\n  -----------------------------\n  include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!\n\n  other info that might help us debug this:\n\n  rcu_scheduler_active = 2, debug_locks = 1\n  1 lock held by triple_fault_ev/1256:\n   #0: ffff88810df5a330 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]\n\n  stack backtrace:\n  CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x7f/0x90\n   lockdep_rcu_suspicious+0x144/0x190\n   kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm]\n   kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n   read_and_check_msr_entry+0x2e/0x180 [kvm_intel]\n   __nested_vmx_vmexit+0x550/0xde0 [kvm_intel]\n   kvm_check_nested_events+0x1b/0x30 [kvm]\n   kvm_apic_accept_events+0x33/0x100 [kvm]\n   kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm]\n   kvm_vcpu_ioctl+0x33e/0x9a0 [kvm]\n   __x64_sys_ioctl+0x8b/0xb0\n   do_syscall_64+0x6c/0x170\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   \u0026lt;/TASK\u0026gt;(CVE-2025-23141)\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\nf2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()\n\nsyzbot reports an UBSAN issue as below:\n\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10\nindex 18446744073709550692 is out of range for type \u0026apos;__le32[5]\u0026apos; (aka \u0026apos;unsigned int[5]\u0026apos;)\nCPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429\n get_nid fs/f2fs/node.h:381 [inline]\n f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181\n f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808\n f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836\n f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886\n f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093\n aio_write+0x56b/0x7c0 fs/aio.c:1633\n io_submit_one+0x8a7/0x18a0 fs/aio.c:2052\n __do_sys_io_submit fs/aio.c:2111 [inline]\n __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f238798cde9\n\nindex 18446744073709550692 (decimal, unsigned long long)\n= 0xfffffffffffffc64 (hexadecimal, unsigned long long)\n= -924 (decimal, long long)\n\nIn f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to\naccess .i_nid[-924], it means both offset[0] and level should zero.\n\nThe possible case should be in f2fs_do_truncate_blocks(), we try to\ntruncate inode size to zero, however, dn.ofs_in_node is zero and\ndn.node_page is not an inode page, so it fails to truncate inode page,\nand then pass zeroed free_from to f2fs_truncate_inode_blocks(), result\nin this issue.\n\n\tif (dn.ofs_in_node || IS_INODE(dn.node_page)) {\n\t\tf2fs_truncate_data_blocks_range(\u0026amp;dn, count);\n\t\tfree_from += count;\n\t}\n\nI guess the reason why dn.node_page is not an inode page could be: there\nare multiple nat entries share the same node block address, once the node\nblock address was reused, f2fs_get_node_page() may load a non-inode block.\n\nLet\u0026apos;s add a sanity check for such condition to avoid out-of-bounds access\nissue.(CVE-2025-37739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ti: icss-iep: Fix possible NULL pointer dereference for perout request\n\nThe ICSS IEP driver tracks perout and pps enable state with flags.\nCurrently when disabling pps and perout signals during icss_iep_exit(),\nresults in NULL pointer dereference for perout.\n\nTo fix the null pointer dereference issue, the icss_iep_perout_enable_hw\nfunction can be modified to directly clear the IEP CMP registers when\ndisabling PPS or PEROUT, without referencing the ptp_perout_request\nstructure, as its contents are irrelevant in this case.(CVE-2025-37784)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: null - Use spin lock instead of mutex\n\nAs the null algorithm may be freed in softirq context through\naf_alg, use spin locks instead of mutexes to protect the default\nnull algorithm.(CVE-2025-37808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: gadget: check that event count does not exceed event buffer length\n\nThe event count is read from register DWC3_GEVNTCOUNT.\nThere is a check for the count being zero, but not for exceeding the\nevent buffer length.\nCheck that event count does not exceed event buffer length,\navoiding an out-of-bounds access when memcpy\u0026apos;ing the event.\nCrash log:\nUnable to handle kernel paging request at virtual address ffffffc0129be000\npc : __memcpy+0x114/0x180\nlr : dwc3_check_event_buf+0xec/0x348\nx3 : 0000000000000030 x2 : 000000000000dfc4\nx1 : ffffffc0129be000 x0 : ffffff87aad60080\nCall trace:\n__memcpy+0x114/0x180\ndwc3_interrupt+0x24/0x34(CVE-2025-37810)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: fsl-qspi: use devm function instead of driver remove\n\nDriver use devm APIs to manage clk/irq/resources and register the spi\ncontroller, but the legacy remove function will be called first during\ndevice detach and trigger kernel panic. Drop the remove function and use\ndevm_add_action_or_reset() for driver cleanup to ensure the release\nsequence.\n\nTrigger kernel panic on i.MX8MQ by\necho 30bb0000.spi \u0026gt;/sys/bus/platform/drivers/fsl-quadspi/unbind(CVE-2025-37842)\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/amdkfd: Fix mode1 reset crash issue\n\nIf HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal\nuser space to abort the processes. After process abort exit, user queues\nstill use the GPU to access system memory before h/w is reset while KFD\ncleanup worker free system memory and free VRAM.\n\nThere is use-after-free race bug that KFD allocate and reuse the freed\nsystem memory, and user queue write to the same system memory to corrupt\nthe data structure and cause driver crash.\n\nTo fix this race, KFD cleanup worker terminate user queues, then flush\nreset_domain wq to wait for any GPU ongoing reset complete, and then\nfree outstanding BOs.(CVE-2025-37854)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result\n\nIf the FW doesn\u0026apos;t support the PDS_CORE_CMD_FW_CONTROL command\nthe driver might at the least print garbage and at the worst\ncrash when the user runs the \u0026quot;devlink dev info\u0026quot; devlink command.\n\nThis happens because the stack variable fw_list is not 0\ninitialized which results in fw_list.num_fw_slots being a\ngarbage value from the stack.  Then the driver tries to access\nfw_list.fw_names[i] with i \u0026gt;= ARRAY_SIZE and runs off the end\nof the array.\n\nFix this by initializing the fw_list and by not failing\ncompletely if the devcmd fails because other useful information\nis printed via devlink dev info even if the devcmd fails.(CVE-2025-37887)\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\nocteon_ep: Fix host hang issue during device reboot\n\nWhen the host loses heartbeat messages from the device,\nthe driver calls the device-specific ndo_stop function,\nwhich frees the resources. If the driver is unloaded in\nthis scenario, it calls ndo_stop again, attempting to free\nresources that have already been freed, leading to a host\nhang issue. To resolve this, dev_close should be called\ninstead of the device-specific stop function.dev_close\ninternally calls ndo_stop to stop the network interface\nand performs additional cleanup tasks. During the driver\nunload process, if the device is already down, ndo_stop\nis not called.(CVE-2025-37933)\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\ndrm/v3d: Add job to pending list if the reset was skipped\n\nWhen a CL/CSD job times out, we check if the GPU has made any progress\nsince the last timeout. If so, instead of resetting the hardware, we skip\nthe reset and let the timer get rearmed. This gives long-running jobs a\nchance to complete.\n\nHowever, when `timedout_job()` is called, the job in question is removed\nfrom the pending list, which means it won\u0026apos;t be automatically freed through\n`free_job()`. Consequently, when we skip the reset and keep the job\nrunning, the job won\u0026apos;t be freed when it finally completes.\n\nThis situation leads to a memory leak, as exposed in [1] and [2].\n\nSimilarly to commit 704d3d60fec4 (\u0026quot;drm/etnaviv: don\u0026apos;t block scheduler when\nGPU is still active\u0026quot;), this patch ensures the job is put back on the\npending list when extending the timeout.(CVE-2025-37951)\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\niio: light: opt3001: fix deadlock due to concurrent flag access\n\nThe threaded IRQ function in this driver is reading the flag twice: once to\nlock a mutex and once to unlock it. Even though the code setting the flag\nis designed to prevent it, there are subtle cases where the flag could be\ntrue at the mutex_lock stage and false at the mutex_unlock stage. This\nresults in the mutex not being unlocked, resulting in a deadlock.\n\nFix it by making the opt3001_irq() code generally more robust, reading the\nflag into a variable and using the variable value at both stages.(CVE-2025-37968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP()\n\nHerbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa\nimplementation\u0026apos;s -\u0026gt;key_size() callback returns an unusually large value.\nHerbert instead suggests (for a division by 8):\n\n  X / 8 + !!(X \u0026amp; 7)\n\nBased on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and\nuse it in lieu of DIV_ROUND_UP() for -\u0026gt;key_size() return values.\n\nAdditionally, use the macro in ecc_digits_from_bytes(), whose \u0026quot;nbytes\u0026quot;\nparameter is a -\u0026gt;key_size() return value in some instances, or a\nuser-specified ASN.1 length in the case of ecdsa_get_signature_rs().(CVE-2025-37984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix double SIGFPE crash\n\nCamm noticed that on parisc a SIGFPE exception will crash an application with\na second SIGFPE in the signal handler.  Dave analyzed it, and it happens\nbecause glibc uses a double-word floating-point store to atomically update\nfunction descriptors. As a result of lazy binding, we hit a floating-point\nstore in fpe_func almost immediately.\n\nWhen the T bit is set, an assist exception trap occurs when when the\nco-processor encounters *any* floating-point instruction except for a double\nstore of register %fr0.  The latter cancels all pending traps.  Let\u0026apos;s fix this\nby clearing the Trap (T) bit in the FP status register before returning to the\nsignal handler in userspace.\n\nThe issue can be reproduced with this test program:\n\nroot@parisc:~# cat fpe.c\n\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\n        sigset_t set;\n        sigemptyset(\u0026amp;set);\n        sigaddset(\u0026amp;set, SIGFPE);\n        sigprocmask(SIG_UNBLOCK, \u0026amp;set, NULL);\n        printf(\u0026quot;GOT signal %d with si_code %ld\\n\u0026quot;, sig, i-\u0026gt;si_code);\n}\n\nint main() {\n        struct sigaction action = {\n                .sa_sigaction = fpe_func,\n                .sa_flags = SA_RESTART|SA_SIGINFO };\n        sigaction(SIGFPE, \u0026amp;action, 0);\n        feenableexcept(FE_OVERFLOW);\n        return printf(\u0026quot;%lf\\n\u0026quot;,1.7976931348623158E308*1.7976931348623158E308);\n}\n\nroot@parisc:~# gcc fpe.c -lm\nroot@parisc:~# ./a.out\n Floating point exception\n\nroot@parisc:~# strace -f ./a.out\n execve(\u0026quot;./a.out\u0026quot;, [\u0026quot;./a.out\u0026quot;], 0xf9ac7034 /* 20 vars */) = 0\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\n ...\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\n +++ killed by SIGFPE +++\n Floating point exception(CVE-2025-37991)\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\nnfs: handle failure of nfs_get_lock_context in unlock path\n\nWhen memory is insufficient, the allocation of nfs_lock_context in\nnfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat\nan nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)\nas valid and proceed to execute rpc_run_task(), this will trigger a NULL\npointer dereference in nfs4_locku_prepare. For example:\n\nBUG: kernel NULL pointer dereference, address: 000000000000000c\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP PTI\nCPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40\nWorkqueue: rpciod rpc_async_schedule\nRIP: 0010:nfs4_locku_prepare+0x35/0xc2\nCode: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3\nRSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246\nRAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40\nRBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38\nR10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030\nR13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30\nFS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __rpc_execute+0xbc/0x480\n rpc_async_schedule+0x2f/0x40\n process_one_work+0x232/0x5d0\n worker_thread+0x1da/0x3d0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x10d/0x240\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\nCR2: 000000000000000c\n---[ end trace 0000000000000000 ]---\n\nFree the allocated nfs4_unlockdata when nfs_get_lock_context() fails and\nreturn NULL to terminate subsequent rpc_run_task, preventing NULL pointer\ndereference.(CVE-2025-38023)\n\nLinux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States.\n There is a security vulnerability in Linux kernel that originates from a wrong parameter order, which may cause null pointers to be dereferenced.(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\nrseq: Fix segfault on registration when rseq_cs is non-zero\n\nThe rseq_cs field is documented as being set to 0 by user-space prior to\nregistration, however this is not currently enforced by the kernel. This\ncan result in a segfault on return to user-space if the value stored in\nthe rseq_cs field doesn\u0026apos;t point to a valid struct rseq_cs.\n\nThe correct solution to this would be to fail the rseq registration when\nthe rseq_cs field is non-zero. However, some older versions of glibc\nwill reuse the rseq area of previous threads without clearing the\nrseq_cs field and will also terminate the process if the rseq\nregistration fails in a secondary thread. This wasn\u0026apos;t caught in testing\nbecause in this case the leftover rseq_cs does point to a valid struct\nrseq_cs.\n\nWhat we can do is clear the rseq_cs field on registration when it\u0026apos;s\nnon-zero which will prevent segfaults on registration and won\u0026apos;t break\nthe glibc versions that reuse rseq areas on thread creation.(CVE-2025-38067)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibnvdimm/labels: Fix divide error in nd_label_data_init()\n\nIf a faulty CXL memory device returns a broken zero LSA size in its\nmemory device information (Identify Memory Device (Opcode 4000h), CXL\nspec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm\ndriver:\n\n Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI\n RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]\n\nCode and flow:\n\n1) CXL Command 4000h returns LSA size = 0\n2) config_size is assigned to zero LSA size (CXL pmem driver):\n\ndrivers/cxl/pmem.c:             .config_size = mds-\u0026gt;lsa_size,\n\n3) max_xfer is set to zero (nvdimm driver):\n\ndrivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd-\u0026gt;nsarea.max_xfer, config_size);\n\n4) A subsequent DIV_ROUND_UP() causes a division by zero:\n\ndrivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */\ndrivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,\ndrivers/nvdimm/label.c-                 config_size);\n\nFix this by checking the config size parameter by extending an\nexisting check.(CVE-2025-38072)\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\nspi-rockchip: Fix register out of bounds access\n\nDo not write native chip select stuff for GPIO chip selects.\nGPIOs can be numbered much higher than native CS.\nAlso, it makes no sense.(CVE-2025-38081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/rapidio/rio_cm.c: prevent possible heap overwrite\n\nIn\n\nriocm_cdev_ioctl(RIO_CM_CHAN_SEND)\n   -\u0026gt; cm_chan_msg_send()\n      -\u0026gt; riocm_ch_send()\n\ncm_chan_msg_send() checks that userspace didn\u0026apos;t send too much data but\nriocm_ch_send() failed to check that userspace sent sufficient data.  The\nresult is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr\nwhich were outside the bounds of the space which cm_chan_msg_send()\nallocated.\n\nAddress this by teaching riocm_ch_send() to check that the entire\nrio_ch_chan_hdr was copied in from userspace.(CVE-2025-38090)\n\nA vulnerability was found in Linux Kernel up to 6.14.7 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-833. The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.This is going to have an impact on availability.Upgrading to version 5.10.238, 5.15.184, 6.1.140, 6.6.92, 6.12.30 or 6.14.8 eliminates this vulnerability. Applying the patch 0772a608d799ac0d127c0a36047a2725777aba9d/64675a9c00443b2e8af42af08c38fc1b78b68ba2/aace6b63892ce8307e502a60fe2f5a4bc6e1cfe7/1d60c0781c1bbeaa1196b0d8aad5c435f06cb7c4/3e64d35475aa21d13dab71da51de51923c1a3a48/84f98955a9de0e0f591df85aa1a44f3ebcf1cb37/c92d6089d8ad7d4d815ebcedee3f3907b539ff1f is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19769).(CVE-2025-38094)\n\nA vulnerability has been found in Linux Kernel up to 6.1.139/6.6.91/6.12.29/6.14.7 (Operating System) and classified as critical.The CWE definition for the vulnerability is CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.As an impact it is known to affect availability.Upgrading to version 6.1.140, 6.6.92, 6.12.30 or 6.14.8 eliminates this vulnerability. Applying the patch 3becc659f9cb76b481ad1fb71f54d5c8d6332d3f/c9d2b9a80d06a58f37e0dc8c827075639b443927/fe1bebd0edb22e3536cbc920ec713331d1367ad4/08680c4dadc6e736c75bc2409d833f03f9003c51/72c7d62583ebce7baeb61acce6057c361f73be4a is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19768).(CVE-2025-38095)\n\nA vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.12.30/6.14.8 (Operating System).CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 6.12.31 or 6.14.9 eliminates this vulnerability. Applying the patch f48ee562c095e552a30b8d9cc0566a267b410f8a/ec1f015ec0c6fd250a6564e8452f7bb3160b9cb1/14d17c78a4b1660c443bae9d38c814edea506f62 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19764).(CVE-2025-38099)\n\nA vulnerability classified as problematic was found in Linux Kernel up to 6.16-rc1 (Operating System).The CWE definition for the vulnerability is CWE-362. The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch 2790c4ec481be45a80948d059cd7c9a06bc37493/a1bf6a4e9264a685b0e642994031f9c5aad72414/110a47efcf23438ff8d31dbd9c854fae2a48bf98/f569984417a4e12c67366e69bdcb752970de921d/2a71924ca4af59ffc00f0444732b6cd54b153d0e/4b755305b2b0618e857fdadb499365b5f2e478d1/444ad445df5496a785705019268a8a84b84484bb/85a3e0ede38450ea3053b8c45d28cf55208409b8 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38108)\n\nA vulnerability was found in Linux Kernel up to 6.1.141/6.6.93/6.12.33/6.15.2/6.16-rc1 (Operating System) and classified as critical.Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch 3c9aba9cbdf163e2654be9f82d43ff8a04273962/9f66b6531c2b4e996bb61720ee94adb4b2e8d1be/9df3e5e7f7e4653fd9802878cedc36defc5ef42d/32aa2fbe319f33b0318ec6f4fceb63879771a286/e6ed54e86aae9e4f7286ce8d5c73780f91b48d1c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38118)\n\nA vulnerability classified as critical has been found in Linux Kernel up to 6.1.141/6.6.93/6.12.33/6.15.2 (Operating System).CWE is classifying the issue as CWE-119. The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 6bf529ce84dccc0074dbc704e70aee4aa545057e/4e9e45746b861ebd54c03ef301da2cb8fc990536/19bd9cde38dd4ca1771aed7afba623e7f4247c8e/7eeb3df6f07a886bdfd52757ede127a59a8784dc/25be318324563c63cbd9cb53186203a08d2f83a1 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38142)\n\nA vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.15.2 (Operating System).Using CWE to declare the problem leads to CWE-129. The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.Impacted is confidentiality, integrity, and availability.Upgrading to version 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 4b9a086eedc1fddae632310386098c12155e3d0a/ad17eb86d042d72a59fd184ad1adf34f5eb36843/f26fe7c3002516dd3c288f1012786df31f4d89e0/8ebcd311b4866ab911d1445ead08690e67f0c488/69541e58323ec3e3904e1fa87a6213961b1f52f4/3c1906a3d50cb94fd0a10e97a1c0a40c0f033cb7/0bdc924bfb319fb10d1113cbf091fc26fb7b1f99 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38146)\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\nA vulnerability classified as problematic has been found in Linux Kernel up to 5.15.185/6.1.141/6.6.93/6.12.33/6.15.2 (Operating System).CWE is classifying the issue as CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.This is going to have an impact on confidentiality.Upgrading to version 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 1ee8ea6937d13b20f90ff35d71ccc03ba448182d/68a1037f0bac4de9a585aa9c879ef886109f3647/74e18211c2c89ab66c9546baa7408288db61aa0d/c13255389499275bc5489a0b5b7940ccea3aef04/9febcc8bded8be0d7efd8237fcef599b6d93b788/4c2c372de2e108319236203cce6de44d70ae15cd is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19785).(CVE-2025-38159)\n\nA vulnerability was found in Linux Kernel up to 6.15.2 (Operating System). It has been rated as problematic.Impacted is confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 49bc7bf38e42cfa642787e947f5721696ea73ac3/f1b743c1955151bd392539b739a3ad155296be13/6a324d77f7ea1a91d55c4b6ad970e3ac9ab6a20d/25f3776b58c1c45ad2e50ab4b263505b4d2378ca/a39cc43efc1bca74ed9d6cf9e60b995071f7d178/65b3f76592aed5a43c4d79375ac097acf975972b/ccc28c0397f75a3ec9539cceed9db014d7b73869/05872a167c2cab80ef186ef23cc34a6776a1a30c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19781).(CVE-2025-38163)\n\nA vulnerability was found in Linux Kernel up to 6.1.141/6.6.93/6.12.33/6.15.2 (Operating System). It has been classified as problematic.CWE is classifying the issue as CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch de89368de3894a8db27caeb8fd902ba1c49f696a/43be952e885476dafb74aa832c0847b2f4f650c6/6103f9ba51a59afb5a0f32299c837377c5a5a693/c4a4786d93e99517d6f10ed56b9ffba4ce88d3b3/d3eaab3c70905c5467e5c4ea403053d67505adeb is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19774).(CVE-2025-38170)\n\nA vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc2 (Operating System).This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 3162d8235c8c4d585525cee8a59d1c180940a968/0f8df5d6f25ac17c52a8bc6418e60a3e63130550/e2b2b7cf6368580114851cb3932f2ad9fbf23386/8c8472855884355caf3d8e0c50adf825f83454b2 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38182)\n\nA vulnerability was found in Linux Kernel (Operating System). It has been declared as problematic.The CWE definition for the vulnerability is CWE-252. The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch b427d98d55217b53c88643579fbbd8a4c351a105/985f086f281b7bbb6644851e63af1a17ffff9277/b5c7397b7fd125203c60b59860c168ee92291272/ee084fa96123ede8b0563a1b5a9b23adc43cd50d is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38195)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc2 (Operating System). It has been rated as critical.Using CWE to declare the problem leads to CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.Impacted is availability.Upgrading to version 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 5e8c658acd1b7c186aeffa46bf08795e121f401a/07d7b8e7ef7d1f812a6211ed531947c56d09e95e/a7b477b64ef5e37cb08dd536ae07c46f9f28262e/f3b840fb1508a80cd8a0efb5c886ae1995a88b24/4d71f2c1e5263a9f042faa71d59515709869dc79/32d05e6cc3a7bf6c8f16f7b7ef8fe80eca0c233e/61ce04601e0d8265ec6d2ffa6df5a7e1bce64854 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38197)\n\nA vulnerability was found in Linux Kernel up to 6.1.141/6.6.94/6.12.34/6.15.3 (Operating System). It has been declared as problematic.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch 2f8c69a72e8ad87b36b8052f789da3cc2b2e186c/7bf4461f1c97207fda757014690d55a447ce859f/2d834477bbc1e8b8a59ff8b0c081529d6bed7b22/b522d4d334f206284b1a44b0b0b2f99fd443b39b/d4965578267e2e81f67c86e2608481e77e9c8569 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38202)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cxusb: no longer judge rbuf when the write fails\n\nsyzbot reported a uninit-value in cxusb_i2c_xfer. [1]\n\nOnly when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()\nsucceeds and rlen is greater than 0, the read operation of usb_bulk_msg()\nwill be executed to read rlen bytes of data from the dvb device into the\nrbuf.\n\nIn this case, although rlen is 1, the write operation failed which resulted\nin the dvb read operation not being executed, and ultimately variable i was\nnot initialized.\n\n[1]\nBUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]\nBUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196\n cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]\n cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196\n __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1\n i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315\n i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343\n i2c_master_send include/linux/i2c.h:109 [inline]\n i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183\n do_loop_readv_writev fs/read_write.c:848 [inline]\n vfs_writev+0x963/0x14e0 fs/read_write.c:1057\n do_writev+0x247/0x5c0 fs/read_write.c:1101\n __do_sys_writev fs/read_write.c:1169 [inline]\n __se_sys_writev fs/read_write.c:1166 [inline]\n __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166\n x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-38229)\n\nA vulnerability was found in Linux Kernel up to 6.15.2/fc2778c42f99c7de52fc004157b3c3ee4dcc208a (Operating System). It has been rated as problematic.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch ac49b7560b4b08b1e4043a29214cc7ad77644c00/e2d2115e56c4a02377189bfc3a9a7933552a7b0f is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38279)\n\nA vulnerability, which was classified as problematic, was found in Linux Kernel (Operating System).CWE is classifying the issue as CWE-74. The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch e7fb4ebee6e900899d2b2e5852c3e2eafcbcad66/ef92b96530d1731d9ac167bc7c193c683cd78fff/6f639c25bfad17d9fd7379ab91ff9678ea9aac85/2bc6dffb4b72d53d6a6ada510269bf548c3f7ae0/0b9bb52796b239de6792d0d68cdc6eb505ebff96/86bc9c742426a16b52a10ef61f5b721aecca2344 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38280)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc2 (Operating System). It has been declared as problematic.The CWE definition for the vulnerability is CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.As an impact it is known to affect confidentiality.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 64773b3ea09235168a549a195cba43bb867c4a17/67abac27d806e8f9d4226ec1528540cf73af673a/92750bfe7b0d8dbcaf578c091a65eda1c5f9ad38/01f91d415a8375d85e0c7d3615cd4a168308bb7c/21da6d3561f373898349ca7167c9811c020da695/22f935bc86bdfbde04009f05eee191d220cd8c89/422e565b7889ebfd9c8705a3fc786642afe61fca/39dfc971e42d886e7df01371cd1bef505076d84c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20926).(CVE-2025-38320)\n\nA vulnerability was found in Linux Kernel up to 6.15.3/6.16-rc2 (Operating System). It has been rated as critical.Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.Upgrading to version 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch a85cc69acdcb05f8cd226b8ea0778b8e2e887e6f/b0823d5fbacb1c551d793cbfe7af24e0d1fa45ed is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38322)\n\nA vulnerability was found in Linux Kernel up to 6.15.3 (Operating System). It has been declared as critical.The CWE definition for the vulnerability is CWE-119. The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch d064c68781c19f378af1ae741d9132d35d24b2bb/8690cd3258455bbae64f809e1d3ee0f043661c71/6805582abb720681dd1c87ff677f155dcf4e86c9/03a162933c4a03b9f1a84f7d8482903c7e1e11bb/83a692a9792aa86249d68a8ac0b9d55ecdd255fa/8e89c17dc8970c5f71a3a991f5724d4c8de42d8c/f78a786ad9a5443a29eef4dae60cde85b7375129/f914b52c379c12288b7623bb814d0508dbe7481d is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38346)\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)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP2","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-101.0.0.107.oe2403sp2"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","bpftool-debuginfo-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","kernel-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","kernel-debuginfo-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","kernel-debugsource-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","kernel-devel-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","kernel-extra-modules-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","kernel-headers-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","kernel-source-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","kernel-tools-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","kernel-tools-debuginfo-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","kernel-tools-devel-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","perf-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","perf-debuginfo-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","python3-perf-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm","python3-perf-debuginfo-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm"],"src":["kernel-6.6.0-101.0.0.107.oe2403sp2.src.rpm"],"x86_64":["bpftool-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","bpftool-debuginfo-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","kernel-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","kernel-debuginfo-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","kernel-debugsource-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","kernel-devel-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","kernel-extra-modules-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","kernel-headers-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","kernel-source-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","kernel-tools-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","kernel-tools-debuginfo-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","kernel-tools-devel-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","perf-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","perf-debuginfo-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","python3-perf-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm","python3-perf-debuginfo-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1870"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47732"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21861"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21996"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22033"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22101"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22108"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23141"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23149"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37739"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37784"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37808"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37810"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37842"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37849"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37854"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37887"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37930"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37933"},{"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-37951"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37963"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37968"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37984"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37991"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38007"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38023"},{"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-38067"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38072"},{"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-38081"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38090"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38094"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38095"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38099"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38108"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38118"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38142"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38146"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38152"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38159"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38163"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38170"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38182"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38195"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38197"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38202"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38229"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38279"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38280"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38320"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38322"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38346"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39735"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40014"}],"database_specific":{"severity":"High"}}