Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2024-43888 State: PUBLISHED Published: 2024-08-26T10:10:40.890Z Last Updated: 2025-05-04T09:28:36.636Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: list_lru: fix UAF for memory cgroup The mem_cgroup_from_slab_obj() is supposed to be called under rcu lock or cgroup_mutex or others which could prevent returned memcg from being freed. Fix it by adding missing rcu read lock. Found by code inspection. [songmuchun@bytedance.com: only grab rcu lock when necessary, per Vlastimil] Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/4589f77c18dd98b65f45617b6d1e95313cf6fcab -
otes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/4589f77c18dd98b65f45617b6d1e95313cf6fcab - https://git.kernel.org/stable/c/5161b48712dcd08ec427c450399d4d1483e21dea
CVE ID: CVE-2024-43889 State: PUBLISHED Published: 2024-08-26T10:10:42.270Z Last Updated: 2025-11-03T22:06:45.325Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: padata: Fix possible divide-by-0 panic in padata_mt_helper() We are hit with a not easily reproducible divide-by-0 panic in padata.c at bootup time. [ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1 [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021 [ 10.017908] Workqueue: events_unbound padata_mt_helper [ 10.0179
12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021 [ 10.017908] Workqueue: events_unbound padata_mt_helper [ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0 : [ 10.017963] Call Trace: [ 10.017968] <TASK> [ 10.018004] ? padata_mt_helper+0x39/0xb0 [ 10.018084] process_one_work+0x174/0x330 [ 10.018093] worker_thread+0x266/0x3a0 [ 10.018111] kthread+0xcf/0x100 [ 10.018124] ret_from_fork+0x31/0x50 [ 10.018138] ret_from_fork_asm+0x1a/0x30 [ 10.018147] </TASK> Looking at the padata_mt_helper() function, the only way a divide-by-0 panic can happen is when ps->chunk_size is 0. The way that chunk_size is initialized in padata_do_multithreaded(), chunk_size can be 0 when the min_chunk in the passed
he way that chunk_size is initialized in padata_do_multithreaded(), chunk_size can be 0 when the min_chunk in the passed-in padata_mt_job structure is 0. Fix this divide-by-0 panic by making sure that chunk_size will be at least 1 no matter what the input parameters are. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ab8b397d5997d8c37610252528edc54bebf9f6d3 - https://git.kernel.org/stable/c/8f5ffd2af7274853ff91d6cd62541191d9fbd10d - https://git.kernel.org/stable/c/a29cfcb848c31f22b4de6a531c3e1d68c9bfe09f - https://git.kernel.org/stable/c/924f788c906dccaca30acab86c7124371e1d6f2c - https://git.kernel.org/stable/c/da0ffe
e09f - https://git.kernel.org/stable/c/924f788c906dccaca30acab86c7124371e1d6f2c - https://git.kernel.org/stable/c/da0ffe84fcc1627a7dff82c80b823b94236af905 - https://git.kernel.org/stable/c/6d45e1c948a8b7ed6ceddb14319af69424db730c
CVE ID: CVE-2024-43890 State: PUBLISHED Published: 2024-08-26T10:10:43.547Z Last Updated: 2025-11-03T22:06:48.215Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Fix overflow in get_free_elt() "tracing_map->next_elt" in get_free_elt() is at risk of overflowing. Once it overflows, new elements can still be inserted into the tracing_map even though the maximum number of elements (`max_elts`) has been reached. Continuing to insert elements after the overflow could result in the tracing_map containing "tracing_map->max_size" elements, leaving no empty entries. If any attempt is made to insert an element into a full tracing
acing_map->max_size" elements, leaving no empty entries. If any attempt is made to insert an element into a full tracing_map using `__tracing_map_insert()`, it will cause an infinite loop with preemption disabled, leading to a CPU hang problem. Fix this by preventing any further increments to "tracing_map->next_elt" once it reaches "tracing_map->max_elt". Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/302ceb625d7b990db205a15e371f9a71238de91c - https://git.kernel.org/stable/c/d3e4dbc2858fe85d1dbd2e72a9fc5dea988b5c18 - https://git.kernel.org/stable/c/eb223bf01e688dfe37e813c8988ee11c8c9f8d0a - https://git.kernel.org/stab
9fc5dea988b5c18 - https://git.kernel.org/stable/c/eb223bf01e688dfe37e813c8988ee11c8c9f8d0a - https://git.kernel.org/stable/c/cd10d186a5409a1fe6e976df82858e9773a698da - https://git.kernel.org/stable/c/788ea62499b3c18541fd6d621964d8fafbc4aec5 - https://git.kernel.org/stable/c/a172c7b22bc2feaf489cfc6d6865f7237134fdf8 - https://git.kernel.org/stable/c/236bb4690773ab6869b40bedc7bc8d889e36f9d6 - https://git.kernel.org/stable/c/bcf86c01ca4676316557dd482c8416ece8c2e143
CVE ID: CVE-2024-43891 State: PUBLISHED Published: 2024-08-26T10:10:44.790Z Last Updated: 2025-05-04T09:28:40.451Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Have format file honor EVENT_FILE_FL_FREED When eventfs was introduced, special care had to be done to coordinate the freeing of the file meta data with the files that are exposed to user space. The file meta data would have a ref count that is set when the file is created and would be decremented and freed after the last user that opened the file closed it. When the file meta data was to be freed, it would set a flag (EVENT_FILE_FL_FREED) to denote that the f
file closed it. When the file meta data was to be freed, it would set a flag (EVENT_FILE_FL_FREED) to denote that the file is freed, and any new references made (like new opens or reads) would fail as it is marked freed. This allowed other meta data to be freed after this flag was set (under the event_mutex). All the files that were dynamically created in the events directory had a pointer to the file meta data and would call event_release() when the last reference to the user space file was closed. This would be the time that it is safe to free the file meta data. A shortcut was made for the "format" file. It's i_private would point to the "call" entry directly and not point to the file's
cut was made for the "format" file. It's i_private would point to the "call" entry directly and not point to the file's meta data. This is because all format files are the same for the same "call", so it was thought there was no reason to differentiate them. The other files maintain state (like the "enable", "trigger", etc). But this meant if the file were to disappear, the "format" file would be unaware of it. This caused a race that could be trigger via the user_events test (that would create dynamic events and free them), and running a loop that would read the user_events format files: In one console run: # cd tools/testing/selftests/user_events # while true; do ./ftrace_test; done And in
s format files: In one console run: # cd tools/testing/selftests/user_events # while true; do ./ftrace_test; done And in another console run: # cd /sys/kernel/tracing/ # while true; do cat events/user_events/__test_event/format; done 2>/dev/null With KASAN memory checking, it would trigger a use-after-free bug report (which was a real bug). This was because the format file was not checking the file's meta data flag "EVENT_FILE_FL_FREED", so it would access the event that the file meta data pointed to after the event was freed. After inspection, there are other locations that were found to not check the EVENT_FILE_FL_FREED flag when accessing the trace_event_file. Add a new helper function: e
t were found to not check the EVENT_FILE_FL_FREED flag when accessing the trace_event_file. Add a new helper function: event_file_file() that will make sure that the event_mutex is held, and will return NULL if the trace_event_file has the EVENT_FILE_FL_FREED flag set. Have the first reference of the struct file pointer use event_file_file() and check for NULL. Later uses can still use the event_file_data() helper function if the event_mutex is still held and was not released since the event_file_file() call. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/4ed03758ddf0b19d69eed69386d65a92d0091e0c - https://git.kernel.org/stable/c/531dc6780d942
https://git.kernel.org/stable/c/4ed03758ddf0b19d69eed69386d65a92d0091e0c - https://git.kernel.org/stable/c/531dc6780d94245af037c25c2371c8caf652f0f9 - https://git.kernel.org/stable/c/b1560408692cd0ab0370cfbe9deb03ce97ab3f6d
CVE ID: CVE-2024-43892 State: PUBLISHED Published: 2024-08-26T10:10:46.612Z Last Updated: 2025-11-03T22:06:51.189Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: memcg: protect concurrent access to mem_cgroup_idr Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mu
he mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that obj
ike for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases. Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race betwe
reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/912736a0435ef40e6a4ae78197ccb5553cb80b05 - https://git.kernel.org/stable/c/e6cc9ff2ac0b5df9f25eb790934c3104f6710278 - https://git.kernel.org/stable/c/56fd70f4aa8b82199db
//git.kernel.org/stable/c/e6cc9ff2ac0b5df9f25eb790934c3104f6710278 - https://git.kernel.org/stable/c/56fd70f4aa8b82199dbe7e99366b1fd7a04d86fb - https://git.kernel.org/stable/c/37a060b64ae83b76600d187d76591ce488ab836b - https://git.kernel.org/stable/c/51c0b1bb7541f8893ec1accba59eb04361a70946 - https://git.kernel.org/stable/c/9972605a238339b85bd16b084eed5f18414d22db
CVE ID: CVE-2024-43893 State: PUBLISHED Published: 2024-08-26T10:10:48.046Z Last Updated: 2025-11-03T22:06:54.168Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: serial: core: check uartclk for zero to avoid divide by zero Calling ioctl TIOCSSERIAL with an invalid baud_base can result in uartclk being zero, which will result in a divide by zero error in uart_get_divisor(). The check for uartclk being zero in uart_set_info() needs to be done before other settings are made as subsequent calls to ioctl TIOCSSERIAL for the same port would be impacted if the uartclk check was done where uartclk gets set. Oops: divide error: 0000 PRE
L for the same port would be impacted if the uartclk check was done where uartclk gets set. Oops: divide error: 0000 PREEMPT SMP KASAN PTI RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580) Call Trace: <TASK> serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576 drivers/tty/serial/8250/8250_port.c:2589) serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502 drivers/tty/serial/8250/8250_port.c:2741) serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862) uart_change_line_settings (./include/linux/spinlock.h:376 ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222) uart_port_startup (drivers/tty/serial/serial_core.c:342) uart_st
serial_core.h:608 drivers/tty/serial/serial_core.c:222) uart_port_startup (drivers/tty/serial/serial_core.c:342) uart_startup (drivers/tty/serial/serial_core.c:368) uart_set_info (drivers/tty/serial/serial_core.c:1034) uart_set_info_user (drivers/tty/serial/serial_core.c:1059) tty_set_serial (drivers/tty/tty_io.c:2637) tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791) __x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Rule: add Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Pr
L_64_after_hwframe (arch/x86/entry/entry_64.S:130) Rule: add Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3bbd90fca824e6fd61fb20f6dd2b0fa5f8b14bba - https://git.kernel.org/stable/c/55b2a5d331a6ceb1c4372945fdb77181265ba24f - https://git.kernel.org/stable/c/52b138f1021113e593ee6ad258ce08fe90693a9e - https://git.kernel.org/stable/c/9196e42a3b8eeff1707e6ef769112b4b6096be49 - https://git.kernel.org/stable/c/e13ba3fe5ee070f8a9dab60029d52b1f61da5051 - https://git.kernel.org/stable/c/e3ad503876283ac3fcca922a1bf243ef9eb0b0e2 - https://git.kernel.org/stable/c/68dc02f319b9ee54dc23caba742a5c754d1cccc8 - https://git.kernel.org/s
2a1bf243ef9eb0b0e2 - https://git.kernel.org/stable/c/68dc02f319b9ee54dc23caba742a5c754d1cccc8 - https://git.kernel.org/stable/c/6eabce6608d6f3440f4c03aa3d3ef50a47a3d193
CVE ID: CVE-2024-43894 State: PUBLISHED Published: 2024-08-26T10:10:49.340Z Last Updated: 2025-11-03T22:06:57.078Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/client: fix null pointer dereference in drm_client_modeset_probe In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/24ddda932c43ffe156c7f3c568bed85131c63ae6 - https://git.kernel.o
Container: References: - https://git.kernel.org/stable/c/24ddda932c43ffe156c7f3c568bed85131c63ae6 - https://git.kernel.org/stable/c/5291d4f73452c91e8a11f71207617e3e234d418e - https://git.kernel.org/stable/c/c763dfe09425152b6bb0e348900a637c62c2ce52 - https://git.kernel.org/stable/c/d64847c383100423aecb6ac5f18be5f4316d9d62 - https://git.kernel.org/stable/c/d64fc94f7bb24fc2be0d6bd5df8df926da461a6d - https://git.kernel.org/stable/c/612cae53e99ce32a58cb821b3b67199eb6e92dff - https://git.kernel.org/stable/c/113fd6372a5bb3689aba8ef5b8a265ed1529a78f
CVE ID: CVE-2024-43895 State: PUBLISHED Published: 2024-08-26T10:10:50.934Z Last Updated: 2025-11-03T22:06:58.545Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip Recompute DSC Params if no Stream on Link [why] Encounter NULL pointer dereference uner mst + dsc setup. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_displa
VO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knl
3: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? asm_exc_page_fault+0x26/0x30 ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da
96438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drm_atomic_check_only+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0xbc0 [how] dsc recompute should be skipped if no mode change detected on the new request. If detected, keep checking whether the stream is already on current state or not. (cherry picked from commit 8151a6c13111b465dbabe07c19f572f7cb
ing whether the stream is already on current state or not. (cherry picked from commit 8151a6c13111b465dbabe07c19f572f7cbd16fef) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/282f0a482ee61d5e863512f3c4fcec90216c20d9 - https://git.kernel.org/stable/c/718d83f66fb07b2cab89a1fc984613a00e3db18f - https://git.kernel.org/stable/c/70275bb960c71d313254473d38c14e7101cee5ad - https://git.kernel.org/stable/c/50e376f1fe3bf571d0645ddf48ad37eb58323919
CVE ID: CVE-2024-43896 State: PUBLISHED Published: 2024-08-26T10:10:52.487Z Last Updated: 2025-05-04T09:28:47.210Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: cs-amp-lib: Fix NULL pointer crash if efi.get_variable is NULL Call efi_rt_services_supported() to check that efi.get_variable exists before calling it. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/5b6baaa7cbd77ff980516bad38bbc5a648bb5158 - https://git.kernel.org/stable/c/dc268085e499666b9f4f0fcb4c5a94e1c0b193b3
CVE ID: CVE-2024-43897 State: PUBLISHED Published: 2024-08-26T10:10:53.972Z Last Updated: 2025-11-03T22:06:59.989Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: drop bad gso csum_start and offset in virtio_net_hdr Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb for GSO packets. The function already checks that a checksum requested with VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets this might not hold for segs after segmentation. Syzkaller demonstrated to reach this warning in skb_checksum_help offset = skb_checksum_start_offset(skb); ret = -EINVAL; if (WARN_ON_ONCE(offset >= skb_head
warning in skb_checksum_help offset = skb_checksum_start_offset(skb); ret = -EINVAL; if (WARN_ON_ONCE(offset >= skb_headlen(skb))) By injecting a TSO packet: WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0 ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774 ip_finish_output_gso net/ipv4/ip_output.c:279 [inline] __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301 iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4850 [inline] netdev_start_xmit include/linux/netdevice.h
pv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4850 [inline] netdev_start_xmit include/linux/netdevice.h:4864 [inline] xmit_one net/core/dev.c:3595 [inline] dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611 __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261 packet_snd net/packet/af_packet.c:3073 [inline] The geometry of the bad input packet at tcp_gso_segment: [ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [ 52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244 [ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ip_summed=3 complete_sw=0 valid=0 level=0
1552 type=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ip_summed=3 complete_sw=0 valid=0 level=0) Mitigate with stricter input validation. csum_offset: for GSO packets, deduce the correct value from gso_type. This is already done for USO. Extend it to TSO. Let UFO be: udp[46]_ufo_fragment ignores these fields and always computes the checksum in software. csum_start: finding the real offset requires parsing to the transport header. Do not add a parser, use existing segmentation parsing. Thanks to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded. Again test both TSO and USO. Do not test UFO for the above reason, and do not test UDP tunnel offload. GSO
w offloaded. Again test both TSO and USO. Do not test UFO for the above reason, and do not test UDP tunnel offload. GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit from devices with no checksum offload"), but then still these fields are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no need to test for ip_summed == CHECKSUM_PARTIAL first. This revises an existing fix mentioned in the Fixes tag, which broke small packets with GSO offload, as detected by kselftests. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/413e785a8
Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/413e785a89f8bde0d4156a54b8ac2fa003c06756 - https://git.kernel.org/stable/c/f01c5e335fbb7fb612d40f14a3c02e2612a43d3b - https://git.kernel.org/stable/c/6772c4868a8e7ad5305957cdb834ce881793acb7 - https://git.kernel.org/stable/c/2edbb3e8838c672cd7e247e47989df9d03fc6668 - https://git.kernel.org/stable/c/89add40066f9ed9abe5f7f886fe5789ff7e0c50e
CVE ID: CVE-2024-43898 State: REJECTED Published: 2024-08-26T10:10:55.547Z Last Updated: 2024-09-10T07:14:38.157Z Description: No description available.