Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
_attach+0xb2/0x1e0 [ 71.986195] bus_probe_device+0x92/0xb0 [ 71.986198] device_add+0x422/0x9a0 [ 71.986201] ? sysfs_merge_group+0xd4/0x110 [ 71.986205] usb_set_configuration+0x57a/0x820 [ 71.986208] usb_generic_driver_probe+0x4f/0x70 [ 71.986211] usb_probe_device+0x3a/0x110 [ 71.986213] really_probe+0xdb/0x380 [ 71.986216] ? pm_runtime_barrier+0x54/0x90 [ 71.986219] __driver_probe_device+0x78/0x170 [ 71.986221] driver_probe_device+0x1f/0x90 [ 71.986224] __device_attach_driver+0x89/0x110 [ 71.986227] ? driver_allows_async_probing+0x70/0x70 [ 71.986230] bus_for_each_drv+0x8c/0xe0 [ 71.986232] __device_attach+0xb2/0x1e0 [ 71.986235] bus_probe_device+0x92/0xb0 [ 71.986237] device_add+0x422/0x9a0
0xe0 [ 71.986232] __device_attach+0xb2/0x1e0 [ 71.986235] bus_probe_device+0x92/0xb0 [ 71.986237] device_add+0x422/0x9a0 [ 71.986239] ? _dev_info+0x7d/0x98 [ 71.986242] ? blake2s_update+0x4c/0xc0 [ 71.986246] usb_new_device.cold+0x148/0x36d [ 71.986250] hub_event+0xa8a/0x1910 [ 71.986255] process_one_work+0x1c4/0x380 [ 71.986259] worker_thread+0x51/0x390 [ 71.986262] ? rescuer_thread+0x3b0/0x3b0 [ 71.986264] kthread+0xdb/0x110 [ 71.986266] ? kthread_complete_and_exit+0x20/0x20 [ 71.986268] ret_from_fork+0x1f/0x30 [ 71.986273] </TASK> [ 71.986274] ---[ end trace 0000000000000000 ]--- [ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17 Additional Analyst Notes: - CISA ADP Vulnrichment
0000 ]--- [ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17 Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/dc8fa6570deadb70c3fb74d7cd8ce38849feaed0 - https://git.kernel.org/stable/c/b5ca338751ad4783ec8d37b5d99c3e37b7813e59
CVE ID: CVE-2022-48983 State: PUBLISHED Published: 2024-10-21T20:06:00.376Z Last Updated: 2025-05-04T08:27:29.355Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring: Fix a null-ptr-deref in io_tctx_exit_cb() Syzkaller reports a NULL deref bug as follows: BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3 Read of size 4 at addr 0000000000000138 by task file1/1955 CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 ? io_tctx_exit_cb+0x53/0xd3 kasan_report+0xbb/0x1f0 ? i
.0-2.el7 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 ? io_tctx_exit_cb+0x53/0xd3 kasan_report+0xbb/0x1f0 ? io_tctx_exit_cb+0x53/0xd3 kasan_check_range+0x140/0x190 io_tctx_exit_cb+0x53/0xd3 task_work_run+0x164/0x250 ? task_work_cancel+0x30/0x30 get_signal+0x1c3/0x2440 ? lock_downgrade+0x6e0/0x6e0 ? lock_downgrade+0x6e0/0x6e0 ? exit_signals+0x8b0/0x8b0 ? do_raw_read_unlock+0x3b/0x70 ? do_raw_spin_unlock+0x50/0x230 arch_do_signal_or_restart+0x82/0x2470 ? kmem_cache_free+0x260/0x4b0 ? putname+0xfe/0x140 ? get_sigframe_size+0x10/0x10 ? do_execveat_common.isra.0+0x226/0x710 ? lockdep_hardirqs_on+0x79/0x100 ? putname+0xfe/0x140 ? do_execveat_common.isra.0+0x238/0x710 exit_to_user_mode_p
/0x710 ? lockdep_hardirqs_on+0x79/0x100 ? putname+0xfe/0x140 ? do_execveat_common.isra.0+0x238/0x710 exit_to_user_mode_prepare+0x15f/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0023:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 000
0 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Kernel panic - not syncing: panic_on_warn set ... This happens because the adding of task_work from io_ring_exit_work() isn't synchronized with canceling all work items from eg exec. The execution of the two are ordered in that they are both run by the task itself, but if io_tctx_exit_cb() is queued while we're canceling all work items off exec AND gets executed when the task exits to userspace rather than in the main loop in io_uring_cancel_generic(), then we can find current->io_uring == NULL and hit the above crash. It's safe to add this NULL check
_cancel_generic(), then we can find current->io_uring == NULL and hit the above crash. It's safe to add this NULL check here, because the execution of the two paths are done by the task itself. [axboe: add code comment and also put an explanation in the commit msg] Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f895511de9d27fff71dad2c234ad53b4afd2b06c - https://git.kernel.org/stable/c/d91edca1943453aaaba4f380f6f364346222e5cf - https://git.kernel.org/stable/c/998b30c3948e4d0b1097e639918c5cff332acac5
CVE ID: CVE-2022-48984 State: PUBLISHED Published: 2024-10-21T20:06:01.083Z Last Updated: 2025-05-04T08:27:30.729Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: slcan: fix freed work crash The LTP test pty03 is causing a crash in slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0
mbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (events) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d6
X: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Call Trace: <TASK> worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:
kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312) Apparently, the slcan's tx_work is freed while being scheduled. While slcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work), slcan_close() (tty side) does not. So when the netdev is never set UP, but the tty is stuffed with bytes and forced to wakeup write, the work is scheduled, but never flushed. So add an additional flush_work() to slcan_close() to be sure the work is flushed under all circumstances. The Fixes commit below moved flush_work() from slcan_close() to slcan_netdev_close(). What was the rationale behind it? Maybe we can drop the one in slcan_n
ork() from slcan_close() to slcan_netdev_close(). What was the rationale behind it? Maybe we can drop the one in slcan_netdev_close()? I see the same pattern in can327. So it perhaps needs the very same fix. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/9e2709d58a14a10eb00d919acd7dec071c33f8c8 - https://git.kernel.org/stable/c/fb855e9f3b6b42c72af3f1eb0b288998fe0d5ebb
CVE ID: CVE-2022-48985 State: PUBLISHED Published: 2024-10-21T20:06:01.802Z Last Updated: 2025-05-04T08:27:31.814Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix race on per-CQ variable napi work_done After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be cleared, and another CPU can start napi thread and access per-CQ variable, cq->work_done. If the other thread (for example, from busy_poll) sets it to a value >= budget, this thread will continue to run when it should stop, and cause memory corruption and panic. To fix this issue, save the per-CQ work_done variable in a local variable before napi_c
use memory corruption and panic. To fix this issue, save the per-CQ work_done variable in a local variable before napi_complete_done(), so it won't be corrupted by a possible concurrent thread after napi_complete_done(). Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done variable race is fixed, so the driver is able to reliably support features like busy_poll. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/fe50a9bbeb1f042e756c5cfa7708112c944368de - https://git.kernel.org/stable/c/6740d8572ccd1bca50d8a1ca2bedc333f50ed5f3 - https://git.kernel.org/stable/c/18010ff776fa42340efc428b3ea6d19b3e7c7b21
CVE ID: CVE-2022-48986 State: PUBLISHED Published: 2024-10-21T20:06:02.502Z Last Updated: 2025-05-04T12:44:08.677Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix gup_pud_range() for dax For dax pud, pud_huge() returns true on x86. So the function works as long as hugetlb is configured. However, dax doesn't depend on hugetlb. Commit 414fd080d125 ("mm/gup: fix gup_pmd_range() for dax") fixed devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as well. This fixes the below kernel panic: general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP < snip > Call Trace: <TA
ic: general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP < snip > Call Trace: <TASK> get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ? mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ? bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ? filemap_range_has_page+0x82/0xc0 generic_file_direct_write+0x9d/0x1a0 ? inode_update_time+0x24/0x30 __generic_file_write_iter+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340 io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0
io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100 __x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ? irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be < snip > </TASK> ---[ end trace 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 < snip > Kernel panic - not syncing: Fatal exception Kernel Offset: disabled Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c
Kernel Offset: disabled Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/04edfa3dc06ecfc6133a33bc7271298782dee875 - https://git.kernel.org/stable/c/f1cf856123ceb766c49967ec79b841030fa1741f - https://git.kernel.org/stable/c/3ac29732a2ffa64c7de13a072b0f2848b9c11037 - https://git.kernel.org/stable/c/e06d13c36ded750c72521b600293befebb4e56c5 - https://git.kernel.org/stable/c/fcd0ccd836ffad73d98a66f6fea7b16f735ea920
CVE ID: CVE-2022-48987 State: PUBLISHED Published: 2024-10-21T20:06:03.328Z Last Updated: 2025-05-04T08:27:34.560Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: v4l2-dv-timings.c: fix too strict blanking sanity checks Sanity checks were added to verify the v4l2_bt_timings blanking fields in order to avoid integer overflows when userspace passes weird values. But that assumed that userspace would correctly fill in the front porch, backporch and sync values, but sometimes all you know is the total blanking, which is then assigned to just one of these fields. And that can fail with these checks. So instead set a maximum fo
ng, which is then assigned to just one of these fields. And that can fail with these checks. So instead set a maximum for the total horizontal and vertical blanking and check that each field remains below that. That is still sufficient to avoid integer overflows, but it also allows for more flexibility in how userspace fills in these fields. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0d73b49c4037199472b29574ae21c21aef493971 - https://git.kernel.org/stable/c/a2b56627c0d13009e02f6f2c0206c0451ed19a0e - https://git.kernel.org/stable/c/2572ab14b73aa45b6ae7e4c089ccf119fed5cf89 - https://git.kernel.org/stable/c/4afc77068e36cee45b39d4fdc7513de269
g/stable/c/2572ab14b73aa45b6ae7e4c089ccf119fed5cf89 - https://git.kernel.org/stable/c/4afc77068e36cee45b39d4fdc7513de26980f72c - https://git.kernel.org/stable/c/32f01f0306a98629508f84d7ef0d1d037bc274a2 - https://git.kernel.org/stable/c/6fb8bc29bfa80707994a63cc97e2f9920e0b0608 - https://git.kernel.org/stable/c/d3d14cdf1c7ae2caa3e999bae95ba99e955fb7c3 - https://git.kernel.org/stable/c/5eef2141776da02772c44ec406d6871a790761ee
CVE ID: CVE-2022-48988 State: PUBLISHED Published: 2024-10-21T20:06:04.601Z Last Updated: 2025-05-04T08:27:35.599Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: memcg: fix possible use-after-free in memcg_write_event_control() memcg_write_event_control() accesses the dentry->d_name of the specified control fd to route the write call. As a cgroup interface file can't be renamed, it's safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can't be removed before the directory, it's safe to access the parent too. Prior to 347c4a874710 ("memcg: remove cgroup_event->cft")
oved before the directory, it's safe to access the parent too. Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free's. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file oper
esurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let's check the superblock and dentry type. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b77600e26fd48727a95ffd50ba1e937efb548125 - https://git.kernel.org/stable/c/e1ae97624ecf400ea56c238bff23e5cd139df0b8 - https://git.kernel.org/stable/c/35963b31821920908e397146502066f6b032c917 - https://git.kernel.org/stable/c/f1f7f36cf682fa59db15e2089039a2eeb58ff2ad - https://git.kernel.org/stable/c/aad8bbd17a1d586005feb9226c2e9cfce1432e13 - https://git.kernel.org/stable/c/0ed0
8ff2ad - https://git.kernel.org/stable/c/aad8bbd17a1d586005feb9226c2e9cfce1432e13 - https://git.kernel.org/stable/c/0ed074317b835caa6c03bcfa8f133365324673dc - https://git.kernel.org/stable/c/4a7ba45b1a435e7097ca0f79a847d0949d0eb088
CVE ID: CVE-2022-48989 State: PUBLISHED Published: 2024-10-21T20:06:05.854Z Last Updated: 2025-05-04T08:27:36.668Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fscache: Fix oops due to race with cookie_lru and use_cookie If a cookie expires from the LRU and the LRU_DISCARD flag is set, but the state machine has not run yet, it's possible another thread can call fscache_use_cookie and begin to use it. When the cookie_worker finally runs, it will see the LRU_DISCARD flag set, transition the cookie->state to LRU_DISCARDING, which will then withdraw the cookie. Once the cookie is withdrawn the object is removed the below oops wil
U_DISCARDING, which will then withdraw the cookie. Once the cookie is withdrawn the object is removed the below oops will occur because the object associated with the cookie is now NULL. Fix the oops by clearing the LRU_DISCARD bit if another thread uses the cookie before the cookie_worker runs. BUG: kernel NULL pointer dereference, address: 0000000000000008 ... CPU: 31 PID: 44773 Comm: kworker/u130:1 Tainted: G E 6.0.0-5.dneg.x86_64 #1 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Workqueue: events_unbound netfs_rreq_write_to_cache_work [netfs] RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... Call Trace: netfs_rreq_write_to_cache_work+0x11c/
[netfs] RIP: 0010:cachefiles_prepare_write+0x28/0x90 [cachefiles] ... Call Trace: netfs_rreq_write_to_cache_work+0x11c/0x320 [netfs] process_one_work+0x217/0x3e0 worker_thread+0x4a/0x3b0 kthread+0xd6/0x100 Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/37f0b459c9b67e14fe4dcc3a15d286c4436ed01d - https://git.kernel.org/stable/c/b5b52de3214a29911f949459a79f6640969b5487
CVE ID: CVE-2022-48990 State: PUBLISHED Published: 2024-10-21T20:06:07.203Z Last Updated: 2025-05-21T08:44:02.780Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix use-after-free during gpu recovery [Why] [ 754.862560] refcount_t: underflow; use-after-free. [ 754.862898] Call Trace: [ 754.862903] <TASK> [ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu] [ 754.863543] drm_sched_main.cold+0x34/0x39 [amd_sched] [How] The fw_fence may be not init, check whether dma_fence_init is performed before job free Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d2a89cd942edd50c1
free Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d2a89cd942edd50c1e652004fd64019be78b0a96 - https://git.kernel.org/stable/c/3cb93f390453cde4d6afda1587aaa00e75e09617
CVE ID: CVE-2022-48991 State: PUBLISHED Published: 2024-10-21T20:06:08.312Z Last Updated: 2025-05-04T08:27:39.085Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs don't hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b ("khugepaged: add support of c
use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of the security impact of this only came in commit 27e1f8273113 ("khugepaged: enable collapse pmd for pte-mapped THP"), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/275c626c131cfe141beeb6c575e31fa53d32da19 - https://git.kernel.org/stable/c/c23105673228c349739e958fa33955ed8faddcaf - https://git.kernel.org/stable/c/ff2a1a6f869650aec99e9d070b5ab625bfbc5bc3 - https://git.kerne
9739e958fa33955ed8faddcaf - https://git.kernel.org/stable/c/ff2a1a6f869650aec99e9d070b5ab625bfbc5bc3 - https://git.kernel.org/stable/c/5ffc2a75534d9d74d49760f983f8eb675fa63d69 - https://git.kernel.org/stable/c/7f445ca2e0e59c7971d0b7b853465e50844ab596 - https://git.kernel.org/stable/c/1a3f8c6cd29d9078cc81b29d39d0e9ae1d6a03c3 - https://git.kernel.org/stable/c/5450535901d89a5dcca5fbbc59a24fe89caeb465 - https://git.kernel.org/stable/c/f268f6cf875f3220afc77bdd0bf1bb136eb54db9
CVE ID: CVE-2022-48992 State: PUBLISHED Published: 2024-10-21T20:06:09.495Z Last Updated: 2025-05-04T08:27:40.144Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-pcm: Add NULL check in BE reparenting Add NULL check in dpcm_be_reparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0760acc2e6598ad4f7bd3662db2d907ef0838139 - https://git.kernel.org/stable/c/d4dd21a79dbb862d2ebcf9ed90e646416009ff0d - https://git.kernel.org/stable/c/e7166d6821c15f3516bcac8ae3f155924da1908c - https://gi
9dbb862d2ebcf9ed90e646416009ff0d - https://git.kernel.org/stable/c/e7166d6821c15f3516bcac8ae3f155924da1908c - https://git.kernel.org/stable/c/f2ba66d8738584d124aff4e760ed1337f5f6dfb6 - https://git.kernel.org/stable/c/f6f45e538328df9ce66aa61bafee1a5717c4b700 - https://git.kernel.org/stable/c/9f74b9aa8d58c18927bb9b65dd5ba70a5fd61615 - https://git.kernel.org/stable/c/34a9796bf0684bfd54e96a142560d560c21c983b - https://git.kernel.org/stable/c/db8f91d424fe0ea6db337aca8bc05908bbce1498
CVE ID: CVE-2022-48993 State: REJECTED Published: 2024-10-21T20:06:10.140Z Last Updated: 2024-10-23T09:06:14.790Z Description: No description available.
CVE ID: CVE-2022-48994 State: PUBLISHED Published: 2024-10-21T20:06:10.814Z Last Updated: 2025-05-04T08:27:41.191Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not hav
ich manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b38486e82ecb9f3046e0184205f6b61408fc40c9 - https://git.kernel.org/stable/c/e385360705a0b346bdb57ce938249175d0613b8a - https://git.kernel.org/stable/c/2f46e95bf344abc4e74f8
git.kernel.org/stable/c/e385360705a0b346bdb57ce938249175d0613b8a - https://git.kernel.org/stable/c/2f46e95bf344abc4e74f8158901d32a869e0adb6 - https://git.kernel.org/stable/c/63badfed200219ca656968725f1a43df293ac936 - https://git.kernel.org/stable/c/15c42ab8d43acb73e2eba361ad05822c0af0ecfa - https://git.kernel.org/stable/c/fccd454129f6a0739651f7f58307cdb631fd6e89 - https://git.kernel.org/stable/c/13ee8fb5410b740c8dd2867d3557c7662f7dda2d - https://git.kernel.org/stable/c/05530ef7cf7c7d700f6753f058999b1b5099a026