Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
xa8/0x200 [ib_core] ib_mr_pool_destroy+0x77/0xb0 [ib_core] nvme_rdma_destroy_queue_ib+0x89/0x240 [nvme_rdma] nvme_rdma_free_queue+0x40/0x50 [nvme_rdma] nvme_rdma_teardown_io_queues.part.0+0xc3/0x120 [nvme_rdma] nvme_rdma_error_recovery_work+0x4d/0xf0 [nvme_rdma] process_one_work+0x582/0xa40 ? pwq_dec_nr_in_flight+0x100/0x100 ? rwlock_bug.part.0+0x60/0x60 worker_thread+0x2a9/0x700 ? process_one_work+0xa40/0xa40 kthread+0x168/0x1a0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 References: - https://git.kernel.org/stable/c/50b35ad2864a9d66f802f9ce193d99bbef64e219 - https://git.kernel.org/stable/c/b5f9a01fae42684648c2ee3cd9985f80c67ab9f7
CVE ID: CVE-2022-49930 State: PUBLISHED Published: 2025-05-01T14:11:07.408Z Last Updated: 2025-10-01T14:56:06.644Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix NULL pointer problem in free_mr_init() Lock grab occurs in a concurrent scenario, resulting in stepping on a NULL pointer. It should be init mutex_init() first before use the lock. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __mutex_lock.constprop.0+0xd0/0x5c0 __mutex_lock_slowpath+0x1c/0x2c mutex_lock+0x44/0x50 free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2] hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_
c/0x2c mutex_lock+0x44/0x50 free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2] hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2] hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2] ib_dereg_mr_user+0x54/0x124 uverbs_free_mr+0x24/0x30 destroy_hw_idr_uobject+0x38/0x74 uverbs_destroy_uobject+0x48/0x1c4 uobj_destroy+0x74/0xcc ib_uverbs_cmd_verbs+0x368/0xbb0 ib_uverbs_ioctl+0xec/0x1a4 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x190 do_el0_svc+0x30/0x90 el0_svc+0x2c/0xb4 el0t_64_sync_handler+0x1a4/0x1b0 el0t_64_sync+0x19c/0x1a0 Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0e23e85d86b78e734dd6654f1b69fbaeb5534c
yst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0e23e85d86b78e734dd6654f1b69fbaeb5534c81 - https://git.kernel.org/stable/c/12bcaf87d8b66d8cd812479c8a6349dcb245375c
CVE ID: CVE-2022-49931 State: PUBLISHED Published: 2025-05-01T14:11:08.135Z Last Updated: 2025-10-01T14:55:40.268Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Correctly move list in sc_disable() Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash. The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen: BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hf
pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hfi1] handle_freeze+0x27/0x1b0 [hfi1] process_one_work+0x1b0/0x380 ? process_one_work+0x380/0x380 worker_thread+0x30/0x360 ? process_one_work+0x380/0x380 kthread+0xd7/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 The fix is to use the correct call to move the list. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/25760a41e3802f54aadcc31385543665ab349b8e - https://git.kernel.org/stable/c/7c4260f8f188df32414a5ecad63e8b934c2aa3f0 - https://git.kernel.org/stable/c/ba95409d6b580501ff6d78efd00064f7df669926 - http
4260f8f188df32414a5ecad63e8b934c2aa3f0 - https://git.kernel.org/stable/c/ba95409d6b580501ff6d78efd00064f7df669926 - https://git.kernel.org/stable/c/b8bcff99b07cc175a6ee12a52db51cdd2229586c - https://git.kernel.org/stable/c/1afac08b39d85437187bb2a92d89a741b1078f55
CVE ID: CVE-2022-49932 State: PUBLISHED Published: 2025-05-02T15:54:53.215Z Last Updated: 2025-05-04T08:49:08.670Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace Call kvm_init() only after _all_ setup is complete, as kvm_init() exposes /dev/kvm to userspace and thus allows userspace to create VMs (and call other ioctls). E.g. KVM will encounter a NULL pointer when attempting to add a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able to create a VM before vmx_init() configures said list. BUG: kernel NULL pointer dereference, address: 00000000
e is able to create a VM before vmx_init() configures said list. BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 6 PID: 1143 Comm: stable Not tainted 6.0.0-rc7+ #988 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:vmx_vcpu_load_vmcs+0x68/0x230 [kvm_intel] <TASK> vmx_vcpu_load+0x16/0x60 [kvm_intel] kvm_arch_vcpu_load+0x32/0x1f0 [kvm] vcpu_load+0x2f/0x40 [kvm] kvm_arch_vcpu_create+0x231/0x310 [kvm] kvm_vm_ioctl+0x79f/0xe10 [kvm] ? handle_mm_fault+0xb1/0x220 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x2b/0x50 entry_SYSCALL_
vm_ioctl+0x79f/0xe10 [kvm] ? handle_mm_fault+0xb1/0x220 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x2b/0x50 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f5a6b05743b </TASK> Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel(+) kvm irqbypass References: - https://git.kernel.org/stable/c/e136e969d268b9b89329c816c002e53f60e82985 - https://git.kernel.org/stable/c/e28533c08023c4b319b7f2cd77f3f7c9204eb517 - https://git.kernel.org/stable/c/e32b120071ea114efc0b4ddd439547750b85f618
CVE ID: CVE-2022-49933 State: REJECTED Published: 2025-05-02T15:54:54.060Z Last Updated: 2025-05-20T13:59:14.308Z Description: No description available.
CVE ID: CVE-2022-49934 State: PUBLISHED Published: 2025-06-18T10:54:36.161Z Last Updated: 2025-07-15T15:43:39.598Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix UAF in ieee80211_scan_rx() ieee80211_scan_rx() tries to access scan_req->flags after a null check, but a UAF is observed when the scan is completed and __ieee80211_scan_completed() executes, which then calls cfg80211_scan_done() leading to the freeing of scan_req. Since scan_req is rcu_dereference()'d, prevent the racing in __ieee80211_scan_completed() by ensuring that from mac80211's POV it is no longer accessed from an RCU read critical section be
0211_scan_completed() by ensuring that from mac80211's POV it is no longer accessed from an RCU read critical section before we call cfg80211_scan_done(). References: - https://git.kernel.org/stable/c/6eb181a64fdabf10be9e54de728876667da20255 - https://git.kernel.org/stable/c/e0ff39448cea654843744c72c6780293c5082cb1 - https://git.kernel.org/stable/c/78a07732fbb0934d14827d8f09b9aa6a49ee1aa9 - https://git.kernel.org/stable/c/9ad48cbf8b07f10c1e4a7a262b32a9179ae9dd2d - https://git.kernel.org/stable/c/4abc8c07a065ecf771827bde3c63fbbe4aa0c08b - https://git.kernel.org/stable/c/5d20c6f932f2758078d0454729129c894fe353e7 - https://git.kernel.org/stable/c/c0445feb80a4d0854898118fa01073701f8d356b - https:
c6f932f2758078d0454729129c894fe353e7 - https://git.kernel.org/stable/c/c0445feb80a4d0854898118fa01073701f8d356b - https://git.kernel.org/stable/c/60deb9f10eec5c6a20252ed36238b55d8b614a2c
CVE ID: CVE-2022-49935 State: PUBLISHED Published: 2025-06-18T10:54:36.963Z Last Updated: 2025-09-03T12:58:58.435Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dma-buf/dma-resv: check if the new fence is really later Previously when we added a fence to a dma_resv object we always assumed the the newer than all the existing fences. With Jason's work to add an UAPI to explicit export/import that's not necessary the case any more. So without this check we would allow userspace to force the kernel into an use after free error. Since the change is very small and defensive it's probably a good idea to backport this to stable kernel
ter free error. Since the change is very small and defensive it's probably a good idea to backport this to stable kernels as well just in case others are using the dma_resv object in the same way. References: - https://git.kernel.org/stable/c/c4c798fe98adceb642050819cb57cbc8f5c27870 - https://git.kernel.org/stable/c/a3f7c10a269d5b77dd5822ade822643ced3057f0
CVE ID: CVE-2022-49936 State: PUBLISHED Published: 2025-06-18T10:54:37.889Z Last Updated: 2025-06-18T10:54:37.889Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: USB: core: Prevent nested device-reset calls Automatic kernel fuzzing revealed a recursive locking violation in usb-storage: ============================================ WARNING: possible recursive locking detected 5.18.0 #3 Not tainted -------------------------------------------- kworker/1:3/1205 is trying to acquire lock: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 but task is already holding loc
face_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 but task is already holding lock: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 ... stack backtrace: CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2988 [inline] check_deadlock kernel/locking/lockdep.c:3031 [inline] validate_chain kernel/locking/lockdep.c:38
lockdep.c:2988 [inline] check_deadlock kernel/locking/lockdep.c:3031 [inline] validate_chain kernel/locking/lockdep.c:3816 [inline] __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053 lock_acquire kernel/locking/lockdep.c:5665 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630 __mutex_lock_common kernel/locking/mutex.c:603 [inline] __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747 usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109 r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622 usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458 device_remove drivers/base/dd.c:545 [inlin
usb_intf.c:622 usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458 device_remove drivers/base/dd.c:545 [inline] device_remove+0x11f/0x170 drivers/base/dd.c:537 __device_release_driver drivers/base/dd.c:1222 [inline] device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248 usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627 usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118 usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114 This turned out not to be an error in usb-storage but rather a nested device reset attempt. That is, as the rtl8712 driver was being unbound from a composite device in preparation for an unrelated USB reset (that dr
t is, as the rtl8712 driver was being unbound from a composite device in preparation for an unrelated USB reset (that driver does not have pre_reset or post_reset callbacks), its ->remove routine called usb_reset_device() -- thus nesting one reset call within another. Performing a reset as part of disconnect processing is a questionable practice at best. However, the bug report points out that the USB core does not have any protection against nested resets. Adding a reset_in_progress flag and testing it will prevent such errors in the future. References: - https://git.kernel.org/stable/c/d90419b8b8322b6924f6da9da952647f2dadc21b - https://git.kernel.org/stable/c/1b29498669914c7f9afb6197224214
l.org/stable/c/d90419b8b8322b6924f6da9da952647f2dadc21b - https://git.kernel.org/stable/c/1b29498669914c7f9afb619722421418a753d372 - https://git.kernel.org/stable/c/cc9a12e12808af178c600cc485338bac2e37d2a8 - https://git.kernel.org/stable/c/df1875084898b15cbc42f712e93d7f113ae6271b - https://git.kernel.org/stable/c/abe3cfb7a7c8e907b312c7dbd7bf4d142b745aa8 - https://git.kernel.org/stable/c/c548b99e1c37db6f7df86ecfe9a1f895d6c5966e - https://git.kernel.org/stable/c/d5eb850b3e8836197a38475840725260b9783e94 - https://git.kernel.org/stable/c/9c6d778800b921bde3bff3cff5003d1650f942d1
CVE ID: CVE-2022-49937 State: PUBLISHED Published: 2025-06-18T10:54:38.812Z Last Updated: 2025-06-18T10:54:38.812Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: mceusb: Use new usb_control_msg_*() routines Automatic kernel fuzzing led to a WARN about invalid pipe direction in the mceusb driver: ------------[ cut here ]------------ usb 6-1: BOGUS control dir, pipe 80000380 doesn't match bRequestType 40 WARNING: CPU: 0 PID: 2465 at drivers/usb/core/urb.c:410 usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410 Modules linked in: CPU: 0 PID: 2465 Comm: kworker/0:2 Not tainted 5.19.0-rc4-00208-g69cb6c6556ad #1 Hardware n
urb.c:410 Modules linked in: CPU: 0 PID: 2465 Comm: kworker/0:2 Not tainted 5.19.0-rc4-00208-g69cb6c6556ad #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410 Code: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 <0f> 0b e9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 ff 41 RSP: 0018:ffffc900032becf0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000 RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90 RBP: ffff888105ad90f0 R08:
3058 RCX: 0000000000000000 RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90 RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 0000000000000000 R10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000 R13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0 Call Trace: <TASK> usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 mceusb_gen1_in
ol_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 mceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline] mceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807 The reason for the warning is clear enough; the driver sends an unusual read request on endpoint 0 but does not set the USB_DIR_IN bit in the bRequestType field. More importantly, the whole situation can be avoided and the driver simplified by converting it over to the relatively new usb_control_msg_recv() and usb_control_msg_send() routines. That's what this fix does. References: - https://git.kernel.org/stable/c/587f793c64d99d92be8ef01c4c69d885a3f2edb6 - https://git.ke
t this fix does. References: - https://git.kernel.org/stable/c/587f793c64d99d92be8ef01c4c69d885a3f2edb6 - https://git.kernel.org/stable/c/75913c562f5ba4cf397d835c63f443879167c6f6 - https://git.kernel.org/stable/c/d69c738ac9310b56e84c51c8f09fc018a8291bc6 - https://git.kernel.org/stable/c/608e58a0f4617977178131f5f68a3fce1d3f5316
CVE ID: CVE-2022-49938 State: PUBLISHED Published: 2025-06-18T10:54:39.458Z Last Updated: 2025-06-18T10:54:39.458Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cifs: fix small mempool leak in SMB2_negotiate() In some cases of failure (dialect mismatches) in SMB2_negotiate(), after the request is sent, the checks would return -EIO when they should be rather setting rc = -EIO and jumping to neg_exit to free the response buffer from mempool. References: - https://git.kernel.org/stable/c/9e3c9efa7caf16e5acc05eab5e4d0a714e1610b0 - https://git.kernel.org/stable/c/38a6b469bf22f153282fbe7d702a24e9eb43f50e - https://git.kernel.org/sta
5e4d0a714e1610b0 - https://git.kernel.org/stable/c/38a6b469bf22f153282fbe7d702a24e9eb43f50e - https://git.kernel.org/stable/c/27893dfc1285f80f80f46b3b8c95f5d15d2e66d0
CVE ID: CVE-2022-49939 State: PUBLISHED Published: 2025-06-18T10:54:40.100Z Last Updated: 2025-06-18T10:54:40.100Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF of ref->proc caused by race condition A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the reference for a node. In this case, the target proc normally releases the failed reference upon close as expected. However, if the target is dying in parallel the call will race with binder_deferred_release(), so the target could have released all of its references by now leaving the cleanup of the new failed reference unhandled. The transaction
ld have released all of its references by now leaving the cleanup of the new failed reference unhandled. The transaction then ends and the target proc gets released making the ref->proc now a dangling pointer. Later on, ref->node is closed and we attempt to take spin_lock(&ref->proc->inner_lock), which leads to the use-after-free bug reported below. Let's fix this by cleaning up the failed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-r
Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20 References: - https://git.kernel.org/stable/c/229f47603dd306bc0eb1a831439adb8e48bb0eae - https://git.kernel.org/stable/c/06e5b43ca4dab06a92b
//git.kernel.org/stable/c/229f47603dd306bc0eb1a831439adb8e48bb0eae - https://git.kernel.org/stable/c/06e5b43ca4dab06a92bf4c2f33766e6fb11b880a - https://git.kernel.org/stable/c/30d0901b307f27d36b2655fb3048cf31ee0e89c0 - https://git.kernel.org/stable/c/9629f2dfdb1dad294b468038ff8e161e94d0b609 - https://git.kernel.org/stable/c/c2a4b5dc8fa71af73bab704d0cac42ac39767ed6 - https://git.kernel.org/stable/c/603a47f2ae56bf68288784d3c0a8c5b8e0a827ed - https://git.kernel.org/stable/c/a0e44c64b6061dda7e00b7c458e4523e2331b739
CVE ID: CVE-2022-49940 State: PUBLISHED Published: 2025-06-18T10:54:40.745Z Last Updated: 2025-06-18T10:54:40.745Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: add sanity check for gsm->receive in gsm_receive_buf() A null pointer dereference can happen when attempting to access the "gsm->receive()" function in gsmld_receive_buf(). Currently, the code assumes that gsm->recieve is only called after MUX activation. Since the gsmld_receive_buf() function can be accessed without the need to initialize the MUX, the gsm->receive() function will not be set and a NULL pointer dereference will occur. Fix this by avoiding th
the MUX, the gsm->receive() function will not be set and a NULL pointer dereference will occur. Fix this by avoiding the call to "gsm->receive()" in case the function is not initialized by adding a sanity check. Call Trace: <TASK> gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861 tiocsti drivers/tty/tty_io.c:2293 [inline] tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://gi
ne] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/5a82cf64f8ad63caf6bf115642ce44ddbc64311e - https://git.kernel.org/stable/c/309aea4b6b813f6678c3a547cfd7fe3a76ffa976 - https://git.kernel.org/stable/c/5aa37f9510345a812c0998bcbbc4d88d1dcc4d8b - https://git.kernel.org/stable/c/f16c6d2e58a4c2b972efcf9eb12390ee0ba3befb
CVE ID: CVE-2022-49941 State: REJECTED Published: 2025-06-18T10:54:41.683Z Last Updated: 2025-06-18T14:19:35.780Z Description: No description available.
CVE ID: CVE-2022-49942 State: PUBLISHED Published: 2025-06-18T10:59:57.610Z Last Updated: 2025-06-18T10:59:57.610Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Don't finalize CSA in IBSS mode if state is disconnected When we are not connected to a channel, sending channel "switch" announcement doesn't make any sense. The BSS list is empty in that case. This causes the for loop in cfg80211_get_bss() to be bypassed, so the function returns NULL (check line 1424 of net/wireless/scan.c), causing the WARN_ON() in ieee80211_ibss_csa_beacon() to get triggered (check line 500 of net/mac80211/ibss.c), which was consequ
the WARN_ON() in ieee80211_ibss_csa_beacon() to get triggered (check line 500 of net/mac80211/ibss.c), which was consequently reported on the syzkaller dashboard. Thus, check if we have an existing connection before generating the CSA beacon in ieee80211_ibss_finish_csa(). References: - https://git.kernel.org/stable/c/cdb9a8da9b84800eb15506cd9363cf0cf059e677 - https://git.kernel.org/stable/c/1691a48aef0a82d1754b9853dae7e3f5cacdf70b - https://git.kernel.org/stable/c/d9eb37db6a28b59a95a3461450ee209654c5f95b - https://git.kernel.org/stable/c/66689c5c02acd4d76c28498fe220998610aec61e - https://git.kernel.org/stable/c/dd649b49219a0388cc10fc40e4c2ea681566a780 - https://git.kernel.org/stable/c/552ba
ec61e - https://git.kernel.org/stable/c/dd649b49219a0388cc10fc40e4c2ea681566a780 - https://git.kernel.org/stable/c/552ba102a6898630a7d16887f29e606d6fabe508 - https://git.kernel.org/stable/c/864e280cb3a9a0f5212b16ef5057c4e692f7039d - https://git.kernel.org/stable/c/15bc8966b6d3a5b9bfe4c9facfa02f2b69b1e5f0
CVE ID: CVE-2022-49943 State: PUBLISHED Published: 2025-06-18T10:59:58.516Z Last Updated: 2025-06-18T10:59:58.516Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: USB: gadget: Fix obscure lockdep violation for udc_mutex A recent commit expanding the scope of the udc_lock mutex in the gadget core managed to cause an obscure and slightly bizarre lockdep violation. In abbreviated form: ====================================================== WARNING: possible circular locking dependency detected 5.19.0-rc7+ #12510 Not tainted ------------------------------------------------------ udevadm/312 is trying to acquire lock: ffff80000aae105
ot tainted ------------------------------------------------------ udevadm/312 is trying to acquire lock: ffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0 but task is already holding lock: ffff000002277548 (kn->active#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kn->active#4){++++}-{0:0}: lock_acquire+0x68/0x84 __kernfs_remove+0x268/0x380 kernfs_remove_by_name_ns+0x58/0xac sysfs_remove_file_ns+0x18/0x24 device_del+0x15c/0x440 -> #2 (device_links_lock){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 device_link_remove+0x3c/0xa0 _