Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
nsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/c9b77438077d5a20c79ead95bcdaf9bd4797baaf - https://git.kernel.org/stable/c/b723f96407a0a078cf75970e4dbf16b46d286a61 - https://git.kernel.org/stable/c/0bdf77be2330062b3a64f2bec39f62ab874a6796 - https://git.kernel.org/stable/c/0d16f53c91111cec914f0811fcc526a2ba77b20d - https://git.kernel.org/stable/c/0d196e7589cefe207d5d41f37a0a28a1fdeeb7c6
CVE ID: CVE-2024-50011 State: PUBLISHED Published: 2024-10-21T18:54:03.683Z Last Updated: 2025-05-04T09:43:45.285Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/aa3109ee91fe09e696274e6ac44813df8d13678f - https://git.kernel.org/stable/c/5afc29ba44fdd1bcbad4e07246c395
l.org/stable/c/aa3109ee91fe09e696274e6ac44813df8d13678f - https://git.kernel.org/stable/c/5afc29ba44fdd1bcbad4e07246c395d946301580
CVE ID: CVE-2024-50012 State: PUBLISHED Published: 2024-10-21T18:54:04.377Z Last Updated: 2025-11-03T22:24:27.744Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stabl
. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6c3d8387839252f1a0fc6367f314446e4a2ebd0b - https://git.kernel.org/stable/c/0f41f383b5a61a2bf6429a449ebba7fb08179d81 - https://git.kernel.org/stable/c/77f88b17387a017416babf1e6488fa17682287e2 - https://git.kernel.org/stable/c/47cb1d9278f179df8250304ec41009e3e836a926 - https://git.kernel.org/stable/c/c0f02536fffbbec71aced36d52a765f8c4493dc2
CVE ID: CVE-2024-50013 State: PUBLISHED Published: 2024-10-21T18:54:05.089Z Last Updated: 2025-11-03T22:24:29.224Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f692160d3e1e5450605071b8df8f7d08d9b09a83 - https://git.kernel.org/stable/c/ddf704c2ce3b73f38d2dd8cf1bb0f7ec038bdf63 - https://git.kernel.org/stable
f7d08d9b09a83 - https://git.kernel.org/stable/c/ddf704c2ce3b73f38d2dd8cf1bb0f7ec038bdf63 - https://git.kernel.org/stable/c/4e1813e52f86eb8db0c6c9570251f2fcbc571f5d - https://git.kernel.org/stable/c/bf0b3b35259475d1fe377bcaa565488e26684f7a - https://git.kernel.org/stable/c/dca359db1eb37f334267ebd7e3cab9a66d191d5b - https://git.kernel.org/stable/c/89081e8407e637463db5880d168e3652fb9f4330 - https://git.kernel.org/stable/c/d2b537b3e533f28e0d97293fe9293161fe8cd137
CVE ID: CVE-2024-50014 State: PUBLISHED Published: 2024-10-21T18:54:05.764Z Last Updated: 2025-11-03T20:43:00.666Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440
locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0
? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/
splat. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/13ea9547763a0488a90ff37cdf52ec85e36ea344 - https://git.kernel.org/stable/c/6e35f560daebe40264c95e9a1ab03110d4997df6 - https://git.kernel.org/stable/c/d157fc20ca5239fd56965a5a8aa1a0e25919891a - https://git.kernel.org/stable/c/b002031d585a14eed511117dda8c6452a804d508 - https://git.kernel.org/stable/c/23dfdb56581ad92a9967bcd720c8c23356af74c1
CVE ID: CVE-2024-50015 State: PUBLISHED Published: 2024-10-21T18:54:06.465Z Last Updated: 2025-11-03T22:24:30.667Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 d
tents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is
ts: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f8a7c342326f6ad1dfdb30a18dd013c70f5e9669 - https://git.kernel.org/stable/c/8c30a9a8610c314554997f86370140746aa35661 - https://git.kernel.org/stable/c/abfaa876b948baaea4d14f21a1963789845c8b4c - https://git.kernel.org/stable/c/5efccdee4a7d507a483f20f880b809cc4eaef14d - https://git.kernel.org/stable/c/a9f331f51515bdb3ebc8d0963131af367ef468f6 - https://git.kernel.org/stable/c/ec0dd451e236c46e4858d53e9e82bae7797a7af5 - https://git.kerne
3ebc8d0963131af367ef468f6 - https://git.kernel.org/stable/c/ec0dd451e236c46e4858d53e9e82bae7797a7af5 - https://git.kernel.org/stable/c/dda898d7ffe85931f9cca6d702a51f33717c501e
CVE ID: CVE-2024-50016 State: REJECTED Published: 2024-10-21T18:54:07.173Z Last Updated: 2025-05-10T14:04:03.592Z Description: No description available.
CVE ID: CVE-2024-50017 State: PUBLISHED Published: 2024-10-21T18:54:07.811Z Last Updated: 2025-05-04T09:43:54.260Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. O
erved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.
Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d113f9723f2bfd9c6feeb899b8ddbee6b8a6e01f - https://git.kernel.org/stable/c/d80a99892f7a992d103138fa4636b2c33abd6740 - https://git.kernel.org/stable/c/a23823098ab2c277c14fc110b97d8d5c83597195 - https://git.kernel.org/stable/c/cc31744a294584a36bf764a0ffa3255a8e69f036
CVE ID: CVE-2024-50018 State: REJECTED Published: 2024-10-21T18:54:08.468Z Last Updated: 2024-12-12T15:17:12.818Z Description: No description available.
CVE ID: CVE-2024-50019 State: PUBLISHED Published: 2024-10-21T19:39:25.908Z Last Updated: 2025-11-03T22:24:32.144Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparke
n TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 <TASK> kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [inline] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_
leanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Fix this with skipping unecessary unparking while stopping a kthread. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/40a6e660d2a3a7a5cb99f0b8ff4fb41bad039f68 - https://git.kernel.org/stable/c/8608196a155cb6cfae04d96b10a2652d0327e33f - https://git.kern
a5cb99f0b8ff4fb41bad039f68 - https://git.kernel.org/stable/c/8608196a155cb6cfae04d96b10a2652d0327e33f - https://git.kernel.org/stable/c/19a5029981c87c2ad0845e713837faa88f5d8e2b - https://git.kernel.org/stable/c/cda5423c1a1c906062ef235c940f249b97d9d135 - https://git.kernel.org/stable/c/214e01ad4ed7158cab66498810094fac5d09b218
CVE ID: CVE-2024-50020 State: PUBLISHED Published: 2024-10-21T19:39:26.555Z Last Updated: 2025-05-04T09:43:57.335Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count le
n currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an e
adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/416dbb815ca69684de148328990ba0ec53e6dbc1 - https://git.kernel.org/stable/c/d517cf89874c6039e6294b18d66f40988e62502a
CVE ID: CVE-2024-50021 State: PUBLISHED Published: 2024-10-21T19:39:27.212Z Last Updated: 2025-05-04T09:43:59.435Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference c
ntly returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this
n this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/aefecead9d08f4a35ab6f51ba2e408d2cef4e31d - https://git.kernel.org/stable/c/ccca30a18e36a742e606d5bf0630e75be7711d0a
CVE ID: CVE-2024-50022 State: PUBLISHED Published: 2024-10-21T19:39:27.873Z Last Updated: 2025-11-03T22:24:33.602Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-da
e is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 37
_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered
error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c974
recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: R
re memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem, but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Progra
device-dax selected alignment (page size i.e. 4K/2M/1G) Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9c4198dfdca818c5ce19c764d90eabd156bbc6da - https://git.kernel.org/stable/c/b822007e8db341d6f175c645ed79866db501ad86 - https://git.kernel.org/stable/c/e877427d218159ac29c9326100920d24330c9ee6 - https://git.kernel.org/stable/c/7fcbd9785d4c17ea533c42f20a9083a83f301fa6
CVE ID: CVE-2024-50023 State: PUBLISHED Published: 2024-10-21T19:39:28.524Z Last Updated: 2025-05-04T09:44:02.404Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct ordering") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod f
removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/143ffa7878e2d9d9c3836ee8304
tional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/143ffa7878e2d9d9c3836ee8304ce4930f7852a3 - https://git.kernel.org/stable/c/fba363f4d244269a0ba7abb8df953a244c6749af - https://git.kernel.org/stable/c/f50b5d74c68e551667e265123659b187a30fe3a5
CVE ID: CVE-2024-50024 State: PUBLISHED Published: 2024-10-21T19:39:29.203Z Last Updated: 2025-11-03T22:24:35.047Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop the