Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
gram Container: References: - https://git.kernel.org/stable/c/3e8081ebff12bec1347deaceb6bce0765cce54df - https://git.kernel.org/stable/c/c6b16e700cf4d959af524bd9d3978407ff7ce462 - https://git.kernel.org/stable/c/9f03f0016ff797932551881c7e06ae50e9c39134 - https://git.kernel.org/stable/c/9803ab882d565a8fb2dde5999d98866d1c499dfd - https://git.kernel.org/stable/c/81821617312988096f5deccf0f7da6f888e98056 - https://git.kernel.org/stable/c/a1afbbb5276f943ad7173d0b4c626b8c75a260da - https://git.kernel.org/stable/c/e32ee6a61041925d1a05c14d10352dcfce9ef029 - https://git.kernel.org/stable/c/8d0765f86135e27f0bb5c950c136495719b4c834 - https://git.kernel.org/stable/c/d078cbf5c38de83bc31f83c47dcd2184c04a50
able/c/8d0765f86135e27f0bb5c950c136495719b4c834 - https://git.kernel.org/stable/c/d078cbf5c38de83bc31f83c47dcd2184c04a50c7
CVE ID: CVE-2024-47738 State: PUBLISHED Published: 2024-10-21T12:14:07.825Z Last Updated: 2025-11-03T22:21:34.018Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for scanning"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of return
ver corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/aafca50e71dc8f3192a5bfb325135a7908f3ef9e - https://git.kernel.org/stable/c/d54455a3a965feb547711aff7afd2ca5deadb99c - https://git.kernel.org/stable/c/3565ef215101ffadb5fe5394c70b1fca51376b25 - htt
54455a3a965feb547711aff7afd2ca5deadb99c - https://git.kernel.org/stable/c/3565ef215101ffadb5fe5394c70b1fca51376b25 - https://git.kernel.org/stable/c/43897111481b679508711d3ca881c4c6593e9247 - https://git.kernel.org/stable/c/e7a7ef9a0742dbd0818d5b15fba2c5313ace765b
CVE ID: CVE-2024-47739 State: PUBLISHED Published: 2024-10-21T12:14:08.495Z Last Updated: 2025-11-03T22:21:35.468Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr w
s as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/46c4079460f4dcaf445860679558eedef4e1bc91 - https://git.kernel.org/stable/c/72164d5b648951684b1a593996b37a6083c61d7d - https://git.kernel.org/stable/c/ab205e1c3846326f162180e56825b4ba38ce9c30 - https://git.kernel.org/stable/c/1b8cf11b3ca593a8802a51802cd0c28c38501428 - https://git.kernel.org/stable/c/9e279e6c1f012b8
tps://git.kernel.org/stable/c/1b8cf11b3ca593a8802a51802cd0c28c38501428 - https://git.kernel.org/stable/c/9e279e6c1f012b82628b89e1b9c65dbefa8ca25a - https://git.kernel.org/stable/c/1bd712de96ad7167fe0d608e706cd60587579f16 - https://git.kernel.org/stable/c/9a22b2812393d93d84358a760c347c21939029a6
CVE ID: CVE-2024-47740 State: PUBLISHED Published: 2024-10-21T12:14:09.171Z Last Updated: 2025-11-03T22:21:36.961Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process ow
ios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything. Additional Analyst Notes: - CISA ADP Vulnrich
n intending to write into the file, that seems unlikely to break anything. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/700f3a7c7fa5764c9f24bbf7c78e0b6e479fa653 - https://git.kernel.org/stable/c/4ce87674c3a6b4d3b3d45f85b584ab8618a3cece - https://git.kernel.org/stable/c/000bab8753ae29a259feb339b99ee759795a48ac - https://git.kernel.org/stable/c/88ff021e1fea2d9b40b2d5efd9013c89f7be04ac - https://git.kernel.org/stable/c/32f348ecc149e9ca70a1c424ae8fa9b6919d2713 - https://git.kernel.org/stable/c/5e0de753bfe87768ebe6744d869caa92f35e5731 - https://git.kernel.org/stable/c/f3bfac2cabf5333506b263bc0c8497c95302f32d - https://gi
bfe87768ebe6744d869caa92f35e5731 - https://git.kernel.org/stable/c/f3bfac2cabf5333506b263bc0c8497c95302f32d - https://git.kernel.org/stable/c/4583290898c13c2c2e5eb8773886d153c2c5121d - https://git.kernel.org/stable/c/4f5a100f87f32cb65d4bb1ad282a08c92f6f591e
CVE ID: CVE-2024-47741 State: PUBLISHED Published: 2024-10-21T12:14:09.836Z Last Updated: 2025-05-04T09:38:51.637Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A
a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structur
l variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only on
ate), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state recor
the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f56a6d9c267ec7fa558ede7755551c047b1034cd - https://git.kernel.org/stable/c/a412ca489ac27b9d0e603499315b7139c948130d - https://git.kernel.org/stable/c/33d1310d4496e904123dab9c28b2d8d2c1800f97 - https://git.kernel.org/stable/c/7ee85f5515e86a4e2a2f51969795920733912bad
CVE ID: CVE-2024-47742 State: PUBLISHED Published: 2024-10-21T12:14:10.499Z Last Updated: 2025-11-03T22:21:38.407Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_f
leged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different be
tronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different because there, the "%s" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names cont
ce is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing ".." path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d1768e5535d3ded59f888637016e6f821f4e069f - https://git.kernel.org/stable/c/9b1ca33ebd05b3acef5b976c04e5e791af93ce1b - https://git.kernel.org/stable/c/c30558e6c5c9ad6c86459d9acce1520ceeab9ea6 - https://git.kernel.org/stable/c/a77fc4acfd49fc6076e565445b2bc5fdc3244da4 - https://git.kernel.org/stable/c/3d2411f4ed
- https://git.kernel.org/stable/c/a77fc4acfd49fc6076e565445b2bc5fdc3244da4 - https://git.kernel.org/stable/c/3d2411f4edcb649eaf232160db459bb4770b5251 - https://git.kernel.org/stable/c/7420c1bf7fc784e587b87329cc6dfa3dca537aa4 - https://git.kernel.org/stable/c/28f1cd94d3f1092728fb775a0fe26c5f1ac2ebeb - https://git.kernel.org/stable/c/6c4e13fdfcab34811c3143a0a03c05fec4e870ec - https://git.kernel.org/stable/c/f0e5311aa8022107d63c54e2f03684ec097d1394
CVE ID: CVE-2024-47743 State: PUBLISHED Published: 2024-10-21T12:14:11.173Z Last Updated: 2025-11-03T22:21:39.860Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Additional Analyst Notes: - CISA ADP Vulnrichme
Verification Center (linuxtesting.org) with Svace static analysis tool. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3322fa8f2aa40b0b3651034cd541647a600cc6c0 - https://git.kernel.org/stable/c/a3765b497a4f5224cb2f7a6a2d3357d3066214ee - https://git.kernel.org/stable/c/13b5b401ead95b5d8266f64904086c55b6024900 - https://git.kernel.org/stable/c/0d3b0706ada15c333e6f9faf19590ff715e45d1e - https://git.kernel.org/stable/c/70fd1966c93bf3bfe3fe6d753eb3d83a76597eef
CVE ID: CVE-2024-47744 State: PUBLISHED Published: 2024-10-21T12:14:11.830Z Last Updated: 2025-05-04T09:38:55.322Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->sr
, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadl
tion_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing t
to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already
uire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] k
_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/4777225ec89f52bb9ca16a33cfb44c189f1b7b47 - https://g
ISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/4777225ec89f52bb9ca16a33cfb44c189f1b7b47 - https://git.kernel.org/stable/c/a2764afce521fd9fd7a5ff6ed52ac2095873128a - https://git.kernel.org/stable/c/760a196e6dcb29580e468b44b5400171dae184d8 - https://git.kernel.org/stable/c/44d17459626052a2390457e550a12cb973506b2f
CVE ID: CVE-2024-47745 State: PUBLISHED Published: 2024-10-21T12:14:12.488Z Last Updated: 2025-11-03T20:40:38.700Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages sysc
ng a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pa
old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/0f910dbf2f2a4a7820ba4bac7b280
A ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/0f910dbf2f2a4a7820ba4bac7b280f7108aa05b1 - https://git.kernel.org/stable/c/49d3a4ad57c57227c3b0fd6cd4188b2a5ebd6178 - https://git.kernel.org/stable/c/3393fddbfa947c8e1fdcc4509226905ffffd8b89 - https://git.kernel.org/stable/c/ce14f38d6ee9e88e37ec28427b4b93a7c33c70d3 - https://git.kernel.org/stable/c/ea7e2d5e49c05e5db1922387b09ca74aa40f46e2
CVE ID: CVE-2024-47746 State: PUBLISHED Published: 2024-10-21T12:14:13.133Z Last Updated: 2025-05-04T09:38:58.456Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/fa4890bd8237e5a1e7428acd7328729db2703b23 - https://git.kernel.org/stable/c/4e181761ffec67307157a7e8a78d58ee4130cf00 - https://git.kernel.org/stable/c
29db2703b23 - https://git.kernel.org/stable/c/4e181761ffec67307157a7e8a78d58ee4130cf00 - https://git.kernel.org/stable/c/2f3d8ff457982f4055fe8f7bf19d3821ba22c376
CVE ID: CVE-2024-47747 State: PUBLISHED Published: 2024-10-21T12:14:13.783Z Last Updated: 2025-11-03T22:21:41.323Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | f
leanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/25d559ed2beec9b34045886100dac46d1ad92eba - https://git.kernel.org/stable/c/b5a84b6c772564c8359a9a0fbaeb2a2944aa1ee9 - https://git.kernel.org/stable/c/338a0582b28e69460df03af50e938b86b4206353 - https://git.kernel.org/stable/c/822c7bb1f
9 - https://git.kernel.org/stable/c/338a0582b28e69460df03af50e938b86b4206353 - https://git.kernel.org/stable/c/822c7bb1f6f8b0331e8d1927151faf8db3b33afd - https://git.kernel.org/stable/c/1c57d61a43293252ad732007c7070fdb112545fd - https://git.kernel.org/stable/c/d2abc379071881798d20e2ac1d332ad855ae22f3 - https://git.kernel.org/stable/c/516dbc6d16637430808c39568cbb6b841d32b55b - https://git.kernel.org/stable/c/77a77331cef0a219b8dd91361435eeef04cb741c - https://git.kernel.org/stable/c/b5109b60ee4fcb2f2bb24f589575e10cc5283ad4