Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ble/c/935035cf97c8cd6794044b500fb0a44a6d30ffa1 - https://git.kernel.org/stable/c/14bac0c7035bf920e190a63c7e1b113c72eadbf4 - https://git.kernel.org/stable/c/230ad40a59c9a9ee8f3822b9a7bec09404102ebc - https://git.kernel.org/stable/c/a32dc6829e33c54e751346aa3e08ddb6d0e1a6a0 - https://git.kernel.org/stable/c/507159facf002d113c4878fec67f37d62f187887 - https://git.kernel.org/stable/c/9705db1eff38d6b9114121f9e253746199b759c9
CVE ID: CVE-2022-50200 State: PUBLISHED Published: 2025-06-18T11:03:42.627Z Last Updated: 2025-07-15T15:43:47.479Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: selinux: Add boundary check in put_entry() Just like next_entry(), boundary check is necessary to prevent memory out-of-bound access. References: - https://git.kernel.org/stable/c/2dabe6a872a5744865372eb30ea51e8ccd21305a - https://git.kernel.org/stable/c/477722f31ad73aa779154d1d7e00825538389f76 - https://git.kernel.org/stable/c/90bdf50ae70c5571a277b5601e4f5df210831e0a - https://git.kernel.org/stable/c/adbfdaacde18faf6cd4e490764045375266b3fbd - https://git.kernel.org/st
01e4f5df210831e0a - https://git.kernel.org/stable/c/adbfdaacde18faf6cd4e490764045375266b3fbd - https://git.kernel.org/stable/c/7363a69d8ca8f0086f8e1196c8ddaf0e168614b1 - https://git.kernel.org/stable/c/9605f50157cae00eb299e1189a6d708c84935ad8 - https://git.kernel.org/stable/c/dedd558d9765b72c66e5a53948e9f5abc3ece1f6 - https://git.kernel.org/stable/c/15ec76fb29be31df2bccb30fc09875274cba2776
CVE ID: CVE-2022-50201 State: PUBLISHED Published: 2025-06-18T11:03:43.263Z Last Updated: 2025-09-03T12:59:05.127Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: selinux: fix memleak in security_read_state_kernel() In this function, it directly returns the result of __security_read_policy without freeing the allocated memory in *data, cause memory leak issue, so free the memory if __security_read_policy failed. [PM: subject line tweak] References: - https://git.kernel.org/stable/c/c877c5217145bda8fd95f506bf42f8d981afa57d - https://git.kernel.org/stable/c/f3cd7562c0a6774fc62d79654482014020e574f5 - https://git.kernel.org/stable/c
8d981afa57d - https://git.kernel.org/stable/c/f3cd7562c0a6774fc62d79654482014020e574f5 - https://git.kernel.org/stable/c/1fc1f72aad2070d34022d0823e4cf09706b53f25 - https://git.kernel.org/stable/c/73de1befcc53a7c68b0c5e76b9b5ac41c517760f
CVE ID: CVE-2022-50202 State: PUBLISHED Published: 2025-06-18T11:03:43.874Z Last Updated: 2025-06-18T11:03:43.874Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PM: hibernate: defer device probing when resuming from hibernation syzbot is reporting hung task at misc_open() [1], for there is a race window of AB-BA deadlock which involves probe_count variable. Currently wait_for_device_probe() from snapshot_open() from misc_open() can sleep forever with misc_mtx held if probe_count cannot become 0. When a device is probed by hub_event() work function, probe_count is incremented before the probe function starts, and probe_count is
is probed by hub_event() work function, probe_count is incremented before the probe function starts, and probe_count is decremented after the probe function completed. There are three cases that can prevent probe_count from dropping to 0. (a) A device being probed stopped responding (i.e. broken/malicious hardware). (b) A process emulating a USB device using /dev/raw-gadget interface stopped responding for some reason. (c) New device probe requests keeps coming in before existing device probe requests complete. The phenomenon syzbot is reporting is (b). A process which is holding system_transition_mutex and misc_mtx is waiting for probe_count to become 0 inside wait_for_device_probe(), but
holding system_transition_mutex and misc_mtx is waiting for probe_count to become 0 inside wait_for_device_probe(), but the probe function which is called from hub_event() work function is waiting for the processes which are blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface. This patch mitigates (b) by deferring wait_for_device_probe() from snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that the possibility of (b) remains as long as any thread which is emulating a USB device via /dev/raw-gadget interface can be blocked by uninterruptible blocking operations (e.g. mutex_lock()). Please also note that (a) and (c) are not addressed. Regarding (c),
erruptible blocking operations (e.g. mutex_lock()). Please also note that (a) and (c) are not addressed. Regarding (c), we should change the code to wait for only one device which contains the image for resuming from hibernation. I don't know how to address (a), for use of timeout for wait_for_device_probe() might result in loss of user data in the image. Maybe we should require the userland to wait for the image device before opening /dev/snapshot interface. References: - https://git.kernel.org/stable/c/8c90947e5f1801e6c7120021c6ea0f3ad6a4eb91 - https://git.kernel.org/stable/c/5a283b59bce72c05c60e9f0fa92a28b5b850d8bb - https://git.kernel.org/stable/c/3c48d3067eaf878642276f053575a5c642600a50
le/c/5a283b59bce72c05c60e9f0fa92a28b5b850d8bb - https://git.kernel.org/stable/c/3c48d3067eaf878642276f053575a5c642600a50 - https://git.kernel.org/stable/c/003a456ae6f70bb97e436e02fc5105be577c1570 - https://git.kernel.org/stable/c/2f0e18e0db42f4f8bc87d3d98333680065ceeff8 - https://git.kernel.org/stable/c/b8e1ae9433d7bd95f2dcc044a7a6f20a4c40d258 - https://git.kernel.org/stable/c/f7042cf9dd40733f387b7cac021e626c74b8856f - https://git.kernel.org/stable/c/8386c414e27caba8501119948e9551e52b527f59
CVE ID: CVE-2022-50203 State: PUBLISHED Published: 2025-06-18T11:03:44.520Z Last Updated: 2025-06-18T11:03:44.520Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ARM: OMAP2+: display: Fix refcount leak bug In omapdss_init_fbdev(), of_find_node_by_name() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. References: - https://git.kernel.org/stable/c/bdbdf69d5b78c5712c60c0004fa6aed12da36e26 - https://git.kernel.org/stable/c/0b4f96b47ff8dc2fa35d03c4116927248796d9af - https://git.kernel.org/stable/c/3e505298a75f0bbdc96e923e76e5d45d6c8f64a7 - https://git.kernel.org/stable/c
7248796d9af - https://git.kernel.org/stable/c/3e505298a75f0bbdc96e923e76e5d45d6c8f64a7 - https://git.kernel.org/stable/c/88d556029a78999b098d26a330bb6a7de166f426 - https://git.kernel.org/stable/c/a89a865dc9f0600fd146224e314775b9efc9d845 - https://git.kernel.org/stable/c/496988a19d5c36fabf97c847db39167e42393c74 - https://git.kernel.org/stable/c/2629d171f3d6451724549d8d10d14ac6da37a7be - https://git.kernel.org/stable/c/50b87a32a79bca6e275918a711fb8cc55e16d739
CVE ID: CVE-2022-50204 State: PUBLISHED Published: 2025-06-18T11:03:45.256Z Last Updated: 2025-06-18T11:03:45.256Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ARM: OMAP2+: pdata-quirks: Fix refcount leak bug In pdata_quirks_init_clocks(), the loop contains of_find_node_by_name() but without corresponding of_node_put(). References: - https://git.kernel.org/stable/c/75f23d72b6e0a34c8a0e8d275b69ba1e6dd0f15f - https://git.kernel.org/stable/c/ebca6870fc0cb5470dbc058cc94f3c53ea886eaa - https://git.kernel.org/stable/c/37f0c89778576ce3d52f40c1e9e727fbddedb28e - https://git.kernel.org/stable/c/5cdbab96bab314c6f2f5e4e8b8a019181328bf5f
CVE ID: CVE-2022-50205 State: PUBLISHED Published: 2025-06-18T11:03:45.889Z Last Updated: 2025-06-18T11:03:45.889Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext2: Add more validity checks for inode counts Add checks verifying number of inodes stored in the superblock matches the number computed from number of inodes per group. Also verify we have at least one block worth of inodes per group. This prevents crashes on corrupted filesystems. References: - https://git.kernel.org/stable/c/0bcdc31094a12b4baf59e241feabc9787cf635fa - https://git.kernel.org/stable/c/07303a9abe3a997d9864fb4315e34b5acfe8fc25 - https://git.kernel.org/
241feabc9787cf635fa - https://git.kernel.org/stable/c/07303a9abe3a997d9864fb4315e34b5acfe8fc25 - https://git.kernel.org/stable/c/b3f423683818cfe15de14d5d9dff44148ff16bbf - https://git.kernel.org/stable/c/d08bb199a406424a8ed0009efdf41710e6d849ee - https://git.kernel.org/stable/c/96b18d3a1be0354ccce43f0ef61b5a3d7e432552 - https://git.kernel.org/stable/c/7a48fdc88a3c35e046a6a0a38eba00f21c65b16e - https://git.kernel.org/stable/c/5e63c5fe9123fa76ffaeff26c211308736ec3a07 - https://git.kernel.org/stable/c/fa78f336937240d1bc598db817d638086060e7e9
CVE ID: CVE-2022-50206 State: PUBLISHED Published: 2025-06-18T11:03:46.505Z Last Updated: 2025-06-18T11:03:46.505Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64: fix oops in concurrently setting insn_emulation sysctls emulation_proc_handler() changes table->data for proc_dointvec_minmax and can generate the following Oops if called concurrently with itself: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | update_insn_emulation_mode+0xc0/0x148 | emulation_proc_handler+0x64/0xb8 | proc_sys_call_handler+0x9c/0xf8 | proc_sys_write
ate_insn_emulation_mode+0xc0/0x148 | emulation_proc_handler+0x64/0xb8 | proc_sys_call_handler+0x9c/0xf8 | proc_sys_write+0x18/0x20 | __vfs_write+0x20/0x48 | vfs_write+0xe4/0x1d0 | ksys_write+0x70/0xf8 | __arm64_sys_write+0x20/0x28 | el0_svc_common.constprop.0+0x7c/0x1c0 | el0_svc_handler+0x2c/0xa0 | el0_svc+0x8/0x200 To fix this issue, keep the table->data as &insn->current_mode and use container_of() to retrieve the insn pointer. Another mutex is used to protect against the current_mode update but not for retrieving insn_emulation as table->data is no longer changing. References: - https://git.kernel.org/stable/c/9d5fec6ba2e4117d196a8259ab54615ffe562460 - https://git.kernel.org/stable/c/b51
rences: - https://git.kernel.org/stable/c/9d5fec6ba2e4117d196a8259ab54615ffe562460 - https://git.kernel.org/stable/c/b51881b1da57fe9877125dfdd0aac5172958fcfd - https://git.kernel.org/stable/c/04549063d5701976034d8c2bfda3d3a8cbf0409f - https://git.kernel.org/stable/c/353b4673d01c512303c45cf2346f630cda73b5c9 - https://git.kernel.org/stable/c/cc69ef95988b9ef2fc730ec452a7441efb90ef5e - https://git.kernel.org/stable/c/6a2fd114678d7fc1b5a0f8865ae98f1c17787455 - https://git.kernel.org/stable/c/07022e07017ee5540f5559b0aeb916e8383c1e1a - https://git.kernel.org/stable/c/af483947d472eccb79e42059276c4deed76f99a6
CVE ID: CVE-2022-50207 State: PUBLISHED Published: 2025-06-18T11:03:47.185Z Last Updated: 2025-06-18T11:03:47.185Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ARM: bcm: Fix refcount leak in bcm_kona_smc_init of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. References: - https://git.kernel.org/stable/c/62d719d31ec667276d7375b64542b080cf187797 - https://git.kernel.org/stable/c/75866df2b1d673df5b7781e565ada753a7895f04 - https://git.kernel.org/stable/c/5afe042c889437de83f38a9d73d145742fb4f65f - http
866df2b1d673df5b7781e565ada753a7895f04 - https://git.kernel.org/stable/c/5afe042c889437de83f38a9d73d145742fb4f65f - https://git.kernel.org/stable/c/91e7f04f53e680bc72f0a9a5c682ab652100b9c8 - https://git.kernel.org/stable/c/bc7f487395f208fd9af69e9a807815e10435aba7 - https://git.kernel.org/stable/c/c6964cb9ac7a43bf78e7d60126e2722992de2ea1 - https://git.kernel.org/stable/c/02b658bfb26452f2c13e4577a13ab802f89a6642 - https://git.kernel.org/stable/c/cb23389a2458c2e4bfd6c86a513cbbe1c4d35e76
CVE ID: CVE-2022-50208 State: PUBLISHED Published: 2025-06-18T11:03:47.848Z Last Updated: 2025-06-18T11:03:47.848Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: soc: amlogic: Fix refcount leak in meson-secure-pwrc.c In meson_secure_pwrc_probe(), there is a refcount leak in one fail path. References: - https://git.kernel.org/stable/c/80c469e63bfa9a5a8114952bffc6a7d241e7497e - https://git.kernel.org/stable/c/f370fbbd3151c1c87d1e976c8964cb6cc46f2e00 - https://git.kernel.org/stable/c/5509d07a9364b75b28055bf2d89289e4e5269929 - https://git.kernel.org/stable/c/d1fbbb5ded714b6610a16ec3d7e271a55291ccc4 - https://git.kernel.org/stable/c
9e4e5269929 - https://git.kernel.org/stable/c/d1fbbb5ded714b6610a16ec3d7e271a55291ccc4 - https://git.kernel.org/stable/c/d18529a4c12f66d83daac78045ea54063bd43257
CVE ID: CVE-2022-50209 State: PUBLISHED Published: 2025-06-18T11:03:48.479Z Last Updated: 2025-06-18T11:03:48.479Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: meson-mx-socinfo: Fix refcount leak in meson_mx_socinfo_init of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. References: - https://git.kernel.org/stable/c/69a64c77aafcf3c772264a36214937514e31ad82 - https://git.kernel.org/stable/c/6b28bf3e044f12db0fc18c42f58ae7fc3fa0144a - https://git.kernel.org/stable/c/2691b8780f88e1b8b3578a5bc78a0011741
/stable/c/6b28bf3e044f12db0fc18c42f58ae7fc3fa0144a - https://git.kernel.org/stable/c/2691b8780f88e1b8b3578a5bc78a0011741bbd74 - https://git.kernel.org/stable/c/e21744c6a0d4116a2d6ebccd947620ca4c952e92 - https://git.kernel.org/stable/c/8a4a33b3e898b13c750b1c0c9643516c7bf6473f - https://git.kernel.org/stable/c/0c1757480a6a61b8c3164ed371c359edb3928f12 - https://git.kernel.org/stable/c/a2106f38077e78afcb4bf98fdda3e162118cfb3d
CVE ID: CVE-2022-50210 State: PUBLISHED Published: 2025-06-18T11:03:49.089Z Last Updated: 2025-06-18T11:03:49.089Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: MIPS: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs. [ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linke
--- [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.084034] Hardware name: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.13
0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<98000000002086d8>] show_stack+0x38/0x14c [ 3.210666]
0000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<98000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9800000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<980000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9800000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9800000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<98000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<98000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<98000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<98000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9800000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9800000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end tra
0000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9800000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]--- References: - https://git.kernel.org/stable/c/d3ac4e47510ec0753ebe1e418a334ad202784aa8 - https://git.kernel.org/stable/c/98aaa511957667ba26d6dabe28dfa210a8f53a63 - https://git.kernel.org/stable/c/4cb392956ae392aec4aa06e661a0bb9146b0bace - https://git.kernel.org/stable/c/274e44e2123417e0924c90d4b4531913b5f3aa2e - https://git.kernel.org/stable/c/807adf6ffa8c3beedcd63b20f5a59c7d061df7d2 - https://git.kernel.org/stable/c/e41db8a9ce696a3382a4f098878fd4d14bccd201 - https://git.kernel.org/stable/c/8916ec149c79cb21f5454fa7840ad96f99cf51cf - https://git.kern
3382a4f098878fd4d14bccd201 - https://git.kernel.org/stable/c/8916ec149c79cb21f5454fa7840ad96f99cf51cf - https://git.kernel.org/stable/c/7d305823e02217b29d41fca67e3cef87fd7bd688 - https://git.kernel.org/stable/c/e1a534f5d074db45ae5cbac41d8912b98e96a006
CVE ID: CVE-2022-50211 State: PUBLISHED Published: 2025-06-18T11:03:49.739Z Last Updated: 2025-06-18T11:03:49.739Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md-raid10: fix KASAN warning There's a KASAN warning in raid10_remove_disk when running the lvm test lvconvert-raid-reshape.sh. We fix this warning by verifying that the value "number" is valid. BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10] Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682 CPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/20
Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report.cold+0x45/0x57a ? __lock_text_start+0x18/0x18 ? raid10_remove_disk+0x61/0x2a0 [raid10] kasan_report+0xa8/0xe0 ? raid10_remove_disk+0x61/0x2a0 [raid10] raid10_remove_disk+0x61/0x2a0 [raid10] Buffer I/O error on dev dm-76, logical block 15344, async page read ? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0 remove_and_add_spares+0x367/0x8a0 [md_mod] ? super_written+0x1c0/0x1c0 [md_mod] ? mutex_trylock+0xac/0x120 ? _raw_spin_lock+0x72/0xc0 ? _raw_spin_lock_bh+0xc0/0xc0 md_check_recovery+0x848/0x960 [md_mod] raid10d+0
ock+0xac/0x120 ? _raw_spin_lock+0x72/0xc0 ? _raw_spin_lock_bh+0xc0/0xc0 md_check_recovery+0x848/0x960 [md_mod] raid10d+0xcf/0x3360 [raid10] ? sched_clock_cpu+0x185/0x1a0 ? rb_erase+0x4d4/0x620 ? var_wake_function+0xe0/0xe0 ? psi_group_change+0x411/0x500 ? preempt_count_sub+0xf/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? raid10_sync_request+0x36c0/0x36c0 [raid10] ? preempt_count_sub+0xf/0xc0 ? _raw_spin_unlock_irqrestore+0x19/0x40 ? del_timer_sync+0xa9/0x100 ? try_to_del_timer_sync+0xc0/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? _raw_spin_unlock_irq+0x11/0x24 ? __list_del_entry_valid+0x68/0xa0 ? finish_wait+0xa3/0x100 md_thread+0x161/0x
x18/0x18 ? _raw_spin_unlock_irq+0x11/0x24 ? __list_del_entry_valid+0x68/0xa0 ? finish_wait+0xa3/0x100 md_thread+0x161/0x260 [md_mod] ? unregister_md_personality+0xa0/0xa0 [md_mod] ? _raw_spin_lock_irqsave+0x78/0xc0 ? prepare_to_wait_event+0x2c0/0x2c0 ? unregister_md_personality+0xa0/0xa0 [md_mod] kthread+0x148/0x180 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Allocated by task 124495: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x80/0xa0 setup_conf+0x140/0x5c0 [raid10] raid10_run+0x4cd/0x740 [raid10] md_run+0x6f9/0x1300 [md_mod] raid_ctr+0x2531/0x4ac0 [dm_raid] dm_table_add_target+0x2b0/0x620 [dm_mod] table_load+0x1c8/0x400 [dm_mod] ctl_ioctl+0x29e/0x560 [dm_mod] dm_
c0 [dm_raid] dm_table_add_target+0x2b0/0x620 [dm_mod] table_load+0x1c8/0x400 [dm_mod] ctl_ioctl+0x29e/0x560 [dm_mod] dm_compat_ctl_ioctl+0x7/0x20 [dm_mod] __do_compat_sys_ioctl+0xfa/0x160 do_syscall_64+0x90/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0xc0 kvfree_call_rcu+0x84/0x480 timerfd_release+0x82/0x140 L __fput+0xfa/0x400 task_work_run+0x80/0xc0 exit_to_user_mode_prepare+0x155/0x160 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x42/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Second to last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0
e+0x46/0xb0 Second to last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0xc0 kvfree_call_rcu+0x84/0x480 timerfd_release+0x82/0x140 __fput+0xfa/0x400 task_work_run+0x80/0xc0 exit_to_user_mode_prepare+0x155/0x160 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x42/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The buggy address belongs to the object at ffff889108f3d200 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte region [ffff889108f3d200, ffff889108f3d300) The buggy address belongs to the physical page: page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0
buggy address belongs to the physical page: page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c head:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0 flags: 0x4000000000010200(slab|head|zone=2) raw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40 raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff889108f3d280: 00 00 ---truncated--- References: - https://git.kernel.org/stable/c/75fbd370a2cec9e92f48285bd90735ed0c837f52 - https://git.kernel.or
ncated--- References: - https://git.kernel.org/stable/c/75fbd370a2cec9e92f48285bd90735ed0c837f52 - https://git.kernel.org/stable/c/bcbdc26a44aba488d2f7122f2d66801bccb74733 - https://git.kernel.org/stable/c/7a6ccc8fa192fd357c2d5d4c6ce67c834a179e23 - https://git.kernel.org/stable/c/ce839b9331c11780470f3d727b6fe3c2794a4620 - https://git.kernel.org/stable/c/5fd4ffa2372a41361d2bdd27ea5730e4e673240c - https://git.kernel.org/stable/c/0f4d18cbea4a6e37a05fd8ee2887439f85211110 - https://git.kernel.org/stable/c/bf30b9ba09b0ac2a10f04dce2b0835ec4d178aa6 - https://git.kernel.org/stable/c/5f57843565131bb782388f9d993f9ee8f453dee1 - https://git.kernel.org/stable/c/d17f744e883b2f8d13cca252d71cfe8ace346f7d
CVE ID: CVE-2022-50212 State: PUBLISHED Published: 2025-06-18T11:03:50.366Z Last Updated: 2025-06-18T11:03:50.366Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not allow CHAIN_ID to refer to another table When doing lookups for chains on the same batch by using its ID, a chain from a different table can be used. If a rule is added to a table but refers to a chain in a different table, it will be linked to the chain in table2, but would have expressions referring to objects in table1. Then, when table1 is removed, the rule will not be removed as its linked to a chain in table2. When expressions in the