Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
"no phy matching phyindex"); return ERR_PTR(-ENODEV); } In the notify path after a ->set operation however, there's no request attributes available. The typical callsite for the above function looks like: phydev = ethnl_req_get_phydev(req_base, tb[ETHTOOL_A_XXX_HEADER], info->extack); So, when tb is NULL (such as in the ethnl notify path), we have a nice crash. It turns out that there's only the PLCA command that is in that case, as the other phydev-specific commands don't have a notification. This commit fixes the crash by passing the cmd index and the nlattr array separately, allowing NULL-checking it directly inside the helper. References: - https://git.kernel.org/stable/c/639c7035295873
tely, allowing NULL-checking it directly inside the helper. References: - https://git.kernel.org/stable/c/639c70352958735addbba5ae7dd65985da96e061 - https://git.kernel.org/stable/c/1f458fa42c29144cef280e05bc49fc21b873d897 - https://git.kernel.org/stable/c/637399bf7e77797811adf340090b561a8f9d1213
CVE ID: CVE-2025-21922 State: PUBLISHED Published: 2025-04-01T15:40:55.711Z Last Updated: 2025-11-03T19:39:16.616Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ppp: Fix KMSAN uninit-value warning with bpf Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter. The following code can generate a PPP filter BPF program: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (00
dle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver. As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction. The issue is that only the first byte indicating direction is initialized in current ppp driver code w
ne the direction. The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized. For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN. [1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d68
ional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d685096c8129c9a92689975193e268945fd21dbf - https://git.kernel.org/stable/c/2f591cb158807bdcf424f66f1fbfa6e4e50f3757 - https://git.kernel.org/stable/c/4e2191b0fd0c064d37b0db67396216f2d4787e0f - https://git.kernel.org/stable/c/3de809a768464528762757e433cd50de35bcb3c1 - https://git.kernel.org/stable/c/1eacd47636a9de5bee25d9d5962dc538a82d9f0b - https://git.kernel.org/stable/c/8aa8a40c766b3945b40565a70349d5581458ff63 - https://git.kernel.org/stable/c/c036f5f2680cbdabdbbace86baee3c83721634d6 - https://git.kernel.org/stable/c/4c2d14c40a68678d885eab4008a0129646805bae
CVE ID: CVE-2025-21923 State: PUBLISHED Published: 2025-04-01T15:40:56.229Z Last Updated: 2025-05-04T07:24:39.239Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: hid-steam: Fix use-after-free when detaching device When a hid-steam device is removed it must clean up the client_hdev used for intercepting hidraw access. This can lead to scheduling deferred work to reattach the input device. Though the cleanup cancels the deferred work, this was done before the client_hdev itself is cleaned up, so it gets rescheduled. This patch fixes the ordering to make sure the deferred work is properly canceled. Additional Analyst Notes: -
cheduled. This patch fixes the ordering to make sure the deferred work is properly canceled. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/026714ec7546de741826324a6a1914c91024d06c - https://git.kernel.org/stable/c/a899adf7063c6745aaff1ec869f3c7f6329ed0a1 - https://git.kernel.org/stable/c/ea3f18d2f02629653b7bfe42607737ccd1343e54 - https://git.kernel.org/stable/c/e53fc232a65f7488ab75d03a5b95f06aaada7262
CVE ID: CVE-2025-21924 State: PUBLISHED Published: 2025-04-01T15:40:56.841Z Last Updated: 2025-11-03T19:39:17.991Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: hns3: make sure ptp clock is unregister and freed if hclge_ptp_get_cycle returns an error During the initialization of ptp, hclge_ptp_get_cycle might return an error and returned directly without unregister clock and free it. To avoid that, call hclge_ptp_destroy_clock to unregist and free clock if hclge_ptp_get_cycle failed. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b7d8d4529984e2d4a72a6d552fb886233e8e83cb -
otes: - CVE Program Container: References: - https://git.kernel.org/stable/c/b7d8d4529984e2d4a72a6d552fb886233e8e83cb - https://git.kernel.org/stable/c/33244e98aa9503585e585335fe2ceb4492630949 - https://git.kernel.org/stable/c/2c04e507f3a5c5dc6e2b9ab37d8cdedee1ef1a37 - https://git.kernel.org/stable/c/9cfc43c0e6e6a31122b4008d763a2960c206aa2d - https://git.kernel.org/stable/c/21dba813d9821687a7f9aff576798ba21a859a32 - https://git.kernel.org/stable/c/b7365eab39831487a84e63a9638209b68dc54008
CVE ID: CVE-2025-21925 State: PUBLISHED Published: 2025-04-01T15:40:57.355Z Last Updated: 2025-11-03T19:39:20.756Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: llc: do not use skb_get() before dev_queue_xmit() syzbot is able to crash hosts [1], using llc and devices not supporting IFF_TX_SKB_SHARING. In this case, e1000 driver calls eth_skb_pad(), while the skb is shared. Simply replace skb_get() by skb_clone() in net/llc/llc_s_ac.c Note that e1000 driver might have an issue with pktgen, because it does not clear IFF_TX_SKB_SHARING, this is an orthogonal change. We need to audit other skb_get() uses in net/llc. [1] kernel BUG
clear IFF_TX_SKB_SHARING, this is an orthogonal change. We need to audit other skb_get() uses in net/llc. [1] kernel BUG at net/core/skbuff.c:2178 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178 Call Trace: <TASK> __skb_pad+0x18a/0x610 net/core/skbuff.c:2466 __skb_put_padto include/linux/skbuff.h:3843 [inline] skb_put_padto include/linux/skbuff.h:3862 [inline] eth_skb_pad include/linux/etherdevice.h:656 [inline] e1000_xmit_fra
] skb_put_padto include/linux/skbuff.h:3862 [inline] eth_skb_pad include/linux/etherdevice.h:656 [inline] e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3806 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:4045 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621 dev_queue_xmit include/linux/netdevice.h:3313 [inline] llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144 llc_exec_sap_trans_actions net/llc/ll
vice.h:3313 [inline] llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209 llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993 sock_sendmsg_nosec net/socket.c:718 [inline] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/cd1c44327bbbd50fc24f2b38892f5f328b784d0f - https://git.kernel.org/stable/c/13f3f872627f0f27c31245524fc11367756240ad - https://git.kernel.org/stable/c/9b6f083db141ece0024be01526aa05aa978811cb - https://git.kernel.org/stable/c/17f86e25431ebc15aa9245ff156414fdad478
table/c/9b6f083db141ece0024be01526aa05aa978811cb - https://git.kernel.org/stable/c/17f86e25431ebc15aa9245ff156414fdad47822d - https://git.kernel.org/stable/c/416e8b4c20c6398044e93008deefd563289f477d - https://git.kernel.org/stable/c/0f764208dc24ea043c3e20194d32aebf94f8459c - https://git.kernel.org/stable/c/056e8a46d79e22983bae4267e0d9c52927076f46 - https://git.kernel.org/stable/c/64e6a754d33d31aa844b3ee66fb93ac84ca1565e
CVE ID: CVE-2025-21926 State: PUBLISHED Published: 2025-04-01T15:40:57.882Z Last Updated: 2025-11-03T19:39:23.706Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: gso: fix ownership in __udp_gso_segment In __udp_gso_segment the skb destructor is removed before segmenting the skb but the socket reference is kept as-is. This is an issue if the original skb is later orphaned as we can hit the following bug: kernel BUG at ./include/linux/skbuff.h:3312! (skb_orphan) RIP: 0010:ip_rcv_core+0x8b2/0xca0 Call Trace: ip_rcv+0xab/0x6e0 __netif_receive_skb_one_core+0x168/0x1b0 process_backlog+0x384/0x1100 __napi_poll.constprop.0+0xa1/0x
ip_rcv+0xab/0x6e0 __netif_receive_skb_one_core+0x168/0x1b0 process_backlog+0x384/0x1100 __napi_poll.constprop.0+0xa1/0x370 net_rx_action+0x925/0xe50 The above can happen following a sequence of events when using OpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes an OVS_ACTION_ATTR_OUTPUT action: 1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb goes through queue_gso_packets and then __udp_gso_segment, where its destructor is removed. 2. The segments' data are copied and sent to userspace. 3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the same original skb is sent to its path. 4. If it later hits skb_orphan, we hit the bug. Fix this by a
te_actions) and the same original skb is sent to its path. 4. If it later hits skb_orphan, we hit the bug. Fix this by also removing the reference to the socket in __udp_gso_segment. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9f28205ddb76e86cac418332e952241d85fed0dc - https://git.kernel.org/stable/c/a2d1cca955ed34873e524cc2e6e885450d262f05 - https://git.kernel.org/stable/c/455217ac9db0cf9349b3933664355e907bb1a569 - https://git.kernel.org/stable/c/e8db70537878e1bb3fd83e5abcc6feefc0587828 - https://git.kernel.org/stable/c/01a83237644d6822bc7df2c5564fc81b0df84358 - https://git.kernel.org/stable/c/084819b0d8b1bd433b90142371eb9450d657f8ca - ht
01a83237644d6822bc7df2c5564fc81b0df84358 - https://git.kernel.org/stable/c/084819b0d8b1bd433b90142371eb9450d657f8ca - https://git.kernel.org/stable/c/c32da44cc9298eaa6109e3fc2c2b4e07cc4bf11b - https://git.kernel.org/stable/c/ee01b2f2d7d0010787c2343463965bbc283a497f
CVE ID: CVE-2025-21927 State: PUBLISHED Published: 2025-04-01T15:40:58.432Z Last Updated: 2025-10-01T19:26:33.723Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu() nvme_tcp_recv_pdu() doesn't check the validity of the header length. When header digests are enabled, a target might send a packet with an invalid header length (e.g. 255), causing nvme_tcp_verify_hdgst() to access memory outside the allocated area and cause memory corruptions by overwriting it with the calculated digest. Fix this by rejecting packets with an unexpected header length. Additional Analyst N
ting it with the calculated digest. Fix this by rejecting packets with an unexpected header length. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/9fbc953d6b38bc824392e01850f0aeee3b348722 - https://git.kernel.org/stable/c/22b06c89aa6b2d1ecb8aea72edfb9d53af8d5126 - https://git.kernel.org/stable/c/ad95bab0cd28ed77c2c0d0b6e76e03e031391064
CVE ID: CVE-2025-21928 State: PUBLISHED Published: 2025-04-01T15:40:59.033Z Last Updated: 2025-11-03T19:39:26.507Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove() The system can experience a random crash a few minutes after the driver is removed. This issue occurs due to improper handling of memory freeing in the ishtp_hid_remove() function. The function currently frees the `driver_data` directly within the loop that destroys the HID devices, which can lead to accessing freed memory. Specifically, `hid_destroy_device()` uses `driver_data` when it calls `hid_ishtp
ich can lead to accessing freed memory. Specifically, `hid_destroy_device()` uses `driver_data` when it calls `hid_ishtp_set_feature()` to power off the sensor, so freeing `driver_data` beforehand can result in accessing invalid memory. This patch resolves the issue by storing the `driver_data` in a temporary variable before calling `hid_destroy_device()`, and then freeing the `driver_data` after the device is destroyed. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/0c1fb475ef999d6c22fc3f963fdf20cb3ed1b03d - https://git.kernel.org/stable/c/d3faae7f42181865c799d88c5054176f38ae4625 - https://git.kernel.org/stable/c/01b
ed1b03d - https://git.kernel.org/stable/c/d3faae7f42181865c799d88c5054176f38ae4625 - https://git.kernel.org/stable/c/01b18a330cda61cc21423a7d1af92cf31ded8f60 - https://git.kernel.org/stable/c/cf1a6015d2f6b1f0afaa0fd6a0124ff2c7943394 - https://git.kernel.org/stable/c/560f4d1299342504a6ab8a47f575b5e6b8345ada - https://git.kernel.org/stable/c/dea6a349bcaf243fff95dfd0428a26be6a0fb44e - https://git.kernel.org/stable/c/eb0695d87a81e7c1f0509b7d8ee7c65fbc26aec9 - https://git.kernel.org/stable/c/07583a0010696a17fb0942e0b499a62785c5fc9f
CVE ID: CVE-2025-21929 State: PUBLISHED Published: 2025-04-01T15:40:59.761Z Last Updated: 2025-05-04T07:24:47.101Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix use-after-free issue in hid_ishtp_cl_remove() During the `rmmod` operation for the `intel_ishtp_hid` driver, a use-after-free issue can occur in the hid_ishtp_cl_remove() function. The function hid_ishtp_cl_deinit() is called before ishtp_hid_remove(), which can lead to accessing freed memory or resources during the removal process. Call Trace: ? ishtp_cl_send+0x168/0x220 [intel_ishtp] ? hid_output_report+0xe3/0x150 [hid] hid_ishtp_set_feature+0
cess. Call Trace: ? ishtp_cl_send+0x168/0x220 [intel_ishtp] ? hid_output_report+0xe3/0x150 [hid] hid_ishtp_set_feature+0xb5/0x120 [intel_ishtp_hid] ishtp_hid_request+0x7b/0xb0 [intel_ishtp_hid] hid_hw_request+0x1f/0x40 [hid] sensor_hub_set_feature+0x11f/0x190 [hid_sensor_hub] _hid_sensor_power_state+0x147/0x1e0 [hid_sensor_trigger] hid_sensor_runtime_resume+0x22/0x30 [hid_sensor_trigger] sensor_hub_remove+0xa8/0xe0 [hid_sensor_hub] hid_device_remove+0x49/0xb0 [hid] hid_destroy_device+0x6f/0x90 [hid] ishtp_hid_remove+0x42/0x70 [intel_ishtp_hid] hid_ishtp_cl_remove+0x6b/0xb0 [intel_ishtp_hid] ishtp_cl_device_remove+0x4a/0x60 [intel_ishtp] ... Additionally, ishtp_hid_remove() is a HID level pow
[intel_ishtp_hid] ishtp_cl_device_remove+0x4a/0x60 [intel_ishtp] ... Additionally, ishtp_hid_remove() is a HID level power off, which should occur before the ISHTP level disconnect. This patch resolves the issue by reordering the calls in hid_ishtp_cl_remove(). The function ishtp_hid_remove() is now called before hid_ishtp_cl_deinit(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/9c677fe859a73f5dd3dd84c27f99e10d28047c73 - https://git.kernel.org/stable/c/e040f11fbca868c6d151e9f2c5730c476abfcf17 - https://git.kernel.org/stable/c/823987841424289339fdb4ba90e6d2c3792836db
CVE ID: CVE-2025-21930 State: PUBLISHED Published: 2025-04-01T15:41:00.316Z Last Updated: 2025-10-01T19:26:33.582Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't try to talk to a dead firmware This fixes: bad state = 0 WARNING: CPU: 10 PID: 702 at drivers/net/wireless/inel/iwlwifi/iwl-trans.c:178 iwl_trans_send_cmd+0xba/0xe0 [iwlwifi] Call Trace: <TASK> ? __warn+0xca/0x1c0 ? iwl_trans_send_cmd+0xba/0xe0 [iwlwifi 64fa9ad799a0e0d2ba53d4af93a53ad9a531f8d4] iwl_fw_dbg_clear_monitor_buf+0xd7/0x110 [iwlwifi 64fa9ad799a0e0d2ba53d4af93a53ad9a531f8d4] _iwl_dbgfs_fw_dbg_clear_write+0xe2/0x120 [iwlmvm 0e8adb18cea
d7/0x110 [iwlwifi 64fa9ad799a0e0d2ba53d4af93a53ad9a531f8d4] _iwl_dbgfs_fw_dbg_clear_write+0xe2/0x120 [iwlmvm 0e8adb18cea92d2c341766bcc10b18699290068a] Ask whether the firmware is alive before sending a command. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/437e93ecd40754f9e938d524daf52a10c589e2d4 - https://git.kernel.org/stable/c/e7c31a3f4f27d61b9ccd894a7bf4690f137da0ec - https://git.kernel.org/stable/c/d73d2c6e3313f0ba60711ab4f4b9044eddca9ca5
CVE ID: CVE-2025-21931 State: PUBLISHED Published: 2025-04-01T15:41:01.055Z Last Updated: 2025-11-03T19:39:27.919Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio Commit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined) add page poison checks in do_migrate_range in order to make offline hwpoisoned page possible by introducing isolate_lru_page and try_to_unmap for hwpoisoned page. However folio lock must be held before calling try_to_unmap. Add it to fix this problem. Warning will be produced if folio is not locked during unmap: -----
re calling try_to_unmap. Add it to fix this problem. Warning will be produced if folio is not locked during unmap: ------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0
Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (
28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/3926b572fd073491bde13ec42ee08ac1b337bf4d - https://git.kernel.org/stable/c/93df6da64b004f75d307ed08d3f0f1020280d339 - https://git.kernel.org/stable/c/576a2f4c437c19bec7d05d05b5990f178d2b0f40 - https://git.kernel.org/stable/c/629dfc6ba5431056701d4e44830f3409b989955a - https://git.kernel.org/stable/c/af288a426c3e3552b62595c6138ec6371a17dbba
CVE ID: CVE-2025-21932 State: PUBLISHED Published: 2025-04-01T15:41:01.792Z Last Updated: 2025-05-04T07:24:51.264Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: abort vma_modify() on merge out of memory failure The remainder of vma_modify() relies upon the vmg state remaining pristine after a merge attempt. Usually this is the case, however in the one edge case scenario of a merge attempt failing not due to the specified range being unmergeable, but rather due to an out of memory error arising when attempting to commit the merge, this assumption becomes untrue. This results in vmg->start, end being modified, and thus the p
ting to commit the merge, this assumption becomes untrue. This results in vmg->start, end being modified, and thus the proceeding attempts to split the VMA will be done with invalid start/end values. Thankfully, it is likely practically impossible for us to hit this in reality, as it would require a maple tree node pre-allocation failure that would likely never happen due to it being 'too small to fail', i.e. the kernel would simply keep retrying reclaim until it succeeded. However, this scenario remains theoretically possible, and what we are doing here is wrong so we must correct it. The safest option is, when this scenario occurs, to simply give up the operation. If we cannot allocate mem
correct it. The safest option is, when this scenario occurs, to simply give up the operation. If we cannot allocate memory to merge, then we cannot allocate memory to split either (perhaps moreso!). Any scenario where this would be happening would be under very extreme (likely fatal) memory pressure, so it's best we give up early. So there is no doubt it is appropriate to simply bail out in this scenario. However, in general we must if at all possible never assume VMG state is stable after a merge attempt, since merge operations update VMG fields. As a result, additionally also make this clear by storing start, end in local variables. The issue was reported originally by syzkaller, and by B
also make this clear by storing start, end in local variables. The issue was reported originally by syzkaller, and by Brad Spengler (via an off-list discussion), and in both instances it manifested as a triggering of the assert: VM_WARN_ON_VMG(start >= end, vmg); In vma_merge_existing_range(). It seems at least one scenario in which this is occurring is one in which the merge being attempted is due to an madvise() across multiple VMAs which looks like this: start end |<------>| |----------|------| | vma | next | |----------|------| When madvise_walk_vmas() is invoked, we first find vma in the above (determining prev to be equal to vma as we are offset into vma), and then enter the loop. We
irst find vma in the above (determining prev to be equal to vma as we are offset into vma), and then enter the loop. We determine the end of vma that forms part of the range we are madvise()'ing by setting 'tmp' to this value: /* Here vma->vm_start <= start < (end|vma->vm_end) */ tmp = vma->vm_end; We then invoke the madvise() operation via visit(), letting prev get updated to point to vma as part of the operation: /* Here vma->vm_start <= start < tmp <= (end|vma->vm_end). */ error = visit(vma, &prev, start, tmp, arg); Where the visit() function pointer in this instance is madvise_vma_behavior(). As observed in syzkaller reports, it is ultimately madvise_update_vma() that is invoked, calling