Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
calculating hole sizes. Fix this by detecting this invalid flag combination early in ext4_iget() and rejecting the corrupted inode. References: - https://git.kernel.org/stable/c/4954d297c91d292630ab43ba4d195dc371ce65d3 - https://git.kernel.org/stable/c/f061f7c331fc16250fc82aa68964f35821687217 - https://git.kernel.org/stable/c/2e9e10657b04152ed0d6ecae8d0c02a3405e28f5 - https://git.kernel.org/stable/c/1437c95ab2a28b138d4521653583729f61ccb48b - https://git.kernel.org/stable/c/cb6039b68efa547b676a8a10fc4618d9d1865c23 - https://git.kernel.org/stable/c/de985264eef64be8a90595908f2e6a87946dad34 - https://git.kernel.org/stable/c/1f5ccd22ff482639133f2a0fe08f6d19d0e68717 - https://git.kernel.org/stable
e6a87946dad34 - https://git.kernel.org/stable/c/1f5ccd22ff482639133f2a0fe08f6d19d0e68717 - https://git.kernel.org/stable/c/1d3ad183943b38eec2acf72a0ae98e635dc8456b
CVE ID: CVE-2025-40168 State: PUBLISHED Published: 2025-11-12T10:46:51.422Z Last Updated: 2025-11-12T10:46:51.422Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match(). smc_clc_prfx_match() is called from smc_listen_work() and not under RCU nor RTNL. Using sk_dst_get(sk)->dev could trigger UAF. Let's use __sk_dst_get() and dst_dev_rcu(). Note that the returned value of smc_clc_prfx_match() is not used in the caller. References: - https://git.kernel.org/stable/c/d26e80f7fb62d77757b67a1b94e4ac756bc9c658 - https://git.kernel.org/stable/c/235f81045c008169cc4e1955b4a64e118e
g/stable/c/d26e80f7fb62d77757b67a1b94e4ac756bc9c658 - https://git.kernel.org/stable/c/235f81045c008169cc4e1955b4a64e118eebe61b
CVE ID: CVE-2025-40169 State: PUBLISHED Published: 2025-11-12T10:46:51.736Z Last Updated: 2025-11-12T10:46:51.736Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative offsets for ALU ops When verifying BPF programs, the check_alu_op() function validates instructions with ALU operations. The 'offset' field in these instructions is a signed 16-bit integer. The existing check 'insn->off > 1' was intended to ensure the offset is either 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn->off' is signed, this check incorrectly accepts all negative values (e.g., -1). This commit tightens the validation by changing the
gned, this check incorrectly accepts all negative values (e.g., -1). This commit tightens the validation by changing the condition to '(insn->off != 0 && insn->off != 1)'. This ensures that any value other than the explicitly permitted 0 and 1 is rejected, hardening the verifier against malformed BPF programs. References: - https://git.kernel.org/stable/c/3bce44b344040e5eef3d64d38b157c15304c0aab - https://git.kernel.org/stable/c/5017c302ca4b2a45149ad64e058fa2d5623c068f - https://git.kernel.org/stable/c/21167bf70dbe400563e189ac632258d35eda38b5 - https://git.kernel.org/stable/c/55c0ced59fe17dee34e9dfd5f7be63cbab207758
CVE ID: CVE-2025-40170 State: PUBLISHED Published: 2025-11-12T10:46:52.014Z Last Updated: 2025-11-12T10:46:52.014Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: use dst_dev_rcu() in sk_setup_caps() Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size(). Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward(). ip4_dst_hoplimit() can use dst_dev_net_rcu(). References: - https://git.kernel.org/stable/c/a805729c0091073d8f0415cfa96c7acd1bc17a48 - https://git.kernel.org/stable/c/99a2ace61b211b0be861b07fbaa062fca4b58879
CVE ID: CVE-2025-40171 State: PUBLISHED Published: 2025-11-12T10:46:52.289Z Last Updated: 2025-11-12T10:46:52.289Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: move lsop put work to nvmet_fc_ls_req_op It’s possible for more than one async command to be in flight from __nvmet_fc_send_ls_req. For each command, a tgtport reference is taken. In the current code, only one put work item is queued at a time, which results in a leaked reference. To fix this, move the work item to the nvmet_fc_ls_req_op struct, which already tracks all resources related to the command. References: - https://git.kernel.org/stable/c/11269c0801
uct, which already tracks all resources related to the command. References: - https://git.kernel.org/stable/c/11269c08013f4ee8b8f5edc6c56700acb34092d0 - https://git.kernel.org/stable/c/a28112cc55013cd8cbd5d36b5115a5b851151bd9 - https://git.kernel.org/stable/c/060ecc81240ef9d60d9485a3a5eb55a0d6e7a25c - https://git.kernel.org/stable/c/7331925c247b03b7767b8cd93cfe1b7aa2377850 - https://git.kernel.org/stable/c/7a619f8c869117ffed08365b377f66b7e1d941b4 - https://git.kernel.org/stable/c/db5a5406fb7e5337a074385c7a3e53c77f2c1bd3
CVE ID: CVE-2025-40172 State: PUBLISHED Published: 2025-11-12T10:53:49.245Z Last Updated: 2025-11-12T10:53:49.245Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages() Currently, if find_and_map_user_pages() takes a DMA xfer request from the user with a length field set to 0, or in a rare case, the host receives QAIC_TRANS_DMA_XFER_CONT from the device where resources->xferred_dma_size is equal to the requested transaction size, the function will return 0 before allocating an sgt or setting the fields of the dma_xfer struct. In that case, encode_addr_size_pairs()
return 0 before allocating an sgt or setting the fields of the dma_xfer struct. In that case, encode_addr_size_pairs() will try to access the sgt which will lead to a general protection fault. Return an EINVAL in case the user provides a zero-sized ALP, or the device requests continuation after all of the bytes have been transferred. References: - https://git.kernel.org/stable/c/48b1d42286bfef7628b1d6c8c28d4e456c90f725 - https://git.kernel.org/stable/c/551f1dfbcb7f3e6ed07f9d6c8c1c64337fcd0ede - https://git.kernel.org/stable/c/1ab9733d14cc9987cc5dcd1f0ad1f416e302e2e6 - https://git.kernel.org/stable/c/11f08c30a3e4157305ba692f1d44cca5fc9a8fca
CVE ID: CVE-2025-40173 State: PUBLISHED Published: 2025-11-12T10:53:49.571Z Last Updated: 2025-11-12T10:53:49.571Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/ip6_tunnel: Prevent perpetual tunnel growth Similarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too. While ipv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"), ipv6 tunnel yet increases the headroom without any ceiling. Reflect ipv4 tunnel headroom adjustment limit on ipv6 version. Credits to Francesco Ruggeri, who was originally debugging this issue and wrote local Arista-
ent limit on ipv6 version. Credits to Francesco Ruggeri, who was originally debugging this issue and wrote local Arista-specific patch and a reproducer. References: - https://git.kernel.org/stable/c/566f8d5c8a443f2dd69c5460fdec43ed1c870c65 - https://git.kernel.org/stable/c/11f6066af3bfb8149aa16c42c0b0c5ea5b199a94 - https://git.kernel.org/stable/c/402b6985e872b4cf394bbbf33b503947a326a6cb - https://git.kernel.org/stable/c/10fe967efe73c610e526ff7460581610633dee9c - https://git.kernel.org/stable/c/48294a67863c9cfa367abb66bbf0ef6548ae124f - https://git.kernel.org/stable/c/eeb4345488672584db4f8c20a1ae13a212ce31c4 - https://git.kernel.org/stable/c/b6eb25d870f1a8ae571fd3da2244b71df547824b - https://
5488672584db4f8c20a1ae13a212ce31c4 - https://git.kernel.org/stable/c/b6eb25d870f1a8ae571fd3da2244b71df547824b - https://git.kernel.org/stable/c/21f4d45eba0b2dcae5dbc9e5e0ad08735c993f16
CVE ID: CVE-2025-40174 State: PUBLISHED Published: 2025-11-12T10:53:49.859Z Last Updated: 2025-11-12T10:53:49.859Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix SMP ordering in switch_mm_irqs_off() Stephen noted that it is possible to not have an smp_mb() between the loaded_mm store and the tlb_gen load in switch_mm(), meaning the ordering against flush_tlb_mm_range() goes out the window, and it becomes possible for switch_mm() to not observe a recent tlb_gen update and fail to flush the TLBs. [ dhansen: merge conflict fixed by Ingo ] References: - https://git.kernel.org/stable/c/0fe5e3f5fb75c5d88dad24dece3ee75e9d8
hansen: merge conflict fixed by Ingo ] References: - https://git.kernel.org/stable/c/0fe5e3f5fb75c5d88dad24dece3ee75e9d87adeb - https://git.kernel.org/stable/c/83b0177a6c4889b3a6e865da5e21b2c9d97d0551
CVE ID: CVE-2025-40175 State: PUBLISHED Published: 2025-11-12T10:53:50.166Z Last Updated: 2025-11-12T10:53:50.166Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: idpf: cleanup remaining SKBs in PTP flows When the driver requests Tx timestamp value, one of the first steps is to clone SKB using skb_get. It increases the reference counter for that SKB to prevent unexpected freeing by another component. However, there may be a case where the index is requested, SKB is assigned and never consumed by PTP flows - for example due to reset during running PTP apps. Add a check in release timestamping function to verify if the SKB assigne
example due to reset during running PTP apps. Add a check in release timestamping function to verify if the SKB assigned to Tx timestamp latch was freed, and release remaining SKBs. References: - https://git.kernel.org/stable/c/2c84e91ef831d4fedb0b94670b3cfd1cc5f966a5 - https://git.kernel.org/stable/c/a3f8c0a273120fd2638f03403e786c3de2382e72
CVE ID: CVE-2025-40176 State: PUBLISHED Published: 2025-11-12T10:53:50.443Z Last Updated: 2025-11-12T10:53:50.443Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tls: wait for pending async decryptions if tls_strp_msg_hold fails Async decryption calls tls_strp_msg_hold to create a clone of the input skb to hold references to the memory it uses. If we fail to allocate that clone, proceeding with async decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, wait for all pending decryption requests. References: - https://git.kernel.org/stable/c/9f83fd0
returned). In this case, wait for all pending decryption requests. References: - https://git.kernel.org/stable/c/9f83fd0c179e0f458e824e417f9d5ad53443f685 - https://git.kernel.org/stable/c/c61d4368197d65c4809d9271f3b85325a600586a - https://git.kernel.org/stable/c/39dec4ea3daf77f684308576baf483b55ca7f160 - https://git.kernel.org/stable/c/4fc109d0ab196bd943b7451276690fb6bb48c2e0 - https://git.kernel.org/stable/c/b8a6ff84abbcbbc445463de58704686011edc8e1
CVE ID: CVE-2025-40177 State: PUBLISHED Published: 2025-11-12T10:53:50.737Z Last Updated: 2025-11-12T10:53:50.737Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Fix bootlog initialization ordering As soon as we queue MHI buffers to receive the bootlog from the device, we could be receiving data. Therefore all the resources needed to process that data need to be setup prior to queuing the buffers. We currently initialize some of the resources after queuing the buffers which creates a race between the probe() and any data that comes back from the device. If the uninitialized resources are accessed, we could see page
he probe() and any data that comes back from the device. If the uninitialized resources are accessed, we could see page faults. Fix the init ordering to close the race. References: - https://git.kernel.org/stable/c/646868e6962b14e25ae7462fdd1fb061b40c1f16 - https://git.kernel.org/stable/c/48814afc7372f96a9584125c8508dffc88d1d378 - https://git.kernel.org/stable/c/fd6e385528d8f85993b7bfc6430576136bb14c65
CVE ID: CVE-2025-40178 State: PUBLISHED Published: 2025-11-12T21:56:24.051Z Last Updated: 2025-11-12T21:56:24.051Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pid: Add a judgment for ns null in pid_nr_ns __task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) { Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns. For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits
at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28
TYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 000000
7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc
xit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt References: - https://git.kernel.org/stable/c/75dbc029c5359438be4a6f908bfbfdab969af776 - https://git.kernel.org/stable/c/c2d09d724856b6f82ab688f65fc1ce833bb56333 - https://git.kernel.org/stable/c/c3b654021931dc806ba086c549e8756c3f204a67 - https://git.kernel.org/stable/c/e10c36a771c5cc910abd9fe4aa9033ee32a47c38 - https://git.kernel.org/stable/c/09d227c59d97efda7d5cc878a4335a6b2bb224c2 - https://git.
c5cc910abd9fe4aa9033ee32a47c38 - https://git.kernel.org/stable/c/09d227c59d97efda7d5cc878a4335a6b2bb224c2 - https://git.kernel.org/stable/c/2076b916bf41be48799d1443df0f8fc75d12ccd0 - https://git.kernel.org/stable/c/a0212978af1825b37da0b453b94d9b0e5af11478 - https://git.kernel.org/stable/c/006568ab4c5ca2309ceb36fa553e390b4aa9c0c7
CVE ID: CVE-2025-40179 State: PUBLISHED Published: 2025-11-12T21:56:24.882Z Last Updated: 2025-11-12T21:56:24.882Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: verify orphan file size is not too big In principle orphan file can be arbitrarily large. However orphan replay needs to traverse it all and we also pin all its buffers in memory. Thus filesystems with absurdly large orphan files can lead to big amounts of memory consumed. Limit orphan file size to a sane value and also use kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for sane but large orphan files. References:
ting array of block descriptor structures to avoid large order allocations for sane but large orphan files. References: - https://git.kernel.org/stable/c/95a21611b14ae0a401720645245a8db16f040995 - https://git.kernel.org/stable/c/566a1d6084563bd07433025aa23bcea4427de107 - https://git.kernel.org/stable/c/304fc34ff6fc8261138fd81f119e024ac3a129e9 - https://git.kernel.org/stable/c/a2d803fab8a6c6a874277cb80156dc114db91921 - https://git.kernel.org/stable/c/2b9da798ff0f4d026c5f0f815047393ebe7d8859 - https://git.kernel.org/stable/c/0a6ce20c156442a4ce2a404747bb0fb05d54eeb3
CVE ID: CVE-2025-40180 State: PUBLISHED Published: 2025-11-12T21:56:25.395Z Last Updated: 2025-11-12T21:56:25.395Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop The cleanup loop was starting at the wrong array index, causing out-of-bounds access. Start the loop at the correct index for zero-indexed arrays to prevent accessing memory beyond the allocated array bounds. References: - https://git.kernel.org/stable/c/cd0cbf2713f6e027ebba867cb7409ae345a31312 - https://git.kernel.org/stable/c/ab96f08ecedd263ecaab9df8455bfb23b07fdcc2 - https://git.kernel.org/stable/
9ae345a31312 - https://git.kernel.org/stable/c/ab96f08ecedd263ecaab9df8455bfb23b07fdcc2 - https://git.kernel.org/stable/c/0aead8197fc1a85b0a89646e418feb49a564b029
CVE ID: CVE-2025-40181 State: PUBLISHED Published: 2025-11-12T21:56:25.930Z Last Updated: 2025-11-12T21:56:25.930Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP When running as an SNP or TDX guest under KVM, force the legacy PCI hole, i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC via a forced variable MTRR range. In most KVM-based setups, legacy devices such as the HPET and TPM are enumerated via ACPI. ACPI enumeration includes a Memory32Fixed entry, and optionally a SystemMemory descriptor for an OperationRegion, e.g. if the dev
eration includes a Memory32Fixed entry, and optionally a SystemMemory descriptor for an OperationRegion, e.g. if the device needs to be accessed via a Control Method. If a SystemMemory entry is present, then the kernel's ACPI driver will auto-ioremap the region so that it can be accessed at will. However, the ACPI spec doesn't provide a way to enumerate the memory type of SystemMemory regions, i.e. there's no way to tell software that a region must be mapped as UC vs. WB, etc. As a result, Linux's ACPI driver always maps SystemMemory regions using ioremap_cache(), i.e. as WB on x86. The dedicated device drivers however, e.g. the HPET driver and TPM driver, want to map their associated memory
B on x86. The dedicated device drivers however, e.g. the HPET driver and TPM driver, want to map their associated memory as UC or WC, as accessing PCI devices using WB is unsupported. On bare metal and non-CoCO, the conflicting requirements "work" as firmware configures the PCI hole (and other device memory) to be UC in the MTRRs. So even though the ACPI mappings request WB, they are forced to UC- in the kernel's tracking due to the kernel properly handling the MTRR overrides, and thus are compatible with the drivers' requested WC/UC-. With force WB MTRRs on SNP and TDX guests, the ACPI mappings get their requested WB if the ACPI mappings are established before the dedicated driver code atte
sts, the ACPI mappings get their requested WB if the ACPI mappings are established before the dedicated driver code attempts to initialize the device. E.g. if acpi_init() runs before the corresponding device driver is probed, ACPI's WB mapping will "win", and result in the driver's ioremap() failing because the existing WB mapping isn't compatible with the requested WC/UC-. E.g. when a TPM is emulated by the hypervisor (ignoring the security implications of relying on what is allegedly an untrusted entity to store measurements), the TPM driver will request UC and fail: [ 1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0 [ 1.732780] tpm_tis MSFT0101:00: probe with driv
730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0 [ 1.732780] tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -12 Note, the '0x2' and '0x0' values refer to "enum page_cache_mode", not x86's memtypes (which frustratingly are an almost pure inversion; 2 == WB, 0 == UC). E.g. tracing mapping requests for TPM TIS yields: Mapping TPM TIS with req_type = 0 WARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460 Modules linked in: CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.16.0-rc7+ #2 VOLUNTARY Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025 RIP: 0010:memtype_re
[W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025 RIP: 0010:memtype_reserve+0x2ab/0x460 __ioremap_caller+0x16d/0x3d0 ioremap_cache+0x17/0x30 x86_acpi_os_ioremap+0xe/0x20 acpi_os_map_iomem+0x1f3/0x240 acpi_os_map_memory+0xe/0x20 acpi_ex_system_memory_space_handler+0x273/0x440 acpi_ev_address_space_dispatch+0x176/0x4c0 acpi_ex_access_region+0x2ad/0x530 acpi_ex_field_datum_io+0xa2/0x4f0 acpi_ex_extract_from_field+0x296/0x3e0 acpi_ex_read_data_from_field+0xd1/0x460 acpi_ex_resolve_node_to_value+0x2ee/0x530 acpi_ex_resolve_to_value+0x1f2/0x540 acpi_ds_evaluate_name_path+0x11b/0x190 acpi_ds_exec_end_op+0x456/0x960 acpi_ps_parse_loop+0x27a/0xa50 acp
ue+0x1f2/0x540 acpi_ds_evaluate_name_path+0x11b/0x190 acpi_ds_exec_end_op+0x456/0x960 acpi_ps_parse_loop+0x27a/0xa50 acpi_ps_parse_aml+0x226/0x600 acpi_ps_execute_method+0x172/0x3e0 acpi_ns_evaluate+0x175/0x5f0 acpi_evaluate_object+0x213/0x490 acpi_evaluate_integer+0x6d/0x140 acpi_bus_get_status+0x93/0x150 acpi_add_single_object+0x43a/0x7c0 acpi_bus_check_add+0x149/0x3a0 acpi_bus_check_add_1+0x16/0x30 acpi_ns_walk_namespace+0x22c/0x360 acpi_walk_namespace+0x15c/0x170 acpi_bus_scan+0x1dd/0x200 acpi_scan_init+0xe5/0x2b0 acpi_init+0x264/0x5b0 do_one_i ---truncated--- References: - https://git.kernel.org/stable/c/34ff466f74d0fe1db8956f9c245e2bb2c67f67bf - https://git.kernel.org/stable/c/91ab8a21
s: - https://git.kernel.org/stable/c/34ff466f74d0fe1db8956f9c245e2bb2c67f67bf - https://git.kernel.org/stable/c/91ab8a21bda2d2d2842b6159ac060d9100433a3c - https://git.kernel.org/stable/c/0dccbc75e18df85399a71933d60b97494110f559
CVE ID: CVE-2025-40182 State: PUBLISHED Published: 2025-11-12T21:56:26.699Z Last Updated: 2025-11-12T21:56:26.699Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: skcipher - Fix reqsize handling Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks. However, this is being recommended for use in all crypto algs [1] instead of setting reqsize using crypto_*_set_r