Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2024-50195 State: PUBLISHED Published: 2024-11-08T05:54:10.183Z Last Updated: 2025-11-03T22:26:50.538Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid().
EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself. Additional Anal
e(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/29f085345cde24566efb751f39e5d367c381c584 - https://git.kernel.org/stable/c/e0c966bd3e31911b57ef76cec4c5796ebd88e512 - https://git.kernel.org/stable/c/673a1c5a2998acbd429d6286e6cad10f17f4f073 - https://git.kernel.org/stable/c/c8789fbe2bbf75845e45302cba6ffa44e1884d01 - https://git.kernel.org/stable/c/27abbde44b6e71ee3891de13e1a228aa7ce95bfe - https://git.kernel.org/stable/c/a3f169e398215e71361774d13bf91a0101283ac2 - https://git.kernel.org/stable/c/1ff7247101af723731ea42e
t.kernel.org/stable/c/a3f169e398215e71361774d13bf91a0101283ac2 - https://git.kernel.org/stable/c/1ff7247101af723731ea42ed565d54fb8f341264 - https://git.kernel.org/stable/c/d8794ac20a299b647ba9958f6d657051fc51a540
CVE ID: CVE-2024-50196 State: PUBLISHED Published: 2024-11-08T05:54:10.949Z Last Updated: 2025-11-03T22:26:51.994Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, &reg); if (!reg) continue; chained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardw
configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ``` A
ng interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ``` Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/655f5d4662b958122b260be05aa6dfdf8768efe6 - https://git.kernel.org/stable/c/4a81800ef05bea5a9896f199677f7b7f5020776a - https://git.kernel.org/stable/c/20728e86289ab463b99b7ab4425515bd26aba417 - https://git.kernel.org/stable/c/dcbe9954634807ec54e22bde278b5b269f921381 - https://git.kernel.org/stable/c/93b8ddc54507a227087c60a0013ed833b6ae7d3c
CVE ID: CVE-2024-50197 State: PUBLISHED Published: 2024-11-08T05:54:11.739Z Last Updated: 2025-10-01T20:27:07.618Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be us
nity(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/be3f7b9f995a6c2ee02767a0319929a2a98adf69 - https://git.kernel.org/stable/c/16a6d2e685e8f9a2f51dd5a363d3f97fcad35e22
CVE ID: CVE-2024-50198 State: PUBLISHED Published: 2024-11-08T05:54:12.450Z Last Updated: 2025-11-03T22:26:53.442Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the fi
on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/bf3ab8e1c28f10df0823d4ff312f83c952b06a15 - https://git.kernel.org/stable/c/50039aec43a82ad2495f2d0fb0c289c8717b4bb2 - https://git.kernel.org/stable/c/bcb90518ccd9e10bf6ab29e31994aab93e4a4361 - https://git.kernel.org/stable/c/2cbb41abae65626736b8b52cf3b9339612c5a
table/c/bcb90518ccd9e10bf6ab29e31994aab93e4a4361 - https://git.kernel.org/stable/c/2cbb41abae65626736b8b52cf3b9339612c5a86a - https://git.kernel.org/stable/c/905166531831beb067fffe2bdfc98031ffe89087 - https://git.kernel.org/stable/c/c7c44e57750c31de43906d97813273fdffcf7d02
CVE ID: CVE-2024-50199 State: PUBLISHED Published: 2024-11-08T05:54:13.403Z Last Updated: 2025-11-03T22:26:54.906Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_b
generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ba7f982cdb37ff5a7739dec85d7325ea66fc1496 - https://git.kernel.org/stable/c/417d5838ca73c6331ae2fe692fab6c25c00d9a0b - https://git.kernel.org/stable/c/e41710f5a61aca9d6baaa8f53908a927dd9e7aa7 - https://git.kernel.org/stable/c/6ec0fe3756f941f42f8c57156b8bdf2877b2ebaf - https://git.kernel.org/stable/c/bed2b9037
7 - https://git.kernel.org/stable/c/6ec0fe3756f941f42f8c57156b8bdf2877b2ebaf - https://git.kernel.org/stable/c/bed2b9037806c62166a0ef9a559a1e7e3e1275b8 - https://git.kernel.org/stable/c/eb66a833cdd2f7302ee05d05e0fa12a2ca32eb87 - https://git.kernel.org/stable/c/7528c4fb1237512ee18049f852f014eba80bbe8d
CVE ID: CVE-2024-50200 State: PUBLISHED Published: 2024-11-08T05:54:14.167Z Last Updated: 2025-11-03T22:26:56.357Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series "maple_tree: correct tree corruption on spanning store", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 ("mm/mmap: avoid zeroing vma tree in mmap_region()"), which is the point at which reports started to be submitted concerning this bug. We wer
ing vma tree in mmap_region()"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by det
isting entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are p
ere has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_pr
ng store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the e
ing_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_
entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \ pivot = 0xffff / \ pivot = ULONG_MAX / ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7c7874977da9e47ca0f53d8b9a5b17385fed83f2 - https://git.kernel.org/stable/c/677f1df179cb6
https://git.kernel.org/stable/c/7c7874977da9e47ca0f53d8b9a5b17385fed83f2 - https://git.kernel.org/stable/c/677f1df179cb68c12ddf7707ec325eb50e99c7d9 - https://git.kernel.org/stable/c/982dd0d26d1f015ed34866579480d2be5250b0ef - https://git.kernel.org/stable/c/bea07fd63192b61209d48cbb81ef474cc3ee4c62
CVE ID: CVE-2024-50201 State: PUBLISHED Published: 2024-11-08T05:56:15.622Z Last Updated: 2025-11-03T22:26:57.827Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 ("drm: Validate encoder->possible_clones"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_cl
ectly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/df75c78bfeff99f9b4815c3e79e2b1b1e34fe264 - https://git.kernel.org/stable/c/fda5dc80121b12871dc343ab37e0c3f0d138825d - https://git.kernel.org/stable/c/c3cd27d85f0778f4ec07384d7516b33153759b8e - https://git.kernel.org/stable/c/1a235af0216411a32ab4db54
.kernel.org/stable/c/c3cd27d85f0778f4ec07384d7516b33153759b8e - https://git.kernel.org/stable/c/1a235af0216411a32ab4db54f7bd19020b46c86d - https://git.kernel.org/stable/c/68801730ebb9393460b30cd3885e407f15da27a9 - https://git.kernel.org/stable/c/28127dba64d8ae1a0b737b973d6d029908599611
CVE ID: CVE-2024-50202 State: PUBLISHED Published: 2024-11-08T05:56:16.544Z Last Updated: 2025-11-03T22:26:59.311Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but
ges is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/bb857ae1efd3138c653239ed1e7aef14e1
Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/bb857ae1efd3138c653239ed1e7aef14e1242c81 - https://git.kernel.org/stable/c/b4b3dc9e7e604be98a222e9f941f5e93798ca475 - https://git.kernel.org/stable/c/c1d0476885d708a932980b0f28cd90d9bd71db39 - https://git.kernel.org/stable/c/edf8146057264191d5bfe5b91773f13d936dadd3 - https://git.kernel.org/stable/c/270a6f9df35fa2aea01ec23770dc9b3fc9a12989 - https://git.kernel.org/stable/c/9698088ac7704e260f492d9c254e29ed7dd8729a - https://git.kernel.org/stable/c/efa810b15a25531cbc2f527330947b9fe16916e7 - https://git.kernel.org/stable/c/08cfa12adf888db98879dbd735bc741360a34168
CVE ID: CVE-2024-50203 State: PUBLISHED Published: 2024-11-08T06:07:54.207Z Last Updated: 2025-05-22T12:39:47.050Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Fix address emission with tag-based KASAN enabled When BPF_TRAMP_F_CALL_ORIG is enabled, the address of a bpf_tramp_image struct on the stack is passed during the size calculation pass and an address on the heap is passed during code generation. This may cause a heap buffer overflow if the heap address is tagged because emit_a64_mov_i64() will emit longer code than it did during the size calculation pass. The same problem could occur without tag-based KASAN
will emit longer code than it did during the size calculation pass. The same problem could occur without tag-based KASAN if one of the 16-bit words of the stack address happened to be all-ones during the size calculation pass. Fix the problem by assuming the worst case (4 instructions) when calculating the size of the bpf_tramp_image address emission. References: - https://git.kernel.org/stable/c/9e80f366ebfdfafc685fe83a84c34f7ef01cbe88 - https://git.kernel.org/stable/c/f521c2a0c0c4585f36d912bf62c852b88682c4f2 - https://git.kernel.org/stable/c/7db1a2121f3c7903b8e397392beec563c3d00950 - https://git.kernel.org/stable/c/a552e2ef5fd1a6c78267cd4ec5a9b49aa11bbb1c
CVE ID: CVE-2024-50204 State: PUBLISHED Published: 2024-11-08T06:07:55.095Z Last Updated: 2025-10-01T20:27:06.943Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs: don't try and remove empty rbtree node When copying a namespace we won't have added the new copy into the namespace rbtree until after the copy succeeded. Calling free_mnt_ns() will try to remove the copy from the rbtree which is invalid. Simply free the namespace skeleton directly. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/a8b155a2c30dc9a5ba837aa5fcba9a47cc031a9b - https://git.kernel.org/stable/c/229fd15908fe1
https://git.kernel.org/stable/c/a8b155a2c30dc9a5ba837aa5fcba9a47cc031a9b - https://git.kernel.org/stable/c/229fd15908fe1f99b1de4cde3326e62d1e892611
CVE ID: CVE-2024-50205 State: PUBLISHED Published: 2024-11-08T06:07:55.993Z Last Updated: 2025-11-03T22:27:00.776Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition
r size"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d575414361630b8b0523912532fcd7c79e43468c - https://git.kernel.org/stable/c/5e431f85c87bbffd93a9830d5a576586f9855291 - https://git.kernel.org/stable/c/7d4eb9e22131ec154e638cbd56629195c9bcbe9a - https://git.kernel.org/stable/c/d2826873db70a6719cdd9212a6739f3e6234cfc4 - https://git.kernel.org/stable/c/4bdc21506f12b2d432b1f2667e5ff4c75eee58e3 - htt
2826873db70a6719cdd9212a6739f3e6234cfc4 - https://git.kernel.org/stable/c/4bdc21506f12b2d432b1f2667e5ff4c75eee58e3 - https://git.kernel.org/stable/c/3452d39c4704aa12504e4190298c721fb01083c3 - https://git.kernel.org/stable/c/72cafe63b35d06b5cfbaf807e90ae657907858da
CVE ID: CVE-2024-50206 State: PUBLISHED Published: 2024-11-08T06:07:56.867Z Last Updated: 2025-10-01T20:27:06.677Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init The loop responsible for allocating up to MTK_FQ_DMA_LENGTH buffers must only touch as many descriptors, otherwise it ends up corrupting unrelated memory. Fix the loop iteration count accordingly. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/68cd084e3ec1512cd383cb3e9cf0ab7ab413724c - https://git.kernel.org/stable/c/88806efc034a9830f483963326b99930ad5
/stable/c/68cd084e3ec1512cd383cb3e9cf0ab7ab413724c - https://git.kernel.org/stable/c/88806efc034a9830f483963326b99930ad519af1
CVE ID: CVE-2024-50207 State: PUBLISHED Published: 2024-11-08T06:07:57.780Z Last Updated: 2025-10-01T20:27:06.537Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix reader locking when changing the sub buffer order The function ring_buffer_subbuf_order_set() updates each ring_buffer_per_cpu and installs new sub buffers that match the requested page order. This operation may be invoked concurrently with readers that rely on some of the modified data, such as the head bit (RB_PAGE_HEAD), or the ring_buffer_per_cpu.pages and reader_page pointers. However, no exclusive access is acquired by ring_buffer_subbuf_order_se
g_buffer_per_cpu.pages and reader_page pointers. However, no exclusive access is acquired by ring_buffer_subbuf_order_set(). Modifying the mentioned data while a reader also operates on them can then result in incorrect memory access and various crashes. Fix the problem by taking the reader_lock when updating a specific ring_buffer_per_cpu in ring_buffer_subbuf_order_set(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/a569290525a05162d5dd26d9845591eaf46e5802 - https://git.kernel.org/stable/c/09661f75e75cb6c1d2d8326a70c311d46729235f