Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
alth_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663 Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return. References: - https://git.kernel.org/stable/c/25672c620421fa2105703a94a29a03487245e6d6 - https://git.kernel.org/stable/c/e0e24571a7b2f8c8f06e25d34
kernel.org/stable/c/25672c620421fa2105703a94a29a03487245e6d6 - https://git.kernel.org/stable/c/e0e24571a7b2f8c8f06e25d3417253ebbdbc8d5c - https://git.kernel.org/stable/c/8141910869596b7a3a5d9b46107da2191d523f82 - https://git.kernel.org/stable/c/ea53e6a47e148b490b1c652fc65d2de5a086df76 - https://git.kernel.org/stable/c/660b2a8f5a306a28c7efc1b4990ecc4912a68f87 - https://git.kernel.org/stable/c/70affe82e38fd3dc76b9c68b5a1989f11e7fa0f3 - https://git.kernel.org/stable/c/56c0a2a9ddc2f5b5078c5fb0f81ab76bbc3d4c37
CVE ID: CVE-2025-39950 State: PUBLISHED Published: 2025-10-04T07:31:10.926Z Last Updated: 2025-10-04T07:31:10.926Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIR A NULL pointer dereference can occur in tcp_ao_finish_connect() during a connect() system call on a socket with a TCP-AO key added and TCP_REPAIR enabled. The function is called with skb being NULL and attempts to dereference it on tcp_hdr(skb)->seq without a prior skb validation. Fix this by checking if skb is NULL before dereferencing it. The commentary is taken from bpf_skops_established(), wh
n. Fix this by checking if skb is NULL before dereferencing it. The commentary is taken from bpf_skops_established(), which is also called in the same flow. Unlike the function being patched, bpf_skops_established() validates the skb before dereferencing it. int main(void){ struct sockaddr_in sockaddr; struct tcp_ao_add tcp_ao; int sk; int one = 1; memset(&sockaddr,'\0',sizeof(sockaddr)); memset(&tcp_ao,'\0',sizeof(tcp_ao)); sk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); sockaddr.sin_family = AF_INET; memcpy(tcp_ao.alg_name,"cmac(aes128)",12); memcpy(tcp_ao.key,"ABCDEFGHABCDEFGH",16); tcp_ao.keylen = 16; memcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr)); setsockopt(sk, IPPROTO_TCP, TCP_AO_ADD
CDEFGH",16); tcp_ao.keylen = 16; memcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr)); setsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tcp_ao, sizeof(tcp_ao)); setsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &one, sizeof(one)); sockaddr.sin_family = AF_INET; sockaddr.sin_port = htobe16(123); inet_aton("127.0.0.1", &sockaddr.sin_addr); connect(sk,(struct sockaddr *)&sockaddr,sizeof(sockaddr)); return 0; } $ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall $ unshare -Urn BUG: kernel NULL pointer dereference, address: 00000000000000b6 PGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/
00 [#1] SMP NOPTI Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182) References: - https://git.kernel.org/stable/c/5f445eb259906b61a518487a790e11d07d31738c - https://git.kernel.org/stable/c/993b734d31ab804747ac961b1ee664b023c3b5fa - https://git.kernel.org/stable/c/2e7bba08923ebc675b1f0e0e0959e68e53047838
CVE ID: CVE-2025-39951 State: PUBLISHED Published: 2025-10-04T07:31:11.684Z Last Updated: 2025-10-04T07:37:07.273Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: um: virtio_uml: Fix use-after-free after put_device in probe When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues. References: - https://git.kernel.org/stable/c/14c231959a16ca41bfdcaede72483362a8c645d7 - https://git.kernel.org/stable/c/5e94e44c9cb30d7a383d8ac227f24a8c9326b770 - https://git.kernel.org/stable/c/aaf900a83508c8c
tps://git.kernel.org/stable/c/5e94e44c9cb30d7a383d8ac227f24a8c9326b770 - https://git.kernel.org/stable/c/aaf900a83508c8cd5cdf765e7749f9076196ec7f - https://git.kernel.org/stable/c/4f364023ddcfe83f7073b973a9cb98584b7f2a46 - https://git.kernel.org/stable/c/00e98b5a69034b251bb36dc6e7123d7648e218e4 - https://git.kernel.org/stable/c/c2ff91255e0157b356cff115d8dc3eeb5162edf2 - https://git.kernel.org/stable/c/7ebf70cf181651fe3f2e44e95e7e5073d594c9c0
CVE ID: CVE-2025-39952 State: PUBLISHED Published: 2025-10-04T07:31:12.445Z Last Updated: 2025-10-04T07:31:12.445Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: avoid buffer overflow in WID string configuration Fix the following copy overflow warning identified by Smatch checker. drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537) This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size lim
ffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field of 'struct wilc_cfg_str'. References: - https://git.kernel.org/stable/c/6085291a1a5865d4ad70f0e5812d524ebd5d1711 - https://git.kernel.org/stable/c/2203ef417044b10a8563ade6a17c74183745d72e - https://git.kernel.org/stable/c/ae50f8562306a7ea1cf3c9722f97ee244f974729 - https://git.kernel.org/stable/c/fe9e4d0c39311d0f97b024147a0d155333f388b5
CVE ID: CVE-2025-39953 State: PUBLISHED Published: 2025-10-04T07:31:13.237Z Last Updated: 2025-10-04T07:37:08.557Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cgroup: split cgroup_destroy_wq into 3 workqueues A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction. Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio Call Trace: cgroup_lock_and_drain_offline+0
ion.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio Call Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20 Root Cause: CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues // cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cg
cuted first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1) Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_fr
ed workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation This separation eliminates blocking in the CSS free path while waiting for offline operations to complete. [1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers References: - https://git.kernel.org/stable/c/cabadd7fd15f97090f752fd22dd7f876a0dc3dc4 - https://git.kernel.org/stable/c/a0c896bda7077aa5005473e2c5b3c27173313b4c - https://git.kernel.org/stable/c/f2795d1b92506e3adf52a298f7181032a1525e04 - https://git.kernel.org/stable/c/993049c9b1355c78918344a6403427d53f9ee700 - https://git.kernel.org/stable/c/4a1e3e
5e04 - https://git.kernel.org/stable/c/993049c9b1355c78918344a6403427d53f9ee700 - https://git.kernel.org/stable/c/4a1e3ec28e8062cd9f339aa6a942df9c5bcb6811 - https://git.kernel.org/stable/c/ded4d207a3209a834b6831ceec7f39b934c74802 - https://git.kernel.org/stable/c/05e0b03447cf215ec384210441b34b7a3b16e8b0 - https://git.kernel.org/stable/c/79f919a89c9d06816dbdbbd168fa41d27411a7f9
CVE ID: CVE-2025-39954 State: PUBLISHED Published: 2025-10-09T09:47:32.825Z Last Updated: 2025-10-09T09:47:32.825Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: sunxi-ng: mp: Fix dual-divider clock rate readback When dual-divider clock support was introduced, the P divider offset was left out of the .recalc_rate readback function. This causes the clock rate to become bogus or even zero (possibly due to the P divider being 1, leading to a divide-by-zero). Fix this by incorporating the P divider offset into the calculation. References: - https://git.kernel.org/stable/c/40108f69c372af3aea73e7829d6849a44638d662 - https://git.
o the calculation. References: - https://git.kernel.org/stable/c/40108f69c372af3aea73e7829d6849a44638d662 - https://git.kernel.org/stable/c/25fbbaf515acd13399589bd5ee6de5f35740cef2
CVE ID: CVE-2025-39955 State: PUBLISHED Published: 2025-10-09T09:47:33.556Z Last Updated: 2025-10-09T09:47:33.556Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect(). syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk in the TCP_ESTABLISHED state. [0] syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destination As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes it to TCP_CLOSE and makes connect() possible, which rest
t(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes it to TCP_CLOSE and makes connect() possible, which restarts timers. Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the retransmit timer triggered the warning and the intended packet was not retransmitted. Let's call reqsk_fastopen_remove() in tcp_disconnect(). [0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcp_retransmit
) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff88810691148
00000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: <IRQ> tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_mig
e/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) </IRQ> References: - https://git.kernel.org/stable/c/7ec092a91ff351dcde89c23e795b73a32827
pic.c:1050 (discriminator 35)) </IRQ> References: - https://git.kernel.org/stable/c/7ec092a91ff351dcde89c23e795b73a328274db6 - https://git.kernel.org/stable/c/a4378dedd6e07e62f2fccb17d78c9665718763d0 - https://git.kernel.org/stable/c/33a4fdf0b4a25f8ce65380c3b0136b407ca57609 - https://git.kernel.org/stable/c/17d699727577814198d744d6afe54735c6b54c99 - https://git.kernel.org/stable/c/dfd06131107e7b699ef1e2a24ed2f7d17c917753 - https://git.kernel.org/stable/c/fa4749c065644af4db496b338452a69a3e5147d9 - https://git.kernel.org/stable/c/ae313d14b45eca7a6bb29cb9bf396d977e7d28fb - https://git.kernel.org/stable/c/45c8a6cc2bcd780e634a6ba8e46bffbdf1fc5c01
CVE ID: CVE-2025-39956 State: PUBLISHED Published: 2025-10-09T09:47:34.253Z Last Updated: 2025-10-09T09:47:34.253Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: igc: don't fail igc_probe() on LED setup error When igc_led_setup() fails, igc_probe() fails and triggers kernel panic in free_netdev() since unregister_netdev() is not called. [1] This behavior can be tested using fault-injection framework, especially the failslab feature. [2] Since LED support is not mandatory, treat LED setup failures as non-fatal and continue probe with a warning message, consequently avoiding the kernel panic. [1] kernel BUG at net/core/dev.c:1204
and continue probe with a warning message, consequently avoiding the kernel panic. [1] kernel BUG at net/core/dev.c:12047! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:free_netdev+0x278/0x2b0 [...] Call Trace: <TASK> igc_probe+0x370/0x910 local_pci_probe+0x3a/0x80 pci_device_probe+0xd1/0x200 [...] [2] #!/bin/bash -ex FAILSLAB_PATH=/sys/kernel/debug/failslab/ DEVICE=0000:00:05.0 START_ADDR=$(grep " igc_led_setup" /proc/kallsyms \ | awk '{printf("0x%s", $1)}') END_ADDR=$(print
/ DEVICE=0000:00:05.0 START_ADDR=$(grep " igc_led_setup" /proc/kallsyms \ | awk '{printf("0x%s", $1)}') END_ADDR=$(printf "0x%x" $((START_ADDR + 0x100))) echo $START_ADDR > $FAILSLAB_PATH/require-start echo $END_ADDR > $FAILSLAB_PATH/require-end echo 1 > $FAILSLAB_PATH/times echo 100 > $FAILSLAB_PATH/probability echo N > $FAILSLAB_PATH/ignore-gfp-wait echo $DEVICE > /sys/bus/pci/drivers/igc/bind References: - https://git.kernel.org/stable/c/bec504867acc7315de9cd96ef9161fa52a25abe8 - https://git.kernel.org/stable/c/f05e82d8553232cef150a6dbb70ed67d162abb2b - https://git.kernel.org/stable/c/528eb4e19ec0df30d0c9ae4074ce945667dde919
CVE ID: CVE-2025-39957 State: PUBLISHED Published: 2025-10-09T09:47:34.933Z Last Updated: 2025-10-09T09:47:34.933Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: increase scan_ies_len for S1G Currently the S1G capability element is not taken into account for the scan_ies_len, which leads to a buffer length validation failure in ieee80211_prep_hw_scan() and subsequent WARN in __ieee80211_start_scan(). This prevents hw scanning from functioning. To fix ensure we accommodate for the S1G capability length. References: - https://git.kernel.org/stable/c/16c9244a62116fe148f6961753b68e7160799f97 - https://git.kernel.org
length. References: - https://git.kernel.org/stable/c/16c9244a62116fe148f6961753b68e7160799f97 - https://git.kernel.org/stable/c/93e063f15e17acb8cd6ac90c8f0802c2624e1a74 - https://git.kernel.org/stable/c/32adb020b0c32939da1322dcc87fc0ae2bc935d1 - https://git.kernel.org/stable/c/0dbad5f5549e54ac269cc04ce89f212892a98cab - https://git.kernel.org/stable/c/7e2f3213e85eba00acb4cfe6d71647892d63c3a1
CVE ID: CVE-2025-39958 State: PUBLISHED Published: 2025-10-09T09:47:35.601Z Last Updated: 2025-10-09T09:47:35.601Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/s390: Make attach succeed when the device was surprise removed When a PCI device is removed with surprise hotplug, there may still be attempts to attach the device to the default domain as part of tear down via (__iommu_release_dma_ownership()), or because the removal happens during probe (__iommu_probe_device()). In both cases zpci_register_ioat() fails with a cc value indicating that the device handle is invalid. This is because the device is no longer part of
t() fails with a cc value indicating that the device handle is invalid. This is because the device is no longer part of the instance as far as the hypervisor is concerned. Currently this leads to an error return and s390_iommu_attach_device() fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail() because attaching to the default domain must never fail. With the device fenced by the hypervisor no DMAs to or from memory are possible and the IOMMU translations have no effect. Proceed as if the registration was successful and let the hotplug event handling clean up the device. This is similar to how devices in the error state are handled since commit 59bbf596791b ("iommu/s390: M
n up the device. This is similar to how devices in the error state are handled since commit 59bbf596791b ("iommu/s390: Make attach succeed even if the device is in error state") except that for removal the domain will not be registered later. This approach was also previously discussed at the link. Handle both cases, error state and removal, in a helper which checks if the error needs to be propagated or ignored. Avoid magic number condition codes by using the pre-existing, but never used, defines for PCI load/store condition codes and rename them to reflect that they apply to all PCI instructions. References: - https://git.kernel.org/stable/c/359613f2fa009587154511e4842e8ab9532edd15 - https
to all PCI instructions. References: - https://git.kernel.org/stable/c/359613f2fa009587154511e4842e8ab9532edd15 - https://git.kernel.org/stable/c/9ffaf5229055fcfbb3b3d6f1c7e58d63715c3f73
CVE ID: CVE-2025-39959 State: PUBLISHED Published: 2025-10-09T09:47:36.274Z Last Updated: 2025-10-09T09:47:36.274Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp: Fix incorrect retrival of acp_chip_info Use dev_get_drvdata(dev->parent) instead of dev_get_platdata(dev) to correctly obtain acp_chip_info members in the acp I2S driver. Previously, some members were not updated properly due to incorrect data access, which could potentially lead to null pointer dereferences. This issue was missed in the earlier commit ("ASoC: amd: acp: Fix NULL pointer deref in acp_i2s_set_tdm_slot"), which only addressed set_tdm_slot(
he earlier commit ("ASoC: amd: acp: Fix NULL pointer deref in acp_i2s_set_tdm_slot"), which only addressed set_tdm_slot(). This change ensures that all relevant functions correctly retrieve acp_chip_info, preventing further null pointer dereference issues. References: - https://git.kernel.org/stable/c/65c5cfbd6d938f77a0df3c34855a4f7d8a61fd10 - https://git.kernel.org/stable/c/d7871f400cad1da376f1d7724209a1c49226c456
CVE ID: CVE-2025-39960 State: PUBLISHED Published: 2025-10-09T12:13:21.327Z Last Updated: 2025-10-09T12:13:21.327Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gpiolib: acpi: initialize acpi_gpio_info struct Since commit 7c010d463372 ("gpiolib: acpi: Make sure we fill struct acpi_gpio_info"), uninitialized acpi_gpio_info struct are passed to __acpi_find_gpio() and later in the call stack info->quirks is used in acpi_populate_gpio_lookup. This breaks the i2c_hid_cpi driver: [ 58.122916] i2c_hid_acpi i2c-UNIW0001:00: HID over i2c has not been provided an Int IRQ [ 58.123097] i2c_hid_acpi i2c-UNIW0001:00: probe with driver i2c_h
001:00: HID over i2c has not been provided an Int IRQ [ 58.123097] i2c_hid_acpi i2c-UNIW0001:00: probe with driver i2c_hid_acpi failed with error -22 Fix this by initializing the acpi_gpio_info pass to __acpi_find_gpio() References: - https://git.kernel.org/stable/c/27d94a2a52cbb54927c0140bd5b978c56e9a283a - https://git.kernel.org/stable/c/19c839a98c731169f06d32e7c9e00c78a0086ebe
CVE ID: CVE-2025-39961 State: PUBLISHED Published: 2025-10-09T12:13:22.029Z Last Updated: 2025-10-09T12:13:22.029Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/amd/pgtbl: Fix possible race while increase page table level The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations. The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switche
fetch_pte() operations. The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level. But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON
ncoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON. CPU 0 CPU 1 ------ ------ map pages unmap pages alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1) Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path. References: - https://git.kernel.org/stable/c/075abf0b1a958acfbea2435003d228e738e90346 - https://git.kernel.org/stable/c/cd92c8ab336c3a633d46e6f35ebcd3509ae7db3b - https
abf0b1a958acfbea2435003d228e738e90346 - https://git.kernel.org/stable/c/cd92c8ab336c3a633d46e6f35ebcd3509ae7db3b - https://git.kernel.org/stable/c/7d462bdecb7d9c32934dab44aaeb7ea7d73a27a2 - https://git.kernel.org/stable/c/1e56310b40fd2e7e0b9493da9ff488af145bdd0c