Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
works. However, this is being recommended for use in all crypto algs [1] instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in skcipher algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [2] Add proper set_reqsize calls in the skcipher init function to properly initialize reqsize for these algorithms in the framework. [1]: https://lore.kernel.org/linux-crypto/aCL8BxpHr5OpT04k@gondor.apana.org.au/ [2]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b References: - https://git.kernel.org/stable/c/f041339d6b9a5a46437f0c48fc727
m/Pratham-T/24247446f1faf4b7843e4014d5089f6b References: - https://git.kernel.org/stable/c/f041339d6b9a5a46437f0c48fc7279c92af7a513 - https://git.kernel.org/stable/c/229c586b5e86979badb7cb0d38717b88a9e95ddd
CVE ID: CVE-2025-40183 State: PUBLISHED Published: 2025-11-12T21:56:27.429Z Last Updated: 2025-11-12T21:56:27.429Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6} Cilium has a BPF egress gateway feature which forces outgoing K8s Pod traffic to pass through dedicated egress gateways which then SNAT the traffic in order to interact with stable IPs outside the cluster. The traffic is directed to the gateway via vxlan tunnel in collect md mode. A recent BPF change utilized the bpf_redirect_neigh() helper to forward packets after the arrival and decap on vxlan, which turned out o
nge utilized the bpf_redirect_neigh() helper to forward packets after the arrival and decap on vxlan, which turned out over time that the kmalloc-256 slab usage in kernel was ever-increasing. The issue was that vxlan allocates the metadata_dst object and attaches it through a fake dst entry to the skb. The latter was never released though given bpf_redirect_neigh() was merely setting the new dst entry via skb_dst_set() without dropping an existing one first. References: - https://git.kernel.org/stable/c/3fba965a9aac0fa3cbd8138436a37af9ab466d79 - https://git.kernel.org/stable/c/057764172fcc6ee2ccb6c41351a55a9f054dc8fd - https://git.kernel.org/stable/c/2e67c2037382abb56497bb9d7b7e10be04eb5598
e/c/057764172fcc6ee2ccb6c41351a55a9f054dc8fd - https://git.kernel.org/stable/c/2e67c2037382abb56497bb9d7b7e10be04eb5598 - https://git.kernel.org/stable/c/b6bfe44b6dbb14a31d86c475cdc9c7689534fb09 - https://git.kernel.org/stable/c/f36a305d30f557306d87c787ddffe094ac5dac89 - https://git.kernel.org/stable/c/7404ce888a45eb7da0508b7cbbe6f2e95302eeb8 - https://git.kernel.org/stable/c/23f3770e1a53e6c7a553135011f547209e141e72
CVE ID: CVE-2025-40184 State: PUBLISHED Published: 2025-11-12T21:56:28.044Z Last Updated: 2025-11-12T21:56:28.044Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix debug checking for np-guests using huge mappings When running with transparent huge pages and CONFIG_NVHE_EL2_DEBUG then the debug checking in assert_host_shared_guest() fails on the launch of an np-guest. This WARN_ON() causes a panic and generates the stack below. In __pkvm_host_relax_perms_guest() the debug checking assumes the mapping is a single page but it may be a block map. Update the checking so that the size is not checked and just assumes the
ing is a single page but it may be a block map. Update the checking so that the size is not checked and just assumes the correct size. While we're here make the same fix in __pkvm_host_mkyoung_guest(). Info: # lkvm run -k /share/arch/arm64/boot/Image -m 704 -c 8 --name guest-128 Info: Removed ghost socket file "/.lkvm//guest-128.sock". [ 1406.521757] kvm [141]: nVHE hyp BUG at: arch/arm64/kvm/hyp/nvhe/mem_protect.c:1088! [ 1406.521804] kvm [141]: nVHE call trace: [ 1406.521828] kvm [141]: [<ffff8000811676b4>] __kvm_nvhe_hyp_panic+0xb4/0xe8 [ 1406.521946] kvm [141]: [<ffff80008116d12c>] __kvm_nvhe_assert_host_shared_guest+0xb0/0x10c [ 1406.522049] kvm [141]: [<ffff80008116f068>] __kvm_nvhe___
008116d12c>] __kvm_nvhe_assert_host_shared_guest+0xb0/0x10c [ 1406.522049] kvm [141]: [<ffff80008116f068>] __kvm_nvhe___pkvm_host_relax_perms_guest+0x48/0x104 [ 1406.522157] kvm [141]: [<ffff800081169df8>] __kvm_nvhe_handle___pkvm_host_relax_perms_guest+0x64/0x7c [ 1406.522250] kvm [141]: [<ffff800081169f0c>] __kvm_nvhe_handle_trap+0x8c/0x1a8 [ 1406.522333] kvm [141]: [<ffff8000811680fc>] __kvm_nvhe___skip_pauth_save+0x4/0x4 [ 1406.522454] kvm [141]: ---[ end nVHE call trace ]--- [ 1406.522477] kvm [141]: Hyp Offset: 0xfffece8013600000 [ 1406.522554] Kernel panic - not syncing: HYP panic: [ 1406.522554] PS:834003c9 PC:0000b1806db6d170 ESR:00000000f2000800 [ 1406.522554] FAR:ffff8000804be420
ing: HYP panic: [ 1406.522554] PS:834003c9 PC:0000b1806db6d170 ESR:00000000f2000800 [ 1406.522554] FAR:ffff8000804be420 HPFAR:0000000000804be0 PAR:0000000000000000 [ 1406.522554] VCPU:0000000000000000 [ 1406.523337] CPU: 3 UID: 0 PID: 141 Comm: kvm-vcpu-0 Not tainted 6.16.0-rc7 #97 PREEMPT [ 1406.523485] Hardware name: FVP Base RevC (DT) [ 1406.523566] Call trace: [ 1406.523629] show_stack+0x18/0x24 (C) [ 1406.523753] dump_stack_lvl+0xd4/0x108 [ 1406.523899] dump_stack+0x18/0x24 [ 1406.524040] panic+0x3d8/0x448 [ 1406.524184] nvhe_hyp_panic_handler+0x10c/0x23c [ 1406.524325] kvm_handle_guest_abort+0x68c/0x109c [ 1406.524500] handle_exit+0x60/0x17c [ 1406.524630] kvm_arch_vcpu_ioctl_run+0x2e0
] kvm_handle_guest_abort+0x68c/0x109c [ 1406.524500] handle_exit+0x60/0x17c [ 1406.524630] kvm_arch_vcpu_ioctl_run+0x2e0/0x8c0 [ 1406.524794] kvm_vcpu_ioctl+0x1a8/0x9cc [ 1406.524919] __arm64_sys_ioctl+0xac/0x104 [ 1406.525067] invoke_syscall+0x48/0x10c [ 1406.525189] el0_svc_common.constprop.0+0x40/0xe0 [ 1406.525322] do_el0_svc+0x1c/0x28 [ 1406.525441] el0_svc+0x38/0x120 [ 1406.525588] el0t_64_sync_handler+0x10c/0x138 [ 1406.525750] el0t_64_sync+0x1ac/0x1b0 [ 1406.525876] SMP: stopping secondary CPUs [ 1406.525965] Kernel Offset: disabled [ 1406.526032] CPU features: 0x0000,00000080,8e134ca1,9446773f [ 1406.526130] Memory Limit: none [ 1406.959099] ---[ end Kernel panic - not syncing: HYP
00,00000080,8e134ca1,9446773f [ 1406.526130] Memory Limit: none [ 1406.959099] ---[ end Kernel panic - not syncing: HYP panic: [ 1406.959099] PS:834003c9 PC:0000b1806db6d170 ESR:00000000f2000800 [ 1406.959099] FAR:ffff8000804be420 HPFAR:0000000000804be0 PAR:0000000000000000 [ 1406.959099] VCPU:0000000000000000 ] References: - https://git.kernel.org/stable/c/4f7af3d8a1177c807d1f2563c7c171700b020656 - https://git.kernel.org/stable/c/2ba972bf71cb71d2127ec6c3db1ceb6dd0c73173
CVE ID: CVE-2025-40185 State: PUBLISHED Published: 2025-11-12T21:56:28.561Z Last Updated: 2025-11-12T21:56:28.561Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: ice_adapter: release xa entry on adapter allocation failure When ice_adapter_new() fails, the reserved XArray entry created by xa_insert() is not released. This causes subsequent insertions at the same index to return -EBUSY, potentially leading to NULL pointer dereferences. Reorder the operations as suggested by Przemek Kitszel: 1. Check if adapter already exists (xa_load) 2. Reserve the XArray slot (xa_reserve) 3. Allocate the adapter (ice_adapter_new) 4. Store
ter already exists (xa_load) 2. Reserve the XArray slot (xa_reserve) 3. Allocate the adapter (ice_adapter_new) 4. Store the adapter (xa_store) References: - https://git.kernel.org/stable/c/7b9269de9815fc34d93dab90bd5169bacbe78e70 - https://git.kernel.org/stable/c/794abb265de3e792167fe3ea0440c064c722bb84 - https://git.kernel.org/stable/c/2db687f3469dbc5c59bc53d55acafd75d530b497
CVE ID: CVE-2025-40186 State: PUBLISHED Published: 2025-11-12T21:56:29.033Z Last Updated: 2025-11-12T21:56:29.033Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request(). syzbot reported the splat below in tcp_conn_request(). [0] If a listener is close()d while a TFO socket is being processed in tcp_conn_request(), inet_csk_reqsk_queue_add() does not set reqsk->sk and calls inet_child_forget(), which calls tcp_disconnect() for the TFO socket. After the cited commit, tcp_disconnect() calls reqsk_fastopen_remove(), where reqsk_put() is called due to !reqsk->sk. Then, reqsk_fas
d commit, tcp_disconnect() calls reqsk_fastopen_remove(), where reqsk_put() is called due to !reqsk->sk. Then, reqsk_fastopen_remove() in tcp_conn_request() decrements the last req->rsk_refcnt and frees reqsk, and __reqsk_free() at the drop_and_free label causes the refcount underflow for the listener and double-free of the reqsk. Let's remove reqsk_fastopen_remove() in tcp_conn_request(). Note that other callers make sure tp->fastopen_rsk is not NULL. [0]: refcount_t: underflow; use-after-free. WARNING: CPU: 12 PID: 5563 at lib/refcount.c:28 refcount_warn_saturate (lib/refcount.c:28) Modules linked in: CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardwa
count.c:28) Modules linked in: CPU: 12 UID: 0 PID: 5563 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:refcount_warn_saturate (lib/refcount.c:28) Code: ab e8 8e b4 98 ff 0f 0b c3 cc cc cc cc cc 80 3d a4 e4 d6 01 00 75 9c c6 05 9b e4 d6 01 01 48 c7 c7 e8 df fb ab e8 6a b4 98 ff <0f> 0b e9 03 5b 76 00 cc 80 3d 7d e4 d6 01 00 0f 85 74 ff ff ff c6 RSP: 0018:ffffa79fc0304a98 EFLAGS: 00010246 RAX: d83af4db1c6b3900 RBX: ffff9f65c7a69020 RCX: d83af4db1c6b3900 RDX: 0000000000000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280 RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280 R
00000000 RSI: 00000000ffff7fff RDI: ffffffffac78a280 RBP: 000000009d781b60 R08: 0000000000007fff R09: ffffffffac6ca280 R10: 0000000000017ffd R11: 0000000000000004 R12: ffff9f65c7b4f100 R13: ffff9f65c7d23c00 R14: ffff9f65c7d26000 R15: ffff9f65c7a64ef8 FS: 00007f9f962176c0(0000) GS:ffff9f65fcf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000200000000180 CR3: 000000000dbbe006 CR4: 0000000000372ef0 Call Trace: <IRQ> tcp_conn_request (./include/linux/refcount.h:400 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 ./include/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301) tcp_rcv_state_process (net/ipv4/tcp_input.c
/net/sock.h:1965 ./include/net/request_sock.h:131 net/ipv4/tcp_input.c:7301) tcp_rcv_state_process (net/ipv4/tcp_input.c:6708) tcp_v6_do_rcv (net/ipv6/tcp_ipv6.c:1670) tcp_v6_rcv (net/ipv6/tcp_ipv6.c:1906) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:438) ip6_input (net/ipv6/ip6_input.c:500) ipv6_rcv (net/ipv6/ip6_input.c:311) __netif_receive_skb (net/core/dev.c:6104) process_backlog (net/core/dev.c:6456) __napi_poll (net/core/dev.c:7506) net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480) </IRQ> References: - https://git.kernel.org/stable/c/e359b742eac1eac75cff4e38ee2e8cea492acd9b - https://git.kernel.org/stable/
References: - https://git.kernel.org/stable/c/e359b742eac1eac75cff4e38ee2e8cea492acd9b - https://git.kernel.org/stable/c/ff6a8883f96a5bc74241ce5b3d431a6dcfa2124d - https://git.kernel.org/stable/c/eb85ad5f23268d64b037bfb545cbcba3752f90c7 - https://git.kernel.org/stable/c/643a94b0cf767325e953591c212be2eb826b9d7f - https://git.kernel.org/stable/c/422c1c173c39bbbae1e0eaaf8aefe40b2596233b - https://git.kernel.org/stable/c/c11ace909e873118295e9eb22dc8c58b0b50eb32 - https://git.kernel.org/stable/c/64dc47a13aa3d9daf7cec29b44dca8e22a6aea15 - https://git.kernel.org/stable/c/2e7cbbbe3d61c63606994b7ff73c72537afe2e1c
CVE ID: CVE-2025-40187 State: PUBLISHED Published: 2025-11-12T21:56:29.504Z Last Updated: 2025-11-12T21:56:29.504Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce() If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0 and sctp_ulpevent_make_authkey() returns 0, then the variable ai_ev remains zero and the zero will be dereferenced in the sctp_ulpevent_free() function. References: - https://git.kernel.org/stable/c/1014b83778c8677f1d7a57c26dc728baa801ac62 - https://git.kernel.org/stable/c/7f702f85df0266ed7b5bab81ba50394c92f3c928 - https://git.ke
677f1d7a57c26dc728baa801ac62 - https://git.kernel.org/stable/c/7f702f85df0266ed7b5bab81ba50394c92f3c928 - https://git.kernel.org/stable/c/dbceedc0213e75bf3e9f9f9e2f66b10699d004fe - https://git.kernel.org/stable/c/025419f4e216a3ae0d0cec622262e98e8078c447 - https://git.kernel.org/stable/c/c21f45cfa4a9526b34d76b397c9ef080668b6e73 - https://git.kernel.org/stable/c/d0e8f1445c19b1786759ba72a38267e1449bab7e - https://git.kernel.org/stable/c/badbd79313e6591616c1b78e29a9b71efed7f035 - https://git.kernel.org/stable/c/2f3119686ef50319490ccaec81a575973da98815
CVE ID: CVE-2025-40188 State: PUBLISHED Published: 2025-11-12T21:56:30.108Z Last Updated: 2025-11-12T21:56:30.108Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pwm: berlin: Fix wrong register in suspend/resume The 'enable' register should be BERLIN_PWM_EN rather than BERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, there will be cpu exception then kernel panic during suspend/resume. References: - https://git.kernel.org/stable/c/da3cadb8b0f35d845b3e2fbb7d978cf6473fd221 - https://git.kernel.org/stable/c/5419c86ea134b8a5b8126f55fa5bc1ad7b3ca444 - https://git.kernel.org/stable/c/9ee5eb3d09217f115f63b7c102d110ccdb1
/stable/c/5419c86ea134b8a5b8126f55fa5bc1ad7b3ca444 - https://git.kernel.org/stable/c/9ee5eb3d09217f115f63b7c102d110ccdb1b26af - https://git.kernel.org/stable/c/fd017aabd4273216ed4223f17991fc087163771f - https://git.kernel.org/stable/c/dc3a1c6237e7f8046e6d4109bcf1998452ccafad - https://git.kernel.org/stable/c/d9457e6258750692c3b27f80880a613178053c25 - https://git.kernel.org/stable/c/6cef9e4425143b19742044c8a675335821fa1994 - https://git.kernel.org/stable/c/3a4b9d027e4061766f618292df91760ea64a1fcc
CVE ID: CVE-2025-40189 State: PUBLISHED Published: 2025-11-12T21:56:30.575Z Last Updated: 2025-11-12T21:56:30.575Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: Fix lost EEPROM read timeout error(-ETIMEDOUT) in lan78xx_read_raw_eeprom Syzbot reported read of uninitialized variable BUG with following call stack. lan78xx 8-1:1.0 (unnamed net_device) (uninitialized): EEPROM read operation timeout ===================================================== BUG: KMSAN: uninit-value in lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline] BUG: KMSAN: uninit-value in lan78xx_init_mac_address drivers/net/usb/lan78xx
rom drivers/net/usb/lan78xx.c:1095 [inline] BUG: KMSAN: uninit-value in lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline] BUG: KMSAN: uninit-value in lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241 lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1095 [inline] lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline] lan78xx_reset+0x999/0x2cd0 drivers/net/usb/lan78xx.c:3241 lan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766 lan78xx_probe+0x225c/0x3310 drivers/net/usb/lan78xx.c:4707 Local variable sig.i.i created at: lan78xx_read_eeprom drivers/net/usb/lan78xx.c:1092 [inline] lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline] lan78xx_reset+0x77
vers/net/usb/lan78xx.c:1092 [inline] lan78xx_init_mac_address drivers/net/usb/lan78xx.c:1937 [inline] lan78xx_reset+0x77e/0x2cd0 drivers/net/usb/lan78xx.c:3241 lan78xx_bind+0x711/0x1690 drivers/net/usb/lan78xx.c:3766 The function lan78xx_read_raw_eeprom failed to properly propagate EEPROM read timeout errors (-ETIMEDOUT). In the fallthrough path, it first attempted to restore the pin configuration for LED outputs and then returned only the status of that restore operation, discarding the original timeout error. As a result, callers could mistakenly treat the data buffer as valid even though the EEPROM read had actually timed out with no data or partial data. To fix this, handle errors in res
valid even though the EEPROM read had actually timed out with no data or partial data. To fix this, handle errors in restoring the LED pin configuration separately. If the restore succeeds, return any prior EEPROM timeout error correctly to the caller. References: - https://git.kernel.org/stable/c/a72a7c4f675080a324d4c2167bd2314d968279f1 - https://git.kernel.org/stable/c/49bdb63ff64469a6de8ea901aef123c75be9bbe7
CVE ID: CVE-2025-40190 State: PUBLISHED Published: 2025-11-12T21:56:30.914Z Last Updated: 2025-11-12T21:56:30.914Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: guard against EA inode refcount underflow in xattr update syzkaller found a path where ext4_xattr_inode_update_ref() reads an EA inode refcount that is already <= 0 and then applies ref_change (often -1). That lets the refcount underflow and we proceed with a bogus value, triggering errors like: EXT4-fs error: EA inode <n> ref underflow: ref_count=-1 ref_change=-1 EXT4-fs warning: ea_inode dec ref err=-117 Make the invariant explicit: if the current refcount is n
nt=-1 ref_change=-1 EXT4-fs warning: ea_inode dec ref err=-117 Make the invariant explicit: if the current refcount is non-positive, treat this as on-disk corruption, emit ext4_error_inode(), and fail the operation with -EFSCORRUPTED instead of updating the refcount. Delete the WARN_ONCE() as negative refcounts are now impossible; keep error reporting in ext4_error_inode(). This prevents the underflow and the follow-on orphan/cleanup churn. References: - https://git.kernel.org/stable/c/ea39e712c2f5ae148ee5515798ae03523673e002 - https://git.kernel.org/stable/c/1cfb3e4ddbdc8e02e637b8852540bd4718bf4814 - https://git.kernel.org/stable/c/505e69f76ac497e788f4ea0267826ec7266b40c8 - https://git.kern
02e637b8852540bd4718bf4814 - https://git.kernel.org/stable/c/505e69f76ac497e788f4ea0267826ec7266b40c8 - https://git.kernel.org/stable/c/3d6269028246f4484bfed403c947a114bb583631 - https://git.kernel.org/stable/c/79ea7f3e11effe1bd9e753172981d9029133a278 - https://git.kernel.org/stable/c/6b879c4c6bbaab03c0ad2a983953bd1410bb165e - https://git.kernel.org/stable/c/440b003f449a4ff2a00b08c8eab9ba5cd28f3943 - https://git.kernel.org/stable/c/57295e835408d8d425bef58da5253465db3d6888
CVE ID: CVE-2025-40191 State: PUBLISHED Published: 2025-11-12T21:56:31.206Z Last Updated: 2025-11-12T21:56:31.206Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix kfd process ref leaking when userptr unmapping kfd_lookup_process_by_pid hold the kfd process reference to ensure it doesn't get destroyed while sending the segfault event to user space. Calling kfd_lookup_process_by_pid as function parameter leaks the kfd process refcount and miss the NULL pointer check if app process is already destroyed. References: - https://git.kernel.org/stable/c/60f6112fc9b3ba0eae519f10702c0c13bab45742 - https://git.kernel.org/st
oyed. References: - https://git.kernel.org/stable/c/60f6112fc9b3ba0eae519f10702c0c13bab45742 - https://git.kernel.org/stable/c/58e6fc2fb94f0f409447e5d46cf6a417b6397fbc
CVE ID: CVE-2025-40192 State: PUBLISHED Published: 2025-11-12T21:56:31.476Z Last Updated: 2025-11-12T21:56:31.476Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Revert "ipmi: fix msg stack when IPMI is disconnected" This reverts commit c608966f3f9c2dca596967501d00753282b395fc. This patch has a subtle bug that can cause the IPMI driver to go into an infinite loop if the BMC misbehaves in a certain way. Apparently certain BMCs do misbehave this way because several reports have come in recently about this. References: - https://git.kernel.org/stable/c/f4aab940ae9eb3ba32e5332b35703673f00d7f37 - https://git.kernel.org/stable/c/b9cc
ences: - https://git.kernel.org/stable/c/f4aab940ae9eb3ba32e5332b35703673f00d7f37 - https://git.kernel.org/stable/c/b9cc7155e65f6feca51bfedd543b9bd300e2be2b - https://git.kernel.org/stable/c/8cf5c24533b8058910fcb83a25a9cf0306383780 - https://git.kernel.org/stable/c/5d09ee1bec870263f4ace439402ea840503b503b
CVE ID: CVE-2025-40193 State: PUBLISHED Published: 2025-11-12T21:56:31.751Z Last Updated: 2025-11-12T21:56:31.751Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xtensa: simdisk: add input size check in proc_write_simdisk A malicious user could pass an arbitrarily bad value to memdup_user_nul(), potentially causing kernel crash. This follows the same pattern as commit ee76746387f6 ("netdevsim: prevent bad user input in nsim_dev_health_break_write()") References: - https://git.kernel.org/stable/c/f40405ccfb87b71175f2d5d004c0b8a0aebcc2cf - https://git.kernel.org/stable/c/151bd88859474cdaccc1e4c8b21fbf72dbba2ab4 - https://git.kern
1175f2d5d004c0b8a0aebcc2cf - https://git.kernel.org/stable/c/151bd88859474cdaccc1e4c8b21fbf72dbba2ab4 - https://git.kernel.org/stable/c/d381de7fd4cdc928ede96987dc64b133e6480dd6 - https://git.kernel.org/stable/c/a0c2c36d864ef3676b05cfd8c58b72ee3214cb1a - https://git.kernel.org/stable/c/5d5f08fd0cd970184376bee07d59f635c8403f63
CVE ID: CVE-2025-40194 State: PUBLISHED Published: 2025-11-12T21:56:32.025Z Last Updated: 2025-11-12T21:56:32.025Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request() The cpufreq_cpu_put() call in update_qos_request() takes place too early because the latter subsequently calls freq_qos_update_request() that indirectly accesses the policy object in question through the QoS request object passed to it. Fortunately, update_qos_request() is called under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it the
d under intel_pstate_driver_lock, so this issue does not matter for changing the intel_pstate operation mode, but it theoretically can cause a crash to occur on CPU device hot removal (which currently can only happen in virt, but it is formally supported nevertheless). Address this issue by modifying update_qos_request() to drop the reference to the policy later. References: - https://git.kernel.org/stable/c/15ac9579ebdaf22a37d7f60b3a8efc1029732ef9 - https://git.kernel.org/stable/c/bc26564bcc659beb6d977cd6eb394041ec2f2851 - https://git.kernel.org/stable/c/ad4e8f9bdbef11a19b7cb93e7f313bf59bdcc3b4 - https://git.kernel.org/stable/c/0a58d3e77b22b087a57831c87cafd360e144a5bd - https://git.kernel.o
7cb93e7f313bf59bdcc3b4 - https://git.kernel.org/stable/c/0a58d3e77b22b087a57831c87cafd360e144a5bd - https://git.kernel.org/stable/c/69a18ff6c60e8e113420f15355fad862cb45d38e - https://git.kernel.org/stable/c/ba63d4e9857a72a89e71a4eff9f2cc8c283e94c3 - https://git.kernel.org/stable/c/57e4a6aadf12578b96a038373cffd54b3a58b092 - https://git.kernel.org/stable/c/69e5d50fcf4093fb3f9f41c4f931f12c2ca8c467
CVE ID: CVE-2025-40195 State: PUBLISHED Published: 2025-11-12T21:56:32.311Z Last Updated: 2025-11-12T21:56:32.311Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mount: handle NULL values in mnt_ns_release() When calling in listmount() mnt_ns_release() may be passed a NULL pointer. Handle that case gracefully. References: - https://git.kernel.org/stable/c/2d68f8a7379d9c61005e982600c61948d4d019bd - https://git.kernel.org/stable/c/99ae3e70a293834d0274c46a37120c71a24a4995 - https://git.kernel.org/stable/c/6c7ca6a02f8f9549a438a08a23c6327580ecf3d6