Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
x408/0x1720 rtnetlink_rcv_msg+0x38e/0xac0 netlink_rcv_skb+0x12d/0x3a0 netlink_unicast+0x4a2/0x740 netlink_sendmsg+0x826/0xcc0 sock_sendmsg+0xc5/0x100 ____sys_sendmsg+0x583/0x690 ___sys_sendmsg+0xe8/0x160 __sys_sendmsg+0xbf/0x160 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f2164122d04 </TASK> References: - https://git.kernel.org/stable/c/ded86c4191a3c17f8200d17a7d8a6f63b74554ae - https://git.kernel.org/stable/c/c2e1e59d59fafe297779ceae1fe0e6fbebc3e745 - https://git.kernel.org/stable/c/723399af2795fb95687a531c9480464b5f489333 - https://git.kernel.org/stable/c/2a3fc78210b9f0e85372a2435368962009f480fc
CVE ID: CVE-2022-50357 State: PUBLISHED Published: 2025-09-17T14:56:09.991Z Last Updated: 2025-09-17T14:56:09.991Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: fix some leaks in probe The dwc3_get_properties() function calls: dwc->usb_psy = power_supply_get_by_name(usb_psy_name); so there is some additional clean up required on these error paths. References: - https://git.kernel.org/stable/c/79c3afb55942368921237d7b5355d48c52bdde20 - https://git.kernel.org/stable/c/3a213503f483173e7eea76f2e7e3bdd6df7fd6f8 - https://git.kernel.org/stable/c/2a735e4b5580a2a6bbd6572109b4c4f163c57462
CVE ID: CVE-2022-50358 State: PUBLISHED Published: 2025-09-17T14:56:10.688Z Last Updated: 2025-09-17T14:56:10.688Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: brcmfmac: return error when getting invalid max_flowrings from dongle When firmware hit trap at initialization, host will read abnormal max_flowrings number from dongle, and it will cause kernel panic when doing iowrite to initialize dongle ring. To detect this error at early stage, we directly return error when getting invalid max_flowrings(>256). References: - https://git.kernel.org/stable/c/3cc9299036bdb647408e11e41de3eb1ff6d428cd - https://git.kernel.org/stable/c/2
ferences: - https://git.kernel.org/stable/c/3cc9299036bdb647408e11e41de3eb1ff6d428cd - https://git.kernel.org/stable/c/2e8bb402b060a6c22160de3d72cee057698177c8 - https://git.kernel.org/stable/c/10c4b63d09a5b0ebf1b61af1dae7f25555cf58b6 - https://git.kernel.org/stable/c/87f126b25fa8562196f0f4c0aa46a446026199bf - https://git.kernel.org/stable/c/200347eb3b2608cc8b54c13dd1d5e03809ba2eb2 - https://git.kernel.org/stable/c/2aca4f3734bd717e04943ddf340d49ab62299a00
CVE ID: CVE-2022-50359 State: PUBLISHED Published: 2025-09-17T14:56:11.482Z Last Updated: 2025-09-17T14:56:11.482Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: cx88: Fix a null-ptr-deref bug in buffer_prepare() When the driver calls cx88_risc_buffer() to prepare the buffer, the function call may fail, resulting in a empty buffer and null-ptr-deref later in buffer_queue(). The following log can reveal it: [ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI [ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 41.828
[#1] PREEMPT SMP KASAN PTI [ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500 [ 41.836311] Call Trace: [ 41.836945] __enqueue_in_driver+0x141/0x360 [ 41.837262] vb2_start_streaming+0x62/0x4a0 [ 41.838216] vb2_core_streamon+0x1da/0x2c0 [ 41.838516] __vb2_init_fileio+0x981/0xbc0 [ 41.839141] __vb2_perform_fileio+0xbf9/0x1120 [ 41.840072] vb2_fop_read+0x20e/0x400 [ 41.840346] v4l2_read+0x215/0x290 [ 41.840603] vfs_read+0x162/0x4c0 Fix this by checking the return value of cx88_risc_buffer() [hverkuil: fix coding style issues] References: - https://git.kernel.org/stable/c/c76d04d2079a4b7369ce9a0e859c0f3f2250bcc1 - ht
il: fix coding style issues] References: - https://git.kernel.org/stable/c/c76d04d2079a4b7369ce9a0e859c0f3f2250bcc1 - https://git.kernel.org/stable/c/10c99d1c46ea9cd940029e17bab11d021f315c21 - https://git.kernel.org/stable/c/4befc7ffa18ef9a4b70d854465313a345a06862f - https://git.kernel.org/stable/c/9181af2dbf06e7f432e5dbe88d10b22343e851b9 - https://git.kernel.org/stable/c/c2257c8a501537afab276c306cb717b7260276e1 - https://git.kernel.org/stable/c/6f21976095c1e92454ab030976f95f40d652351b - https://git.kernel.org/stable/c/704838040f3bdb4aa07ff4f26505a666a3defcfe - https://git.kernel.org/stable/c/644d5a87ab1863eb606526ea743021752a17e9cb - https://git.kernel.org/stable/c/2b064d91440b33fba5b452f2d
kernel.org/stable/c/644d5a87ab1863eb606526ea743021752a17e9cb - https://git.kernel.org/stable/c/2b064d91440b33fba5b452f2d1b31f13ae911d71
CVE ID: CVE-2022-50360 State: PUBLISHED Published: 2025-09-17T14:56:12.260Z Last Updated: 2025-09-17T14:56:12.260Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: fix aux-bus EP lifetime Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred. This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made. For the DP aux-bus, an attempt to populate the bus a second time will simply fa
tempt to allocate the resources is made. For the DP aux-bus, an attempt to populate the bus a second time will simply fail ("DP AUX EP device already populated"). Fix this by tying the lifetime of the EP device to the DRM device rather than DP controller platform device. Patchwork: https://patchwork.freedesktop.org/patch/502672/ References: - https://git.kernel.org/stable/c/8768663188e4169333f66583e4d2432e65c421df - https://git.kernel.org/stable/c/2b57f726611e294dc4297dd48eb8c98ef1938e82
CVE ID: CVE-2022-50361 State: PUBLISHED Published: 2025-09-17T14:56:13.510Z Last Updated: 2025-09-17T14:56:13.510Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: add missing unregister_netdev() in wilc_netdev_ifc_init() Fault injection test reports this issue: kernel BUG at net/core/dev.c:10731! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI Call Trace: <TASK> wilc_netdev_ifc_init+0x19f/0x220 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5] wilc_cfg80211_init+0x30c/0x380 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5] wilc_bus_probe+0xad/0x2b0 [wilc1000_spi 1520a7539b6589cc6cde2ae826a523a33f8bacff] spi_p
9e98af6a708f266a8dffd53f99e4bf5] wilc_bus_probe+0xad/0x2b0 [wilc1000_spi 1520a7539b6589cc6cde2ae826a523a33f8bacff] spi_probe+0xe4/0x140 really_probe+0x17e/0x3f0 __driver_probe_device+0xe3/0x170 driver_probe_device+0x49/0x120 The root case here is alloc_ordered_workqueue() fails, but cfg80211_unregister_netdevice() or unregister_netdev() not be called in error handling path. To fix add unregister_netdev goto lable to add the unregister operation in error handling path. References: - https://git.kernel.org/stable/c/a1bdecedc7ad0512365267cd1a26bfc2ae455c59 - https://git.kernel.org/stable/c/6da6ce086221803ed6c3b1db11096cecd3e58ec8 - https://git.kernel.org/stable/c/2b88974ecb358990e1c33fabcd0b9e1
.org/stable/c/6da6ce086221803ed6c3b1db11096cecd3e58ec8 - https://git.kernel.org/stable/c/2b88974ecb358990e1c33fabcd0b9e142bab7f21
CVE ID: CVE-2022-50362 State: PUBLISHED Published: 2025-09-17T14:56:14.189Z Last Updated: 2025-09-17T14:56:14.189Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dmaengine: hisilicon: Add multi-thread support for a DMA channel When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 100 > /sys/module/dmatest/parameters/threads_per_chan % echo 100 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [383493.327077] Unable to handle kernel paging request at virtual address dead000000000108 [383493.335103] Mem abort info: [383493.335103]
ble to handle kernel paging request at virtual address dead000000000108 [383493.335103] Mem abort info: [383493.335103] ESR = 0x96000044 [383493.335105] EC = 0x25: DABT (current EL), IL = 32 bits [383493.335107] SET = 0, FnV = 0 [383493.335108] EA = 0, S1PTW = 0 [383493.335109] FSC = 0x04: level 0 translation fault [383493.335110] Data abort info: [383493.335111] ISV = 0, ISS = 0x00000044 [383493.364739] CM = 0, WnR = 1 [383493.367793] [dead000000000108] address between user and kernel address ranges [383493.375021] Internal error: Oops: 96000044 [#1] PREEMPT SMP [383493.437574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump: loaded Tainted: GO 5.17.0-rc4+ #2 [383493.457851] pstate: 204000c9
7574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump: loaded Tainted: GO 5.17.0-rc4+ #2 [383493.457851] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [383493.465331] pc : vchan_tx_submit+0x64/0xa0 [383493.469957] lr : vchan_tx_submit+0x34/0xa0 This occurs because the transmission timed out, and that's due to data race. Each thread rewrite channels's descriptor as soon as device_issue_pending is called. It leads to the situation that the driver thinks that it uses the right descriptor in interrupt handler while channels's descriptor has been changed by other thread. The descriptor which in fact reported interrupt will not be handled any more, as well as its tx->callback. Tha
r thread. The descriptor which in fact reported interrupt will not be handled any more, as well as its tx->callback. That's why timeout reports. With current fixes channels' descriptor changes it's value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. In case of channel's descriptor is busy, try to submit to HW again when a descriptor is completed. In this case, vc->desc_issued may be empty when hisi_dma_start_transfer is called, so delete error reporting on this. Now it is just possible to queue a descriptor for further processing. R
er is called, so delete error reporting on this. Now it is just possible to queue a descriptor for further processing. References: - https://git.kernel.org/stable/c/af12e209a9d559394d35875ba0e6c80407605888 - https://git.kernel.org/stable/c/7cb9b20941e1fb20d22d0a2f460a3d4fa417274c - https://git.kernel.org/stable/c/d4a8ec5cc7ff5d442bd49a44f26d74b2021ba4c8 - https://git.kernel.org/stable/c/f4cee0b385cd0348e071d4d80c4c13cfe547c70d - https://git.kernel.org/stable/c/2cbb95883c990d0002a77e13d3278913ab26ad79
CVE ID: CVE-2022-50363 State: PUBLISHED Published: 2025-09-17T14:56:15.047Z Last Updated: 2025-09-17T14:56:15.047Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: skmsg: pass gfp argument to alloc_sk_msg() syzbot found that alloc_sk_msg() could be called from a non sleepable context. sk_psock_verdict_recv() uses rcu_read_lock() protection. We need the callers to pass a gfp_t argument to avoid issues. syzbot report was: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 3613, name: syz-executor414 preempt_count: 0, expected: 0 RCU nest depth: 1
): 0, irqs_disabled(): 0, non_block: 0, pid: 3613, name: syz-executor414 preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 __might_resched+0x538/0x6a0 kernel/sched/core.c:9877 might_alloc include/linux/sched/mm.h:274 [inline] slab_pre_alloc_hook mm/slab.h:700 [inline] slab_alloc_node mm/slub.c:3162 [inline] slab_alloc mm/slub.c:3256 [inline] kmem_cache_alloc_trace+0x59
ab.h:700 [inline] slab_alloc_node mm/slub.c:3162 [inline] slab_alloc mm/slub.c:3256 [inline] kmem_cache_alloc_trace+0x59/0x310 mm/slub.c:3287 kmalloc include/linux/slab.h:600 [inline] kzalloc include/linux/slab.h:733 [inline] alloc_sk_msg net/core/skmsg.c:507 [inline] sk_psock_skb_ingress_self+0x5c/0x330 net/core/skmsg.c:600 sk_psock_verdict_apply+0x395/0x440 net/core/skmsg.c:1014 sk_psock_verdict_recv+0x34d/0x560 net/core/skmsg.c:1201 tcp_read_skb+0x4a1/0x790 net/ipv4/tcp.c:1770 tcp_rcv_established+0x129d/0x1a10 net/ipv4/tcp_input.c:5971 tcp_v4_do_rcv+0x479/0xac0 net/ipv4/tcp_ipv4.c:1681 sk_backlog_rcv include/net/sock.h:1109 [inline] __release_sock+0x1d8/0x4c0 net/core/sock.c:2906 release_
tcp_ipv4.c:1681 sk_backlog_rcv include/net/sock.h:1109 [inline] __release_sock+0x1d8/0x4c0 net/core/sock.c:2906 release_sock+0x5d/0x1c0 net/core/sock.c:3462 tcp_sendmsg+0x36/0x40 net/ipv4/tcp.c:1483 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] __sys_sendto+0x46d/0x5f0 net/socket.c:2117 __do_sys_sendto net/socket.c:2129 [inline] __se_sys_sendto net/socket.c:2125 [inline] __x64_sys_sendto+0xda/0xf0 net/socket.c:2125 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/693ddd6ffc05b228ea1638f9d757c5d3541f9446 - https://git
r_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/693ddd6ffc05b228ea1638f9d757c5d3541f9446 - https://git.kernel.org/stable/c/2d1f274b95c6e4ba6a813b3b8e7a1a38d54a0a08
CVE ID: CVE-2022-50364 State: PUBLISHED Published: 2025-09-17T14:56:15.753Z Last Updated: 2025-09-17T14:56:15.753Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i2c: mux: reg: check return value after calling platform_get_resource() It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. References: - https://git.kernel.org/stable/c/61df25c41b8e0d2c988ccf17139f70075a2e1ba4 - https://git.kernel.org/stable/c/8212800943997fab6
s://git.kernel.org/stable/c/61df25c41b8e0d2c988ccf17139f70075a2e1ba4 - https://git.kernel.org/stable/c/8212800943997fab61874550278d653cb378c60c - https://git.kernel.org/stable/c/f5049b3ad9446203b916ee375f30fa217735f63a - https://git.kernel.org/stable/c/f7a440c89b6d460154efeb058272760e41bdfea8 - https://git.kernel.org/stable/c/2d47b79d2bd39cc6369eccf94a06568d84c906ae
CVE ID: CVE-2022-50365 State: PUBLISHED Published: 2025-09-17T14:56:16.648Z Last Updated: 2025-09-17T14:56:16.648Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: skbuff: Account for tail adjustment during pull operations Extending the tail can have some unexpected side effects if a program uses a helper like BPF_FUNC_skb_pull_data to read partial content beyond the head skb headlen when all the skbs in the gso frag_list are linear with no head_frag - kernel BUG at net/core/skbuff.c:4219! pc : skb_segment+0xcf4/0xd2c lr : skb_segment+0x63c/0xd2c Call trace: skb_segment+0xcf4/0xd2c __udp_gso_segment+0xa4/0x544 udp4_ufo_fragment+0
/0xd2c lr : skb_segment+0x63c/0xd2c Call trace: skb_segment+0xcf4/0xd2c __udp_gso_segment+0xa4/0x544 udp4_ufo_fragment+0x184/0x1c0 inet_gso_segment+0x16c/0x3a4 skb_mac_gso_segment+0xd4/0x1b0 __skb_gso_segment+0xcc/0x12c udp_rcv_segment+0x54/0x16c udp_queue_rcv_skb+0x78/0x144 udp_unicast_rcv_skb+0x8c/0xa4 __udp4_lib_rcv+0x490/0x68c udp_rcv+0x20/0x30 ip_protocol_deliver_rcu+0x1b0/0x33c ip_local_deliver+0xd8/0x1f0 ip_rcv+0x98/0x1a4 deliver_ptype_list_skb+0x98/0x1ec __netif_receive_skb_core+0x978/0xc60 Fix this by marking these skbs as GSO_DODGY so segmentation can handle the tail updates accordingly. References: - https://git.kernel.org/stable/c/ff3743d00f41d803e6ab9334962b674f3b7fd0cb - https:
ail updates accordingly. References: - https://git.kernel.org/stable/c/ff3743d00f41d803e6ab9334962b674f3b7fd0cb - https://git.kernel.org/stable/c/6ac417d71b80e74b002313fcd73f7e9008e8e457 - https://git.kernel.org/stable/c/2d59f0ca153e9573ec4f140988c0ccca0eb4181b - https://git.kernel.org/stable/c/668dc454bcbd1da73605201ff43f988c70848215 - https://git.kernel.org/stable/c/821be5a5ab09a40ba09cb5ba354f18cf7996fea0 - https://git.kernel.org/stable/c/8fb773eed4909ef5dc1bbeb3629a337d3336df7e - https://git.kernel.org/stable/c/946dd5dc4fcc4123cdfe3942b20012c4448cf89a - https://git.kernel.org/stable/c/331615d837f4979eb91a336a223a5c7f7886ecd5 - https://git.kernel.org/stable/c/2d7afdcbc9d32423f177ee12b7c93
el.org/stable/c/331615d837f4979eb91a336a223a5c7f7886ecd5 - https://git.kernel.org/stable/c/2d7afdcbc9d32423f177ee12b7c93783aea338fb
CVE ID: CVE-2022-50366 State: PUBLISHED Published: 2025-09-17T14:56:17.441Z Last Updated: 2025-09-17T14:56:17.441Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue When value < time_unit, the parameter of ilog2() will be zero and the return value is -1. u64(-1) is too large for shift exponent and then will trigger shift-out-of-bounds: shift exponent 18446744073709551615 is too large for 32-bit type 'int' Call Trace: rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us References: - https://git.kernel.org/stable/c/42f79dbb9514f72
e_data_raw set_time_window store_constraint_time_window_us References: - https://git.kernel.org/stable/c/42f79dbb9514f726ff21df25f09cb0693b0b2445 - https://git.kernel.org/stable/c/3eb0ba70376f6ee40fa843fc9cee49269370b0b3 - https://git.kernel.org/stable/c/4ebba43384722adbd325baec3a12c572d94488eb - https://git.kernel.org/stable/c/49a6ffdaed60f0eb52c198fafebc05994e16e305 - https://git.kernel.org/stable/c/708b9abe1b4a2f050a483db4b7edfc446b13df1f - https://git.kernel.org/stable/c/139bbbd01114433b80fe59f5e1330615aadf9752 - https://git.kernel.org/stable/c/6216b685b8f48ab7b721a6fd5acbf526b41c13e8 - https://git.kernel.org/stable/c/1d94af37565e4d3c26b0d63428e093a37d5b4c32 - https://git.kernel.org/stab
acbf526b41c13e8 - https://git.kernel.org/stable/c/1d94af37565e4d3c26b0d63428e093a37d5b4c32 - https://git.kernel.org/stable/c/2d93540014387d1c73b9ccc4d7895320df66d01b
CVE ID: CVE-2022-50367 State: PUBLISHED Published: 2025-09-17T14:56:23.190Z Last Updated: 2025-09-17T14:56:23.190Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs: fix UAF/GPF bug in nilfs_mdt_destroy In alloc_inode, inode_init_always() could return -ENOMEM if security_inode_alloc() fails, which causes inode->i_private uninitialized. Then nilfs_is_metadata_file_inode() returns true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(), which frees the uninitialized inode->i_private and leads to crashes(e.g., UAF/GPF). Fix this by moving security_inode_alloc just prior to this_cpu_inc(nr_inodes) References: - https://git.ke
g., UAF/GPF). Fix this by moving security_inode_alloc just prior to this_cpu_inc(nr_inodes) References: - https://git.kernel.org/stable/c/d1ff475d7c83289d0a7faef346ea3bbf90818bad - https://git.kernel.org/stable/c/c0aa76b0f17f59dd9c9d3463550a2986a1d592e4 - https://git.kernel.org/stable/c/ec2aab115eb38ac4992ea2fcc2a02fbe7af5cf48 - https://git.kernel.org/stable/c/70e4f70d54e0225f91814e8610477d65f33cefe4 - https://git.kernel.org/stable/c/1e555c3ed1fce4b278aaebe18a64a934cece57d8 - https://git.kernel.org/stable/c/64b79e632869ad3ef6c098a4731d559381da1115 - https://git.kernel.org/stable/c/81de80330fa6907aec32eb54c5619059e6e36452 - https://git.kernel.org/stable/c/2a96b532098284ecf8e4849b8b9e5fc7a28bd
table/c/81de80330fa6907aec32eb54c5619059e6e36452 - https://git.kernel.org/stable/c/2a96b532098284ecf8e4849b8b9e5fc7a28bdee9 - https://git.kernel.org/stable/c/2e488f13755ffbb60f307e991b27024716a33b29
CVE ID: CVE-2022-50368 State: PUBLISHED Published: 2025-09-17T14:56:24.102Z Last Updated: 2025-09-17T14:56:24.102Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502668/ References: - https://git.kernel.org/stable/c/4e5587cddb334f7a5bb1c49ea8bbfc966fafe1b8 - https://git.kernel.org/stable/c/f649ed0e1b7a1545f8e27267d3c468b3cb222ece - https://git.kernel.org/stable/c/2
66fafe1b8 - https://git.kernel.org/stable/c/f649ed0e1b7a1545f8e27267d3c468b3cb222ece - https://git.kernel.org/stable/c/21c4679af01f1027cb559330c2e7d410089b2b36 - https://git.kernel.org/stable/c/9f035d1fb30648fe70ee01627eb131c56d699b35 - https://git.kernel.org/stable/c/e83b354890a3c1d5256162f87a6cc38c47ae7f20 - https://git.kernel.org/stable/c/2e786eb2f9cebb07e317226b60054df510b60c65
CVE ID: CVE-2022-50369 State: PUBLISHED Published: 2025-09-17T14:56:24.889Z Last Updated: 2025-09-17T14:56:24.889Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/vkms: Fix null-ptr-deref in vkms_release() A null-ptr-deref is triggered when it tries to destroy the workqueue in vkms->output.composer_workq in vkms_release(). KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24 RIP: 0010:destroy_workqueue+0x2f/0x710 ... Call Trace: <TASK> ? vkms_config_debugfs_init+0x50/0x50 [vkms] __devm_drm_dev_alloc+0x15a/0x1c0 [drm] vkms_init+0x245/
. Call Trace: <TASK> ? vkms_config_debugfs_init+0x50/0x50 [vkms] __devm_drm_dev_alloc+0x15a/0x1c0 [drm] vkms_init+0x245/0x1000 [vkms] do_one_initcall+0xd0/0x4f0 do_init_module+0x1a4/0x680 load_module+0x6249/0x7110 __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that an OOM happened which triggers the destroy of the workqueue, however, the workqueue is alloced in the later process, thus a null-ptr-deref happened. A simple call graph is shown as below: vkms_init() vkms_create() devm_drm_dev_alloc() __devm_drm_dev_alloc() devm_drm_dev_init() devm_add_action_or_reset() devm_add_action() # an error happened devm_drm_dev_init_release
v_alloc() devm_drm_dev_init() devm_add_action_or_reset() devm_add_action() # an error happened devm_drm_dev_init_release() drm_dev_put() kref_put() drm_dev_release() vkms_release() destroy_workqueue() # null-ptr-deref happened vkms_modeset_init() vkms_output_init() vkms_crtc_init() # where the workqueue get allocated Fix this by checking if composer_workq is NULL before passing it to the destroy_workqueue() in vkms_release(). References: - https://git.kernel.org/stable/c/0b8f390e2251191f1b179cc87f65d54c96565f0d - https://git.kernel.org/stable/c/1f9836f95271e7acf016667eee0aeae3386f9645 - https://git.kernel.org/stable/c/596f1ba3987e601e31a5abf1f75ce1d2635aceac - https://git.kernel.org/stable/c
ae3386f9645 - https://git.kernel.org/stable/c/596f1ba3987e601e31a5abf1f75ce1d2635aceac - https://git.kernel.org/stable/c/57031c474c3a920ea73afeb5dc352e537f5793ee - https://git.kernel.org/stable/c/2fe2a8f40c21161ffe7653cc234e7934db5b7cc5
CVE ID: CVE-2022-50370 State: PUBLISHED Published: 2025-09-17T14:56:26.015Z Last Updated: 2025-09-17T14:56:26.015Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i2c: designware: Fix handling of real but unexpected device interrupts Commit c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs") caused a regression on certain Gigabyte motherboards for Intel Alder Lake-S where system crashes to NULL pointer dereference in i2c_dw_xfer_msg() when system resumes from S3 sleep state ("deep"). I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made following notes: - Issue happens when resuming from S3 but not