Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
er when kmalloc() fail to allocate. So directly return ENOMEM, if kasprintf() return NULL pointer. References: - https://git.kernel.org/stable/c/aaf552c5d53abe4659176e099575fe870d2e4768 - https://git.kernel.org/stable/c/b4d9f55cd38435358bc16d580612bc0d798d7b4c - https://git.kernel.org/stable/c/a988dcd3dd9e691c5ccc3324b209688f3b5453e9 - https://git.kernel.org/stable/c/040f726fecd88121f3b95e70369785ad452dddf9 - https://git.kernel.org/stable/c/777430aa4ddccaa5accec6db90ffc1d47f00d471 - https://git.kernel.org/stable/c/97e5b508e96176f1a73888ed89df396d7041bfcb - https://git.kernel.org/stable/c/5834a3a98cd266ad35a229923c0adbd0addc8d68 - https://git.kernel.org/stable/c/91d5c5060ee24fe8da88cd585bb43b
l.org/stable/c/5834a3a98cd266ad35a229923c0adbd0addc8d68 - https://git.kernel.org/stable/c/91d5c5060ee24fe8da88cd585bb43b843d2f0dce
CVE ID: CVE-2022-49833 State: PUBLISHED Published: 2025-05-01T14:09:51.387Z Last Updated: 2025-05-20T14:35:37.685Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: clone zoned device info when cloning a device When cloning a btrfs_device, we're not cloning the associated btrfs_zoned_device_info structure of the device in case of a zoned filesystem. Later on this leads to a NULL pointer dereference when accessing the device's zone_info for instance when setting a zone as active. This was uncovered by fstests' testcase btrfs/161. References: - https://git.kernel.org/stable/c/ad88cabcec942c033f980cd1e28d56ecdaf5f3b8 -
y fstests' testcase btrfs/161. References: - https://git.kernel.org/stable/c/ad88cabcec942c033f980cd1e28d56ecdaf5f3b8 - https://git.kernel.org/stable/c/21e61ec6d0bb786818490e926aa9aeb4de95ad0d
CVE ID: CVE-2022-49834 State: PUBLISHED Published: 2025-05-01T14:09:52.076Z Last Updated: 2025-05-04T08:46:30.738Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix use-after-free bug of ns_writer on remount If a nilfs2 filesystem is downgraded to read-only due to metadata corruption on disk and is remounted read/write, or if emergency read-only remount is performed, detaching a log writer and synchronizing the filesystem can be done at the same time. In these cases, use-after-free of the log writer (hereinafter nilfs->ns_writer) can happen as shown in the scenario below: Task1 Task2 -------------------------------- --
hereinafter nilfs->ns_writer) can happen as shown in the scenario below: Task1 Task2 -------------------------------- ------------------------------ nilfs_construct_segment nilfs_segctor_sync init_wait init_waitqueue_entry add_wait_queue schedule nilfs_remount (R/W remount case) nilfs_attach_log_writer nilfs_detach_log_writer nilfs_segctor_destroy kfree finish_wait _raw_spin_lock_irqsave __raw_spin_lock_irqsave do_raw_spin_lock debug_spin_lock_before <-- use-after-free While Task1 is sleeping, nilfs->ns_writer is freed by Task2. After Task1 waked up, Task1 accesses nilfs->ns_writer which is already freed. This scenario diagram is based on the Shigeru Yoshida's post [1]. This patch fixes the
s_writer which is already freed. This scenario diagram is based on the Shigeru Yoshida's post [1]. This patch fixes the issue by not detaching nilfs->ns_writer on remount so that this UAF race doesn't happen. Along with this change, this patch also inserts a few necessary read-only checks with superblock instance where only the ns_writer pointer was used to check if the filesystem is read-only. References: - https://git.kernel.org/stable/c/b2fbf10040216ef5ee270773755fc2f5da65b749 - https://git.kernel.org/stable/c/39a3ed68270b079c6b874d4e4727a512b9b4882c - https://git.kernel.org/stable/c/b4736ab5542112fe0a40f140a0a0b072954f34da - https://git.kernel.org/stable/c/9b162e81045266a2d5b44df9dffdf05
.org/stable/c/b4736ab5542112fe0a40f140a0a0b072954f34da - https://git.kernel.org/stable/c/9b162e81045266a2d5b44df9dffdf05c54de9cca - https://git.kernel.org/stable/c/4feedde5486c07ea79787839153a71ca71329c7d - https://git.kernel.org/stable/c/afbd1188382a75f6cfe22c0b68533f7f9664f182 - https://git.kernel.org/stable/c/b152300d5a1ba4258dacf9916bff20e6a8c7603b - https://git.kernel.org/stable/c/8cccf05fe857a18ee26e20d11a8455a73ffd4efd
CVE ID: CVE-2022-49835 State: PUBLISHED Published: 2025-05-01T14:09:52.700Z Last Updated: 2025-05-04T08:46:32.274Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: fix potential memleak in 'add_widget_node' As 'kobject_add' may allocated memory for 'kobject->name' when return error. And in this function, if call 'kobject_add' failed didn't free kobject. So call 'kobject_put' to recycling resources. References: - https://git.kernel.org/stable/c/b688a3ec235222d9a84e43a48a6f31acb95baf2d - https://git.kernel.org/stable/c/bb0ac8d5e541224f599bc8e8f31a313faa4bf7b7 - https://git.kernel.org/stable/c/90b7d055e2b5f39429f9a9e3815b
nel.org/stable/c/bb0ac8d5e541224f599bc8e8f31a313faa4bf7b7 - https://git.kernel.org/stable/c/90b7d055e2b5f39429f9a9e3815b48a48530ef28 - https://git.kernel.org/stable/c/02dea987ec1cac712c78e75d224ceb9bb73519ed - https://git.kernel.org/stable/c/3a79f9568de08657fcdbc41d6fc4c0ca145a7a2b - https://git.kernel.org/stable/c/7140d7aaf93da6a665b454f91bb4dc6b1de218bd - https://git.kernel.org/stable/c/455d99bd6baf19688048b6d42d9fa74eae27f93b - https://git.kernel.org/stable/c/9a5523f72bd2b0d66eef3d58810c6eb7b5ffc143
CVE ID: CVE-2022-49836 State: PUBLISHED Published: 2025-05-01T14:09:53.454Z Last Updated: 2025-05-04T08:46:33.471Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: siox: fix possible memory leak in siox_device_add() If device_register() returns error in siox_device_add(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(), and sdevice is freed in siox_device_release(), set it to null in error path. References: - https://git.kernel.org/sta
), and sdevice is freed in siox_device_release(), set it to null in error path. References: - https://git.kernel.org/stable/c/0a5da069603ecc3d7aa09167450235462adaa295 - https://git.kernel.org/stable/c/f9fe7ba4ea5b24ffdf8e125f660aca3ba4a147fb - https://git.kernel.org/stable/c/a4b5423f88a17a36550ae8c16c46779b1ee42f4b - https://git.kernel.org/stable/c/5d03c2911c529ea4d6ebfec53425f1091e8d402b - https://git.kernel.org/stable/c/d9c31e728843259209fb530c59995e4fe262699f - https://git.kernel.org/stable/c/6e63153db50059fb78b8a8447b132664887d24e3
CVE ID: CVE-2022-49837 State: PUBLISHED Published: 2025-05-01T14:09:54.141Z Last Updated: 2025-10-01T17:02:27.099Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix memory leaks in __check_func_call kmemleak reports this issue: unreferenced object 0xffff88817139d000 (size 2048): comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 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: [<0000000045f075f0>] kmalloc_trace+0x27/0xa0 [<0000000098b7c90a>] __check_func_call+0x316/0x1230 [<00000000b4c3c403
ace: [<0000000045f075f0>] kmalloc_trace+0x27/0xa0 [<0000000098b7c90a>] __check_func_call+0x316/0x1230 [<00000000b4c3c403>] check_helper_call+0x172e/0x4700 [<00000000aa3875b7>] do_check+0x21d8/0x45e0 [<000000001147357b>] do_check_common+0x767/0xaf0 [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0 [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940 [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650 [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0 [<00000000946ee250>] do_syscall_64+0x3b/0x90 [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The root case here is: In function prepare_func_exit(), the callee is not released in the abnormal scenario after "state->curframe--;". To fix, move "state->curfra
func_exit(), the callee is not released in the abnormal scenario after "state->curframe--;". To fix, move "state->curframe--;" to the very bottom of the function, right when we free callee and reset frame[] pointer to NULL, as Andrii suggested. In addition, function __check_func_call() has a similar problem. In the abnormal scenario before "state->curframe++;", the callee also should be released by free_func_state(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d4944497827a3d14bc5a26dbcfb7433eb5a956c0 - https://git.kernel.org/stable/c/83946d772e756734a900ef99dbe0aeda506adf37 - https://git.kernel.org/stable/c/eb86559a691cea5fa63e57a03ec3dc9c
org/stable/c/83946d772e756734a900ef99dbe0aeda506adf37 - https://git.kernel.org/stable/c/eb86559a691cea5fa63e57a03ec3dc9c31e97955
CVE ID: CVE-2022-49838 State: PUBLISHED Published: 2025-05-01T14:09:54.816Z Last Updated: 2025-05-04T08:46:36.160Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sctp: clear out_curr if all frag chunks of current msg are pruned A crash was reported by Zhen Chen: list_del corruption, ffffa035ddf01c18->next is NULL WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0 RIP: 0010:__list_del_entry_valid+0x59/0xe0 Call Trace: sctp_sched_dequeue_common+0x17/0x70 [sctp] sctp_sched_fcfs_dequeue+0x37/0x50 [sctp] sctp_outq_flush_data+0x85/0x360 [sctp] sctp_outq_uncork+0x77/0xa0 [sctp] sctp_cmd_interpreter.con
queue+0x37/0x50 [sctp] sctp_outq_flush_data+0x85/0x360 [sctp] sctp_outq_uncork+0x77/0xa0 [sctp] sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp] sctp_side_effects+0x37/0xe0 [sctp] sctp_do_sm+0xd0/0x230 [sctp] sctp_primitive_SEND+0x2f/0x40 [sctp] sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp] sctp_sendmsg+0x3d5/0x440 [sctp] sock_sendmsg+0x5b/0x70 and in sctp_sched_fcfs_dequeue() it dequeued a chunk from stream out_curr outq while this outq was empty. Normally stream->out_curr must be set to NULL once all frag chunks of current msg are dequeued, as we can see in sctp_sched_dequeue_done(). However, in sctp_prsctp_prune_unsent() as it is not a proper dequeue, sctp_sched_dequeue_done() is not called
ue_done(). However, in sctp_prsctp_prune_unsent() as it is not a proper dequeue, sctp_sched_dequeue_done() is not called to do this. This patch is to fix it by simply setting out_curr to NULL when the last frag chunk of current msg is dequeued from out_curr stream in sctp_prsctp_prune_unsent(). References: - https://git.kernel.org/stable/c/e27458b18b35caee4b27b37a4a9c503b93cae5cc - https://git.kernel.org/stable/c/2ea600b598dd3e061854dd4dd5b4c815397dfcea - https://git.kernel.org/stable/c/3eff34e01062ec08fbb45ce2baaaa644550be821 - https://git.kernel.org/stable/c/2f201ae14ae0f91dbf1cffea7bb1e29e81d4d108
CVE ID: CVE-2022-49839 State: PUBLISHED Published: 2025-05-01T14:09:55.599Z Last Updated: 2025-10-01T17:01:20.900Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_transport_sas: Fix error handling in sas_phy_add() If transport_add_device() fails in sas_phy_add(), the kernel will crash trying to delete the device in transport_remove_device() called from sas_remove_host(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x54/0x3d0 l
ainted: G W 6.1.0-rc1+ #173 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x54/0x3d0 lr : device_del+0x37c/0x3d0 Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_phy_delete+0x30/0x60 [scsi_transport_sas] do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x40/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] hisi_sas_remove+0x40/0x68 [hisi_sas_main] hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw] platform_remove+0x2c/0x60 Fix this by chec
emove+0x40/0x68 [hisi_sas_main] hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw] platform_remove+0x2c/0x60 Fix this by checking and handling return value of transport_add_device() in sas_phy_add(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/03aabcb88aeeb7221ddb6196ae84ad5fb17b743f - https://git.kernel.org/stable/c/2f21d653c648735657e23948b1d7ac7273de0f87 - https://git.kernel.org/stable/c/c736876ee294bb4f271d76a25cc7d70c8537bc5d - https://git.kernel.org/stable/c/5d7bebf2dfb0dc97aac1fbace0910e557ecdb16f
CVE ID: CVE-2022-49840 State: PUBLISHED Published: 2025-05-01T14:09:56.233Z Last Updated: 2025-10-01T17:01:08.580Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb() We got a syzkaller problem because of aarch64 alignment fault if KFENCE enabled. When the size from user bpf program is an odd number, like 399, 407, etc, it will cause the struct skb_shared_info's unaligned access. As seen below: BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include
0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_
f_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_
bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381 To fix the problem, we adjust @size so that (@size + @hearoom) is a multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info is aligned to a cache line. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/047824a730699c6c66df43306b80f700c9dfc2fd - https://git.kernel.org/stable/c/730fb1ef974a13915bc7651364d8b3318891cd70 - https://git.kernel.org/stable/c/7a704dbfd3735304e261f2
it.kernel.org/stable/c/730fb1ef974a13915bc7651364d8b3318891cd70 - https://git.kernel.org/stable/c/7a704dbfd3735304e261f2787c52fbc7c3884736 - https://git.kernel.org/stable/c/e60f37a1d379c821c17b08f366412dce9ef3d99f - https://git.kernel.org/stable/c/eaa8edd86514afac9deb9bf9a5053e74f37edf40 - https://git.kernel.org/stable/c/1b597f2d6a55e9f549989913860ad5170da04964 - https://git.kernel.org/stable/c/d3fd203f36d46aa29600a72d57a1b61af80e4a25
CVE ID: CVE-2022-49841 State: PUBLISHED Published: 2025-05-01T14:09:56.980Z Last Updated: 2025-05-04T08:46:40.165Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: serial: imx: Add missing .thaw_noirq hook The following warning is seen with non-console UART instance when system hibernates. [ 37.371969] ------------[ cut here ]------------ [ 37.376599] uart3_root_clk already disabled [ 37.380810] WARNING: CPU: 0 PID: 296 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0 ... [ 37.506986] Call trace: [ 37.509432] clk_core_disable+0xa4/0xb0 [ 37.513270] clk_disable+0x34/0x50 [ 37.516672] imx_uart_thaw+0x38/0x5c [ 37.520250] platfor
clk_core_disable+0xa4/0xb0 [ 37.513270] clk_disable+0x34/0x50 [ 37.516672] imx_uart_thaw+0x38/0x5c [ 37.520250] platform_pm_thaw+0x30/0x6c [ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4 [ 37.528972] device_resume+0x7c/0x160 [ 37.532633] dpm_resume+0xe8/0x230 [ 37.536036] hibernation_snapshot+0x288/0x430 [ 37.540397] hibernate+0x10c/0x2e0 [ 37.543798] state_store+0xc4/0xd0 [ 37.547203] kobj_attr_store+0x1c/0x30 [ 37.550953] sysfs_kf_write+0x48/0x60 [ 37.554619] kernfs_fop_write_iter+0x118/0x1ac [ 37.559063] new_sync_write+0xe8/0x184 [ 37.562812] vfs_write+0x230/0x290 [ 37.566214] ksys_write+0x68/0xf4 [ 37.569529] __arm64_sys_write+0x20/0x2c [ 37.573452] invoke_syscall.constprop.0+0x50/0
37.566214] ksys_write+0x68/0xf4 [ 37.569529] __arm64_sys_write+0x20/0x2c [ 37.573452] invoke_syscall.constprop.0+0x50/0xf0 [ 37.578156] do_el0_svc+0x11c/0x150 [ 37.581648] el0_svc+0x30/0x140 [ 37.584792] el0t_64_sync_handler+0xe8/0xf0 [ 37.588976] el0t_64_sync+0x1a0/0x1a4 [ 37.592639] ---[ end trace 56e22eec54676d75 ]--- On hibernating, pm core calls into related hooks in sequence like: .freeze .freeze_noirq .thaw_noirq .thaw With .thaw_noirq hook being absent, the clock will be disabled in a unbalanced call which results the warning above. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_thaw clk_disable_unprepare() Adding the missing .thaw_noirq hook
able() imx_uart_suspend_noirq() clk_disable() imx_uart_thaw clk_disable_unprepare() Adding the missing .thaw_noirq hook as imx_uart_resume_noirq() will have the call sequence corrected as below and thus fix the warning. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_resume_noirq() clk_enable() imx_uart_thaw clk_disable_unprepare() References: - https://git.kernel.org/stable/c/e401312ca6e180ee1bd65f6a766e99dd40aa95e7 - https://git.kernel.org/stable/c/476b09e07bd519ec7ba5941a6a6f9a02256dbb21 - https://git.kernel.org/stable/c/0a3160f4ffc70ee4bfa1521f698dace06e6091fd - https://git.kernel.org/stable/c/ae22294e213a402a70fa1731538367d1b758ffe7 - https://git.k
70ee4bfa1521f698dace06e6091fd - https://git.kernel.org/stable/c/ae22294e213a402a70fa1731538367d1b758ffe7 - https://git.kernel.org/stable/c/e3f9d87d6f0732827c443bd1474df21c2fad704b - https://git.kernel.org/stable/c/4561d8008a467cb05ac632a215391d6b787f40aa
CVE ID: CVE-2022-49842 State: PUBLISHED Published: 2025-05-01T14:09:57.711Z Last Updated: 2025-10-01T17:00:56.212Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: core: Fix use-after-free in snd_soc_exit() KASAN reports a use-after-free: BUG: KASAN: use-after-free in device_del+0xb5b/0xc60 Read of size 8 at addr ffff888008655050 by task rmmod/387 CPU: 2 PID: 387 Comm: rmmod Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl+0x79/0x9a print_report+0x17f/0x47b kasan_report+0xbb/0xf0 device_del+0xb5b/0xc60 platform_device_del.part.0+0x24/0x200 platform_device_unregister+0x2e/0x40 snd_soc_e
rt+0xbb/0xf0 device_del+0xb5b/0xc60 platform_device_del.part.0+0x24/0x200 platform_device_unregister+0x2e/0x40 snd_soc_exit+0xa/0x22 [snd_soc_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK> It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail, but its ret is ignored, which makes soc_dummy_dev unregistered twice. snd_soc_init() snd_soc_util_init() platform_device_register_simple(soc_dummy_dev) platform_driver_register() # fail platform_device_unregister(soc_dummy_dev) platform_driver_register() # success ... snd_soc_exit() snd_soc_util_exit() # soc_dummy_dev will be unregistered for second time
_driver_register() # success ... snd_soc_exit() snd_soc_util_exit() # soc_dummy_dev will be unregistered for second time To fix it, handle error and stop snd_soc_init() when util_init() fail. Also clean debugfs when util_init() or driver_register() fail. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/41fad4f712e081acdfde8b59847f9f66eaf407a0 - https://git.kernel.org/stable/c/90bbdf30a51e42378cb23a312005a022794b8e1e - https://git.kernel.org/stable/c/a3365e62239dc064019a244bde5686ac18527c22 - https://git.kernel.org/stable/c/2ec3f558db343b045a7c7419cdbaec266b8ac1a7 - https://git.kernel.org/stable/c/8d21554ec7680e9585fb852d933203c3db60dad1 - https
3f558db343b045a7c7419cdbaec266b8ac1a7 - https://git.kernel.org/stable/c/8d21554ec7680e9585fb852d933203c3db60dad1 - https://git.kernel.org/stable/c/34eee4189bcebbd5f6a2ff25ef0cb893ad33d51e - https://git.kernel.org/stable/c/c5674bd073c0fd9f620ca550c5ff08d0d429bdd9 - https://git.kernel.org/stable/c/6ec27c53886c8963729885bcf2dd996eba2767a7
CVE ID: CVE-2022-49843 State: REJECTED Published: 2025-05-01T14:09:58.333Z Last Updated: 2025-05-08T10:23:22.012Z Description: No description available.
CVE ID: CVE-2022-49844 State: PUBLISHED Published: 2025-05-01T14:09:58.999Z Last Updated: 2025-10-01T17:00:34.409Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: dev: fix skb drop check In commit a6d190f8c767 ("can: skb: drop tx skb if in listen only mode") the priv->ctrlmode element is read even on virtual CAN interfaces that do not create the struct can_priv at startup. This out-of-bounds read may lead to CAN frame drops for virtual CAN interfaces like vcan and vxcan. This patch mainly reverts the original commit and adds a new helper for CAN interface drivers that provide the required information in struct can_priv. [mk
nal commit and adds a new helper for CAN interface drivers that provide the required information in struct can_priv. [mkl: patch pch_can, too] Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/386c49fe31ee748e053860b3bac7794a933ac9ac - https://git.kernel.org/stable/c/ae64438be1923e3c1102d90fd41db7afcfaf54cc
CVE ID: CVE-2022-49845 State: PUBLISHED Published: 2025-05-01T14:09:59.718Z Last Updated: 2025-10-01T17:00:17.827Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_send_one(): fix missing CAN header initialization The read access to struct canxl_frame::len inside of a j1939 created skbuff revealed a missing initialization of reserved and later filled elements in struct can_frame. This patch initializes the 8 byte CAN header with zero. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d0513b095e1ef1469718564dec3fb3348556d0a8 - https://git.kernel.org/stable/c/f8e0edea
s: - https://git.kernel.org/stable/c/d0513b095e1ef1469718564dec3fb3348556d0a8 - https://git.kernel.org/stable/c/f8e0edeaa0f2b860bdbbf0aafb4492533043d650 - https://git.kernel.org/stable/c/69e86c6268d59ceddd0abe9ae8f1f5296f316c3c - https://git.kernel.org/stable/c/2719f82ad5d8199cf5f346ea8bb3998ad5323b72 - https://git.kernel.org/stable/c/3eb3d283e8579a22b81dd2ac3987b77465b2a22f