Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-49800 State: PUBLISHED Published: 2025-05-01T14:09:29.042Z Last Updated: 2025-05-04T08:45:37.373Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event() test_gen_synth_cmd() only free buf in fail path, hence buf will leak when there is no failure. Add kfree(buf) to prevent the memleak. The same reason and solution in test_empty_synth_event(). unreferenced object 0xffff8881127de000 (size 2048): comm "modprobe", pid 247, jiffies 4294972316 (age 78.756s) hex dump (first 32 bytes): 20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20 gen_synth_test 20
es 4294972316 (age 78.756s) hex dump (first 32 bytes): 20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20 gen_synth_test 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 64 5f pid_t next_pid_ backtrace: [<000000004254801a>] kmalloc_trace+0x26/0x100 [<0000000039eb1cf5>] 0xffffffffa00083cd [<000000000e8c3bc8>] 0xffffffffa00086ba [<00000000c293d1ea>] do_one_initcall+0xdb/0x480 [<00000000aa189e6d>] do_init_module+0x1cf/0x680 [<00000000d513222b>] load_module+0x6a50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd unreferenced object 0xffff8881127df000 (size 2048): comm "modprobe", pid 247
>] entry_SYSCALL_64_after_hwframe+0x63/0xcd unreferenced object 0xffff8881127df000 (size 2048): comm "modprobe", pid 247, jiffies 4294972324 (age 78.728s) hex dump (first 32 bytes): 20 65 6d 70 74 79 5f 73 79 6e 74 68 5f 74 65 73 empty_synth_tes 74 20 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 t pid_t next_pi backtrace: [<000000004254801a>] kmalloc_trace+0x26/0x100 [<00000000d4db9a3d>] 0xffffffffa0008071 [<00000000c31354a5>] 0xffffffffa00086ce [<00000000c293d1ea>] do_one_initcall+0xdb/0x480 [<00000000aa189e6d>] do_init_module+0x1cf/0x680 [<00000000d513222b>] load_module+0x6a50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000
50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/65ba7e7c241122ef0a9e61d1920f2ae9689aa796 - https://git.kernel.org/stable/c/07ba4f0603aba288580866394f2916dfe55823a2 - https://git.kernel.org/stable/c/0e5baaa181a052d968701bb9c5b1d55847f00942 - https://git.kernel.org/stable/c/a4527fef9afe5c903c718d0cd24609fe9c754250
CVE ID: CVE-2022-49801 State: PUBLISHED Published: 2025-05-01T14:09:29.682Z Last Updated: 2025-05-04T12:45:13.899Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Fix memory leak in tracing_read_pipe() kmemleak reports this issue: unreferenced object 0xffff888105a18900 (size 128): comm "test_progs", pid 18933, jiffies 4336275356 (age 22801.766s) hex dump (first 32 bytes): 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...B.X. 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000560143a1>] __kmalloc_node_track_caller+0x4a/0x140 [<000000006af00822>] krealloc+0x8d/0xf0 [<00000000c
cktrace: [<00000000560143a1>] __kmalloc_node_track_caller+0x4a/0x140 [<000000006af00822>] krealloc+0x8d/0xf0 [<00000000c309be6a>] trace_iter_expand_format+0x99/0x150 [<000000005a53bdb6>] trace_check_vprintf+0x1e0/0x11d0 [<0000000065629d9d>] trace_event_printf+0xb6/0xf0 [<000000009a690dc7>] trace_raw_output_bpf_trace_printk+0x89/0xc0 [<00000000d22db172>] print_trace_line+0x73c/0x1480 [<00000000cdba76ba>] tracing_read_pipe+0x45c/0x9f0 [<0000000015b58459>] vfs_read+0x17b/0x7c0 [<000000004aeee8ed>] ksys_read+0xed/0x1c0 [<0000000063d3d898>] do_syscall_64+0x3b/0x90 [<00000000a06dda7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd iter->fmt alloced in tracing_read_pipe() -> .. ->trace_iter_expand_forma
da7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd iter->fmt alloced in tracing_read_pipe() -> .. ->trace_iter_expand_format(), but not freed, to fix, add free in tracing_release_pipe() References: - https://git.kernel.org/stable/c/2c21ee020ce43d744ecd7f3e9bddfcaafef270ce - https://git.kernel.org/stable/c/a7d3f8f33c113478737bc61bb32ec5f9a987da7d - https://git.kernel.org/stable/c/649e72070cbbb8600eb823833e4748f5a0815116
CVE ID: CVE-2022-49802 State: PUBLISHED Published: 2025-05-01T14:09:30.308Z Last Updated: 2025-05-04T08:45:39.803Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix null pointer dereference in ftrace_add_mod() The @ftrace_mod is allocated by kzalloc(), so both the members {prev,next} of @ftrace_mode->list are NULL, it's not a valid state to call list_del(). If kstrdup() for @ftrace_mod->{func|module} fails, it goes to @out_free tag and calls free_ftrace_mod() to destroy @ftrace_mod, then list_del() will write prev->next and next->prev, where null pointer dereference happens. BUG: kernel NULL pointer dereference, addres
ll write prev->next and next->prev, where null pointer dereference happens. BUG: kernel NULL pointer dereference, address: 0000000000000008 Oops: 0002 [#1] PREEMPT SMP NOPTI Call Trace: <TASK> ftrace_mod_callback+0x20d/0x220 ? do_filp_open+0xd9/0x140 ftrace_process_regex.isra.51+0xbf/0x130 ftrace_regex_write.isra.52.part.53+0x6e/0x90 vfs_write+0xee/0x3a0 ? __audit_filter_op+0xb1/0x100 ? auditd_test_task+0x38/0x50 ksys_write+0xa5/0xe0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Kernel panic - not syncing: Fatal exception So call INIT_LIST_HEAD() to initialize the list member to fix this issue. References: - https://git.kernel.org/stable/c/665b4c6648bf2b91f69b33817f4321cf4
alize the list member to fix this issue. References: - https://git.kernel.org/stable/c/665b4c6648bf2b91f69b33817f4321cf4c3cafe9 - https://git.kernel.org/stable/c/b5bfc61f541d3f092b13dedcfe000d86eb8e133c - https://git.kernel.org/stable/c/f715f31559b82e3f75ce047fa476de63d8107584 - https://git.kernel.org/stable/c/6a14828caddad0d989495a72af678adf60992704 - https://git.kernel.org/stable/c/1bea037a1abb23a6729bef36a2265a4565f5ea77 - https://git.kernel.org/stable/c/6e50eb4b1807017f6c2d5089064256ce2de8aef1 - https://git.kernel.org/stable/c/19ba6c8af9382c4c05dc6a0a79af3013b9a35cd0
CVE ID: CVE-2022-49803 State: PUBLISHED Published: 2025-05-01T14:09:30.971Z Last Updated: 2025-05-04T08:45:40.908Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netdevsim: Fix memory leak of nsim_dev->fa_cookie kmemleak reports this issue: unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007a
210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove() The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove(). References: - https://git.kernel.org/stable/c/207edad5717e0a5709ce8467f0eff41c607835c9 - https://git.kernel.org/stable/c/064bc7312bd09a48798418663090be0c776183
able/c/207edad5717e0a5709ce8467f0eff41c607835c9 - https://git.kernel.org/stable/c/064bc7312bd09a48798418663090be0c776183db
CVE ID: CVE-2022-49804 State: PUBLISHED Published: 2025-05-01T14:09:31.590Z Last Updated: 2025-05-04T08:45:42.406Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: s390: avoid using global register for current_stack_pointer Commit 30de14b1884b ("s390: current_stack_pointer shouldn't be a function") made current_stack_pointer a global register variable like on many other architectures. Unfortunately on s390 it uncovers old gcc bug which is fixed only since gcc-9.1 [gcc commit 3ad7fed1cc87 ("S/390: Fix PR89775. Stackpointer save/restore instructions removed")] and backported to gcc-8.4 and later. Due to this bug gcc versions prior
ackpointer save/restore instructions removed")] and backported to gcc-8.4 and later. Due to this bug gcc versions prior to 8.4 generate broken code which leads to stack corruptions. Current minimal gcc version required to build the kernel is declared as 5.1. It is not possible to fix all old gcc versions, so work around this problem by avoiding using global register variable for current_stack_pointer. References: - https://git.kernel.org/stable/c/a478952a8ac44e32316dc046a063a7dc34825aa6 - https://git.kernel.org/stable/c/e3c11025bcd2142a61abe5806b2f86a0e78118df
CVE ID: CVE-2022-49805 State: PUBLISHED Published: 2025-05-01T14:09:32.227Z Last Updated: 2025-05-04T08:45:43.623Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: lan966x: Fix potential null-ptr-deref in lan966x_stats_init() lan966x_stats_init() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: lan966x_stats_init() create_singlethread_workqueue() # failed, lan966x->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value a
ueue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL. References: - https://git.kernel.org/stable/c/4a43c1c6040e848e1344c7b16ac696b68fbc439c - https://git.kernel.org/stable/c/ba86af3733aece88dbcee0dfebf7e2dcfefb2be4
CVE ID: CVE-2022-49806 State: PUBLISHED Published: 2025-05-01T14:09:32.854Z Last Updated: 2025-05-04T08:45:44.756Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: microchip: sparx5: Fix potential null-ptr-deref in sparx_stats_init() and sparx5_start() sparx_stats_init() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: sparx_stats_init() create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref
_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL. So as sparx5_start(). References: - https://git.kernel.org/stable/c/80e590aeb132887102c3fa79d99b338f099dc952 - https://git.kernel.org/stable/c/456327e565dc49d18b2f595f39f47df8a36f1057 - https://git.kernel.org/stable/c/639f5d006e36bb303f525d9479448c412b720c39
CVE ID: CVE-2022-49807 State: PUBLISHED Published: 2025-05-01T14:09:33.492Z Last Updated: 2025-05-04T08:45:46.011Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a memory leak in nvmet_auth_set_key When changing dhchap secrets we need to release the old secrets as well. kmemleak complaint: -- unreferenced object 0xffff8c7f44ed8180 (size 64): comm "check", pid 7304, jiffies 4295686133 (age 72034.246s) hex dump (first 32 bytes): 44 48 48 43 2d 31 3a 30 30 3a 4c 64 4c 4f 64 71 DHHC-1:00:LdLOdq 79 56 69 67 77 48 55 32 6d 5a 59 4c 7a 35 59 38 yVigwHU2mZYLz5Y8 backtrace: [<00000000b6fc5071>] kstrdup+0x2e/0x60 [<00000000f0f
67 77 48 55 32 6d 5a 59 4c 7a 35 59 38 yVigwHU2mZYLz5Y8 backtrace: [<00000000b6fc5071>] kstrdup+0x2e/0x60 [<00000000f0f4633f>] 0xffffffffc0e07ee6 [<0000000053006c05>] 0xffffffffc0dff783 [<00000000419ae922>] configfs_write_iter+0xb1/0x120 [<000000008183c424>] vfs_write+0x2be/0x3c0 [<000000009005a2a5>] ksys_write+0x5f/0xe0 [<00000000cd495c89>] do_syscall_64+0x38/0x90 [<00000000f2a84ac5>] entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/65710ea51d4a185592c7b14c9e33d0c4a364f074 - https://git.kernel.org/stable/c/0a52566279b4ee65ecd2503d7b7342851f84755c
CVE ID: CVE-2022-49808 State: PUBLISHED Published: 2025-05-01T14:09:34.130Z Last Updated: 2025-05-04T08:45:47.599Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: dsa: don't leak tagger-owned storage on switch driver unbind In the initial commit dc452a471dba ("net: dsa: introduce tagger-owned storage for private and shared data"), we had a call to tag_ops->disconnect(dst) issued from dsa_tree_free(), which is called at tree teardown time. There were problems with connecting to a switch tree as a whole, so this got reworked to connecting to individual switches within the tree. In this process, tag_ops->disconnect(ds) was mad
this got reworked to connecting to individual switches within the tree. In this process, tag_ops->disconnect(ds) was made to be called only from switch.c (cross-chip notifiers emitted as a result of dynamic tag proto changes), but the normal driver teardown code path wasn't replaced with anything. Solve this problem by adding a function that does the opposite of dsa_switch_setup_tag_protocol(), which is called from the equivalent spot in dsa_switch_teardown(). The positioning here also ensures that we won't have any use-after-free in tagging protocol (*rcv) ops, since the teardown sequence is as follows: dsa_tree_teardown -> dsa_tree_teardown_master -> dsa_master_teardown -> unsets master->d
eardown sequence is as follows: dsa_tree_teardown -> dsa_tree_teardown_master -> dsa_master_teardown -> unsets master->dsa_ptr, making no further packets match the ETH_P_XDSA packet type handler -> dsa_tree_teardown_ports -> dsa_port_teardown -> dsa_slave_destroy -> unregisters DSA net devices, there is even a synchronize_net() in unregister_netdevice_many() -> dsa_tree_teardown_switches -> dsa_switch_teardown -> dsa_switch_teardown_tag_protocol -> finally frees the tagger-owned storage References: - https://git.kernel.org/stable/c/5809fb03942dbac25144db5bebea84fa003ecaca - https://git.kernel.org/stable/c/4e0c19fcb8b5323716140fa82b79aa9f60e60407
CVE ID: CVE-2022-49809 State: PUBLISHED Published: 2025-05-01T14:09:34.853Z Last Updated: 2025-05-04T12:45:15.015Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix skb leak in x25_lapb_receive_frame() x25_lapb_receive_frame() using skb_copy() to get a private copy of skb, the new skb should be freed in the undersized/fragmented skb error handling path. Otherwise there is a memory leak. References: - https://git.kernel.org/stable/c/fda0ba7c84b46d10947c687320804b9de149a921 - https://git.kernel.org/stable/c/dfcfbe4f2e4b2c81cff4e79b48502d97fda73118 - https://git.kernel.org/stable/c/0ef17d966445358a55c5f4ccf2c73cca3e39192
ble/c/dfcfbe4f2e4b2c81cff4e79b48502d97fda73118 - https://git.kernel.org/stable/c/0ef17d966445358a55c5f4ccf2c73cca3e39192b - https://git.kernel.org/stable/c/e109b41870db995cae25dfaf0cc3922f9028b1a1 - https://git.kernel.org/stable/c/9f00da9c866d506998bf0a3f699ec900730472da - https://git.kernel.org/stable/c/c8baf1fc248b2e88642f094fea9509a9bf98c5bb - https://git.kernel.org/stable/c/2d675be16a461310d738d93f9f1a00da62055c5a - https://git.kernel.org/stable/c/2929cceb2fcf0ded7182562e4888afafece82cce
CVE ID: CVE-2022-49810 State: PUBLISHED Published: 2025-05-01T14:09:35.470Z Last Updated: 2025-05-04T08:45:49.863Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing xas_retry() calls in xarray iteration netfslib has a number of places in which it performs iteration of an xarray whilst being under the RCU read lock. It *should* call xas_retry() as the first thing inside of the loop and do "continue" if it returns true in case the xarray walker passed out a special value indicating that the walk needs to be redone from the root[*]. Fix this by adding the missing retry checks. [*] I wonder if this should be done in
needs to be redone from the root[*]. Fix this by adding the missing retry checks. [*] I wonder if this should be done inside xas_find(), xas_next_node() and suchlike, but I'm told that's not an simple change to effect. This can cause an oops like that below. Note the faulting address - this is an internal value (|0x2) returned from xarray. BUG: kernel NULL pointer dereference, address: 0000000000000402 ... RIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs] ... Call Trace: netfs_rreq_assess+0xa6/0x240 [netfs] netfs_readpage+0x173/0x3b0 [netfs] ? init_wait_var_entry+0x50/0x50 filemap_read_page+0x33/0xf0 filemap_get_pages+0x2f2/0x3f0 filemap_read+0xaa/0x320 ? do_filp_open+0xb2/0x150 ? rmqueue+0x3be
emap_read_page+0x33/0xf0 filemap_get_pages+0x2f2/0x3f0 filemap_read+0xaa/0x320 ? do_filp_open+0xb2/0x150 ? rmqueue+0x3be/0xe10 ceph_read_iter+0x1fe/0x680 [ceph] ? new_sync_read+0x115/0x1a0 new_sync_read+0x115/0x1a0 vfs_read+0xf3/0x180 ksys_read+0x5f/0xe0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Changes: ======== ver #2) - Changed an unsigned int to a size_t to reduce the likelihood of an overflow as per Willy's suggestion. - Added an additional patch to fix the maths. References: - https://git.kernel.org/stable/c/b2cc07a76f1eb12de3b22caf5fdbf856a7bef16d - https://git.kernel.org/stable/c/7e043a80b5dae5c2d2cf84031501de7827fd6c00
CVE ID: CVE-2022-49811 State: PUBLISHED Published: 2025-05-01T14:09:36.098Z Last Updated: 2025-05-04T08:45:51.308Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drbd: use after free in drbd_create_device() The drbd_destroy_connection() frees the "connection" so use the _safe() iterator to prevent a use after free. References: - https://git.kernel.org/stable/c/fc1897f16ebcfd22364f2afcc27f53a740f3bc7a - https://git.kernel.org/stable/c/bf47ca1b35fc1f55091ffaff5fbe41ea0c6f59a1 - https://git.kernel.org/stable/c/813a8dd9c45fd46f5cbbfbedf0791afa7740ccf5 - https://git.kernel.org/stable/c/9ed51414aef6e59e832e2960f10766dce2d5b1a1 - http
3a8dd9c45fd46f5cbbfbedf0791afa7740ccf5 - https://git.kernel.org/stable/c/9ed51414aef6e59e832e2960f10766dce2d5b1a1 - https://git.kernel.org/stable/c/7d93417d596402ddd46bd76c721f205d09d0d025 - https://git.kernel.org/stable/c/c2a00b149836d60c222930bbea6b2139caf34d4f - https://git.kernel.org/stable/c/a7a1598189228b5007369a9622ccdf587be0730f
CVE ID: CVE-2022-49812 State: PUBLISHED Published: 2025-05-01T14:09:36.741Z Last Updated: 2025-05-04T08:45:52.554Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bridge: switchdev: Fix memory leaks when changing VLAN protocol The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag. To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag. W
ge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag. When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol. In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver
nge (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted. Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev. [1] unreferenced object 0xffff8881f6771200 (size 256): comm "ip", pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_
0 00 00 00 00 00 00 ................ backtrace: [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_sys
<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 References: - https://git.kernel.org/stable/c/347f1793b573466424c550f2748ed837b6690fe7 - https://git.kernel.org/stable/c/fc16a2c81a3eb1cbba8775f5bdc67856df903a7c - https://git.kernel.org/stable/c/f8926e2d2225eb7b7e11cd3fa266aaad9075b767 - https://git.kernel.org/stable/c/9d45921ee4cb364910097e7d1b7558559c2f9fd2
CVE ID: CVE-2022-49813 State: PUBLISHED Published: 2025-05-01T14:09:37.787Z Last Updated: 2025-05-04T08:45:53.648Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ena: Fix error handling in ena_init() The ena_init() won't destroy workqueue created by create_singlethread_workqueue() when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak. References: - https://git.kernel.org/stable/c/6b23a4b252044e4fd23438930d452244818d7000 - https://git.kernel.org/stable/c/3f7b2ef8fe924e299bc339811ea3f1b9935c040f - https://git.kernel.org/stable/c/0e2369223b174d198ec42a3ec0a7
nel.org/stable/c/3f7b2ef8fe924e299bc339811ea3f1b9935c040f - https://git.kernel.org/stable/c/0e2369223b174d198ec42a3ec0a7f06c8727b968 - https://git.kernel.org/stable/c/d349e9be5a2c2d7588a2c4e4bfa0bb3dc1226769
CVE ID: CVE-2022-49814 State: PUBLISHED Published: 2025-05-01T14:09:38.389Z Last Updated: 2025-05-04T08:45:54.817Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kcm: close race conditions on sk_receive_queue sk->sk_receive_queue is protected by skb queue lock, but for KCM sockets its RX path takes mux->rx_lock to protect more than just skb queue. However, kcm_recvmsg() still only grabs the skb queue lock, so race conditions still exist. We can teach kcm_recvmsg() to grab mux->rx_lock too but this would introduce a potential performance regression as struct kcm_mux can be shared by multiple KCM sockets. So we have to enforce sk