Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
+0x1c/0x150 [bluetooth] l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth] __sys_getsockopt+0xcc/0x200 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &hdev->lock --> &chan->lock#2/1 --> sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&chan->lock#2/1); lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&hdev->lock); *** DEADLOCK *** 1 lock held by bluetoothd/1118: #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 [bluetooth] stack backtrace: CPU: 3 PID
ck-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 [bluetooth] stack backtrace: CPU: 3 PID: 1118 Comm: bluetoothd Not tainted 5.12.0-rc1-00026-g73d464503354 #10 Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017 Call Trace: dump_stack+0x7f/0xa1 check_noncircular+0x105/0x120 ? __lock_acquire+0x147a/0x1a50 __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? __lock_acquire+0x2e1/0x1a50 ? lock_is_held_type+0xb4/0x120 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] __mutex_lock+0xa3/0xa10 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? lock_acquire+0x277/0x3d0 ? mark_held_locks+0x49/0x70 ? mark_held_locks
0xa10 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? lock_acquire+0x277/0x3d0 ? mark_held_locks+0x49/0x70 ? mark_held_locks+0x49/0x70 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] hci_conn_get_phy+0x ---truncated--- Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7cc0ba67883c6c8d3bddb283f56c167fc837a555 - https://git.kernel.org/stable/c/fee71f480bc1dec5f6ae3b0b185ff12a62bceabc - https://git.kernel.org/stable/c/332e69eb3bd90370f2d9f2c2ca7974ff523dea17 - https://git.kernel.org/stable/c/17486960d79b900c45e0bb8fbcac0262848582ba
CVE ID: CVE-2021-47039 State: PUBLISHED Published: 2024-02-28T08:13:45.937Z Last Updated: 2025-05-04T07:02:48.800Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ataflop: potential out of bounds in do_format() The function uses "type" as an array index: q = unit[drive].disk[type]->queue; Unfortunately the bounds check on "type" isn't done until later in the function. Fix this by moving the bounds check to the start. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/07f86aa8f4fe077be1b018cc177eb8c6573e5671 - https://git.kernel.org/stable/c/2a3a8bbca28b899806
://git.kernel.org/stable/c/07f86aa8f4fe077be1b018cc177eb8c6573e5671 - https://git.kernel.org/stable/c/2a3a8bbca28b899806844c00d49ed1b7ccb50957 - https://git.kernel.org/stable/c/1ffec389a6431782a8a28805830b6fae9bf00af1
CVE ID: CVE-2021-47040 State: PUBLISHED Published: 2024-02-28T08:13:46.557Z Last Updated: 2025-05-04T07:02:50.136Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring: fix overflows checks in provide buffers Colin reported before possible overflow and sign extension problems in io_provide_buffers_prep(). As Linus pointed out previous attempt did nothing useful, see d81269fecb8ce ("io_uring: fix provide_buffers sign extension"). Do that with help of check_<op>_overflow helpers. And fix struct io_provide_buf::len type, as it doesn't make much sense to keep it signed. Additional Analyst Notes: - CVE Program Container: - CISA A
::len type, as it doesn't make much sense to keep it signed. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cbbc13b115b8f18e0a714d89f87fbdc499acfe2d - https://git.kernel.org/stable/c/51bf90901952aaac564bbdb36b2b503050c53dd9 - https://git.kernel.org/stable/c/84b8c266c4bfe9ed5128e13253c388deb74b1b03 - https://git.kernel.org/stable/c/38134ada0ceea3e848fe993263c0ff6207fd46e7
CVE ID: CVE-2021-47041 State: PUBLISHED Published: 2024-02-28T08:13:47.182Z Last Updated: 2025-05-04T07:02:51.163Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3
made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local
_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_que
8/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687): [<ffffffff9ec376bd>] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686): [<ffffffff9ec374d8>] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684): [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last
in_lock_irqsave+0x68/0x90 softirqs last enabled at (10684): [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); <Interrupt> lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb
: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ? _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acq
/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/999d606a820c36ae9b9e9611360c8b3d8d4bb777 - https://git.kernel
m Container: References: - https://git.kernel.org/stable/c/999d606a820c36ae9b9e9611360c8b3d8d4bb777 - https://git.kernel.org/stable/c/60ade0d56b06537a28884745059b3801c78e03bc - https://git.kernel.org/stable/c/06beaa1a9f6e501213195e47c30416032fd2bbd5 - https://git.kernel.org/stable/c/906c538340dde6d891df89fe7dac8eaa724e40da - https://git.kernel.org/stable/c/b5332a9f3f3d884a1b646ce155e664cc558c1722
CVE ID: CVE-2021-47042 State: PUBLISHED Published: 2024-02-28T08:13:47.809Z Last Updated: 2025-05-04T07:02:52.181Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Free local data after use Fixes the following memory leak in dc_link_construct(): unreferenced object 0xffffa03e81471400 (size 1024): comm "amd_module_load", pid 2486, jiffies 4294946026 (age 10.544s) hex dump (first 32 bytes): 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 00 ................ backtrace: [<000000000bdf5c4a>] kmem_cache_alloc_trace+0x30a/0x4a0 [<00000000e7c59f0e>] link_creat
0 00 ................ backtrace: [<000000000bdf5c4a>] kmem_cache_alloc_trace+0x30a/0x4a0 [<00000000e7c59f0e>] link_create+0xce/0xac0 [amdgpu] [<000000002fb6c072>] dc_create+0x370/0x720 [amdgpu] [<000000000094d1f3>] amdgpu_dm_init+0x18e/0x17a0 [amdgpu] [<00000000bec048fd>] dm_hw_init+0x12/0x20 [amdgpu] [<00000000a2bb7cf6>] amdgpu_device_init+0x1463/0x1e60 [amdgpu] [<0000000032d3bb13>] amdgpu_driver_load_kms+0x5b/0x330 [amdgpu] [<00000000a27834f9>] amdgpu_pci_probe+0x192/0x280 [amdgpu] [<00000000fec7d291>] local_pci_probe+0x47/0xa0 [<0000000055dbbfa7>] pci_device_probe+0xe3/0x180 [<00000000815da970>] really_probe+0x1c4/0x4e0 [<00000000b4b6974b>] driver_probe_device+0x62/0x150 [<000000000f9ecc6
x180 [<00000000815da970>] really_probe+0x1c4/0x4e0 [<00000000b4b6974b>] driver_probe_device+0x62/0x150 [<000000000f9ecc61>] device_driver_attach+0x58/0x60 [<000000000f65c843>] __driver_attach+0xd6/0x150 [<000000002f5e3683>] bus_for_each_dev+0x6a/0xc0 [<00000000a1cfc897>] driver_attach+0x1e/0x20 Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/296443139f893b554dddd56a99ba8471ab5802d4 - https://git.kernel.org/stable/c/616cf23b6cf40ad6f03ffbddfa1b6c4eb68d8ae1
CVE ID: CVE-2021-47043 State: PUBLISHED Published: 2024-02-28T08:13:48.440Z Last Updated: 2025-05-04T07:02:53.181Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: venus: core: Fix some resource leaks in the error path of 'venus_probe()' If an error occurs after a successful 'of_icc_get()' call, it must be undone. Use 'devm_of_icc_get()' instead of 'of_icc_get()' to avoid the leak. Update the remove function accordingly and axe the now unneeded 'icc_put()' calls. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/00b68a7478343afdf83f30c43e64db5296057030
ichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/00b68a7478343afdf83f30c43e64db5296057030 - https://git.kernel.org/stable/c/940d01eceb3a7866fbfca136a55a5625fc75a565 - https://git.kernel.org/stable/c/711acdf0228dc71601247f28b56f13e850e395c8 - https://git.kernel.org/stable/c/5a465c5391a856a0c1e9554964d660676c35d1b2
CVE ID: CVE-2021-47044 State: PUBLISHED Published: 2024-02-28T08:13:49.087Z Last Updated: 2025-05-04T07:02:59.275Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix shift-out-of-bounds in load_balance() Syzbot reported a handful of occurrences where an sd->nr_balance_failed can grow to much higher values than one would expect. A successful load_balance() resets it to 0; a failed one increments it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an active balance, which will either set it to sd->cache_nice_tries+1 or reset it to 0. However, in case the to-be-active-balanced task is not allowed to run
set it to sd->cache_nice_tries+1 or reset it to 0. However, in case the to-be-active-balanced task is not allowed to run on env->dst_cpu, then the increment is done without any further modification. This could then be repeated ad nauseam, and would explain the absurdly high values reported by syzbot (86, 149). VincentG noted there is value in letting sd->cache_nice_tries grow, so the shift itself should be fixed. That means preventing: """ If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. """ Thus we need to cap the shift exponent to BITS_PER_TYPE(typeof(lefthand)) - 1. I had a look around for other
efined. """ Thus we need to cap the shift exponent to BITS_PER_TYPE(typeof(lefthand)) - 1. I had a look around for other similar cases via coccinelle: @expr@ position pos; expression E1; expression E2; @@ ( E1 >> E2@pos | E1 >> E2@pos ) @cst depends on expr@ position pos; expression expr.E1; constant cst; @@ ( E1 >> cst@pos | E1 << cst@pos ) @script:python depends on !cst@ pos << expr.pos; exp << expr.E2; @@ # Dirty hack to ignore constexpr if exp.upper() != exp: coccilib.report.print_report(pos[0], "Possible UB shift here") The only other match in kernel/sched is rq_clock_thermal() which employs sched_thermal_decay_shift, and that exponent is already capped to 10, so that one is fine. Addit
thermal() which employs sched_thermal_decay_shift, and that exponent is already capped to 10, so that one is fine. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/80862cbf76c2646f709a57c4517aefe0b094c774 - https://git.kernel.org/stable/c/2f3eab368e313dba35fc2f51ede778bf7b030b54 - https://git.kernel.org/stable/c/805cea93e66ca7deaaf6ad3b67224ce47c104c2f - https://git.kernel.org/stable/c/39a2a6eb5c9b66ea7c8055026303b3aa681b49a5
CVE ID: CVE-2021-47045 State: PUBLISHED Published: 2024-02-28T08:13:49.708Z Last Updated: 2025-05-04T07:03:00.354Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb() It is possible to call lpfc_issue_els_plogi() passing a did for which no matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a null pointer to a lpfc_nodelist structure resulting in a null pointer dereference. Fix by returning an error status if no valid ndlp is found. Fix up comments regarding ndlp reference counting. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program C
d. Fix up comments regarding ndlp reference counting. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/a09677de458d500b00701f6036baa423d9995408 - https://git.kernel.org/stable/c/9bdcfbed2a9fe24d2c7eaa1bad7c705e18de8cc7 - https://git.kernel.org/stable/c/8dd1c125f7f838abad009b64bff5f0a11afe3cb6
CVE ID: CVE-2021-47046 State: PUBLISHED Published: 2024-02-28T08:13:50.320Z Last Updated: 2025-05-04T07:03:01.818Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix off by one in hdmi_14_process_transaction() The hdcp_i2c_offsets[] array did not have an entry for HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one read overflow. I added an entry and copied the 0x0 value for the offset from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c. I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX entries. This doesn't change the code, but it's just a belt and susp
veral of these arrays as having HDCP_MESSAGE_ID_MAX entries. This doesn't change the code, but it's just a belt and suspenders approach to try future proof the code. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/403c4528e5887af3deb9838cb77a557631d1e138 - https://git.kernel.org/stable/c/6a58310d5d1e5b02d0fc9b393ba540c9367bced5 - https://git.kernel.org/stable/c/080bd41d6478a64edf96704fddcda52b1fd5fed7 - https://git.kernel.org/stable/c/8e6fafd5a22e7a2eb216f5510db7aab54cc545c1
CVE ID: CVE-2021-47047 State: PUBLISHED Published: 2024-02-28T08:13:50.931Z Last Updated: 2025-05-04T07:03:02.855Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails The spi controller supports 44-bit address space on AXI in DMA mode, so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping. In addition, if dma_map_single fails, it should return immediately instead of continuing doing the DMA operation which bases on invalid address. This fixes the following crash which occurs in reading a big block from flash: [ 123.633577] zynqmp-qspi ff0f0000.spi: swiotlb bu
s the following crash which occurs in reading a big block from flash: [ 123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots) [ 123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped [ 123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0 [ 123.792536] Mem abort info: [ 123.795313] ESR = 0x96000145 [ 123.798351] EC = 0x25: DABT (current EL), IL = 32 bits [ 123.803655] SET = 0, FnV = 0 [ 123.806693] EA = 0, S1PTW = 0 [ 123.809818] Data abort info: [ 123.812683] ISV = 0, ISS = 0x00000145 [ 123.816503] CM = 1, WnR = 1 [ 123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000
, ISS = 0x00000145 [ 123.816503] CM = 1, WnR = 1 [ 123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000 [ 123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000 [ 123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/5980a3b9c933408bc22b0e349b78c3ebd7cbf880 - https://git.kernel.org/stable/c/c26c026eb496261dbc0adbf606cc81989cd2038c - https://git.kernel.org/stable/c/bad5a23cf2b477fa78b85fd392736dae09a1e818 - https://git.kernel.org/stable/c/126bdb606fd2802454e6048caef1be3e25dd121e
CVE ID: CVE-2021-47048 State: PUBLISHED Published: 2024-02-28T08:13:51.551Z Last Updated: 2025-05-04T07:03:08.916Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op When handling op->addr, it is using the buffer "tmpbuf" which has been freed. This will trigger a use-after-free KASAN warning. Let's use temporary variables to store op->addr.val and op->cmd.opcode to fix this issue. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/1231279389b5e638bc3b66b9741c94077aed4b5a - https://git.kernel.org/st
ment: References: - https://git.kernel.org/stable/c/1231279389b5e638bc3b66b9741c94077aed4b5a - https://git.kernel.org/stable/c/d67e0d6bd92ebbb0294e7062bbf5cdc773764e62 - https://git.kernel.org/stable/c/23269ac9f123eca3aea7682d3345c02e71ed696c - https://git.kernel.org/stable/c/a2c5bedb2d55dd27c642c7b9fb6886d7ad7bdb58
CVE ID: CVE-2021-47049 State: PUBLISHED Published: 2024-02-28T08:13:52.168Z Last Updated: 2025-05-04T12:40:57.653Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Use after free in __vmbus_open() The "open_info" variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees "open_info" without removing it from the list. This will result in a use after free. First remove it from the list, and then free it. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d5c7b42c9f56ca46b286daa537d181bd7f69214f - https://git.kernel.
lnrichment: References: - https://git.kernel.org/stable/c/d5c7b42c9f56ca46b286daa537d181bd7f69214f - https://git.kernel.org/stable/c/f37dd5d1b5d38a79a4f7b8dd7bbb705505f05560 - https://git.kernel.org/stable/c/2728f289b3270b0e273292b46c534421a33bbfd5 - https://git.kernel.org/stable/c/3e9bf43f7f7a46f21ec071cb47be92d0874c48da
CVE ID: CVE-2021-47050 State: PUBLISHED Published: 2024-02-28T08:13:52.801Z Last Updated: 2025-05-04T07:03:11.234Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: memory: renesas-rpc-if: fix possible NULL pointer dereference of resource The platform_get_resource_byname() can return NULL which would be immediately dereferenced by resource_size(). Instead dereference it after validating the resource. Addresses-Coverity: Dereference null return value Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/71bcc1b4a1743534d8abdcb57ff912e6bc390438 - https://git.kernel.
lnrichment: References: - https://git.kernel.org/stable/c/71bcc1b4a1743534d8abdcb57ff912e6bc390438 - https://git.kernel.org/stable/c/e16acc3a37f09e18835dc5d8014942c2ef6ca957 - https://git.kernel.org/stable/c/a74cb41af7dbe019e4096171f8bc641c7ce910ad - https://git.kernel.org/stable/c/59e27d7c94aa02da039b000d33c304c179395801
CVE ID: CVE-2021-47051 State: PUBLISHED Published: 2024-02-28T08:13:53.461Z Last Updated: 2025-05-04T07:03:12.356Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware() pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/4a01ad002d2e03c399af536562693752af7c81b1 - https://git.ker
P Vulnrichment: References: - https://git.kernel.org/stable/c/4a01ad002d2e03c399af536562693752af7c81b1 - https://git.kernel.org/stable/c/ce02e58ddf8658a4c3bed2296f32a5873b3f7cce - https://git.kernel.org/stable/c/b8207bfc539cd07d15e753ff2d179c5b61c673b1 - https://git.kernel.org/stable/c/6a2b5cee0d31ab6cc51030c441135b0e31217282 - https://git.kernel.org/stable/c/a03675497970a93fcf25d81d9d92a59c2d7377a7
CVE ID: CVE-2021-47052 State: PUBLISHED Published: 2024-02-28T08:13:54.083Z Last Updated: 2025-05-04T07:03:13.528Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul - Fix memory leak of rxd There are two error return paths that are not freeing rxd and causing memory leaks. Fix these. Addresses-Coverity: ("Resource leak") Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/0e596b3734649041ed77edc86a23c0442bbe062b - https://git.kernel.org/stable/c/dfd6443bf49ac17adf882ca46c40c506a0284bd6 - https://git.kernel.org/stable/c/b7bd0657c2036add71981d88a7fae
el.org/stable/c/dfd6443bf49ac17adf882ca46c40c506a0284bd6 - https://git.kernel.org/stable/c/b7bd0657c2036add71981d88a7fae50188150b6e - https://git.kernel.org/stable/c/854b7737199848a91f6adfa0a03cf6f0c46c86e8