Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-49201 State: PUBLISHED Published: 2025-02-26T01:55:43.263Z Last Updated: 2025-10-01T19:56:59.050Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ibmvnic: fix race between xmit and reset There is a race between reset and the transmit paths that can lead to ibmvnic_xmit() accessing an scrq after it has been freed in the reset path. It can result in a crash like: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000016189f8 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnic
instruction address: 0xc0080000016189f8 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 Call Trace: [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable) [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c9cfcc] sch_direct_xmit+0xec/0x330 [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0 [c000000000c00ad4] __dev_queue_xmit+0x394/0x730 [c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding] [c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding] [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c00ca4] __dev_queue_xmit+0x564/0x730 [c000000000cf97e
ing] [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c00ca4] __dev_queue_xmit+0x564/0x730 [c000000000cf97e0] neigh_hh_output+0xd0/0x180 [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0 [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0 [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0 [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0 [c000000000d2d984] tcp_retransmit_skb+0x34/0x130 [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0 [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330 [c000000000d317bc] tcp_write_timer+0x5c/0x200 [c000000000243270] call_timer_fn+0x50/0x1c0 [c000000000243704] __run_timers.part.0+0x324/0x460 [c000000000243894] run_timer_softirq+0x54/0xa0 [c000000
fn+0x50/0x1c0 [c000000000243704] __run_timers.part.0+0x324/0x460 [c000000000243894] run_timer_softirq+0x54/0xa0 [c000000000ea713c] __do_softirq+0x15c/0x3e0 [c000000000166258] __irq_exit_rcu+0x158/0x190 [c000000000166420] irq_exit+0x20/0x40 [c00000000002853c] timer_interrupt+0x14c/0x2b0 [c000000000009a00] decrementer_common_virt+0x210/0x220 --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c The immediate cause of the crash is the access of tx_scrq in the following snippet during a reset, where the tx_scrq can be either NULL or an address that will soon be invalid: ibmvnic_xmit() { ... tx_scrq = adapter->tx_scrq[queue_num]; txq = netdev_get_tx_queue(netdev, queue_num); ind_bufp = &tx_s
mvnic_xmit() { ... tx_scrq = adapter->tx_scrq[queue_num]; txq = netdev_get_tx_queue(netdev, queue_num); ind_bufp = &tx_scrq->ind_buf; if (test_bit(0, &adapter->resetting)) { ... } But beyond that, the call to ibmvnic_xmit() itself is not safe during a reset and the reset path attempts to avoid this by stopping the queue in ibmvnic_cleanup(). However just after the queue was stopped, an in-flight ibmvnic_complete_tx() could have restarted the queue even as the reset is progressing. Since the queue was restarted we could get a call to ibmvnic_xmit() which can then access the bad tx_scrq (or other fields). We cannot however simply have ibmvnic_complete_tx() check the ->resetting bit and skip st
bad tx_scrq (or other fields). We cannot however simply have ibmvnic_complete_tx() check the ->resetting bit and skip starting the queue. This can race at the "back-end" of a good reset which just restarted the queue but has not cleared the ->resetting bit yet. If we skip restarting the queue due to ->resetting being true, the queue would remain stopped indefinitely potentially leading to transmit timeouts. IOW ->resetting is too broad for this purpose. Instead use a new flag that indicates whether or not the queues are active. Only the open/ reset paths control when the queues are active. ibmvnic_complete_tx() and others wake up the queue only if the queue is marked active. So we will have:
eues are active. ibmvnic_complete_tx() and others wake up the queue only if the queue is marked active. So we will have: A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open() ->resetting = true ->tx_queues_active = false disable tx queues ... ->tx_queues_active = true start tx queues B. Tx interrupt in ibmvnic_complete_tx(): if (->tx_queues_active) netif_wake_subqueue(); To ensure that ->tx_queues_active and state of the queues are consistent, we need a lock which: - must also be taken in the interrupt path (ibmvnic_complete_tx()) - shared across the multiple ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/1bd58abf595b
uncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/1bd58abf595b6cf1ba6dd47ec887c4c009155fc9 - https://git.kernel.org/stable/c/475f9cce98b63bc145b4efa66fa51175d4cb345f - https://git.kernel.org/stable/c/8507c6ade73cdbbbda5c3d31d67f52f2e1cf03fe - https://git.kernel.org/stable/c/4219196d1f662cb10a462eb9e076633a3fc31a15
CVE ID: CVE-2022-49202 State: PUBLISHED Published: 2025-02-26T01:55:43.738Z Last Updated: 2025-05-04T08:32:15.567Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_uart: add missing NULL check in h5_enqueue Syzbot hit general protection fault in __pm_runtime_resume(). The problem was in missing NULL check. hu->serdev can be NULL and we should not blindly pass &serdev->dev somewhere, since it will cause GPF. References: - https://git.kernel.org/stable/c/7235485433d290367d60ae22fcdfc565e61d42ab - https://git.kernel.org/stable/c/e6b6c904c0f88588b6a3ace20e4c0d61eab124f8 - https://git.kernel.org/stable/c/8a3896c30f54243
tps://git.kernel.org/stable/c/e6b6c904c0f88588b6a3ace20e4c0d61eab124f8 - https://git.kernel.org/stable/c/8a3896c30f542439d36303183dc96f65df8cc528 - https://git.kernel.org/stable/c/32cb08e958696908a9aad5e49a78d74f7e32fffb
CVE ID: CVE-2022-49203 State: PUBLISHED Published: 2025-02-26T01:55:44.214Z Last Updated: 2025-10-01T19:56:58.910Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix double free during GPU reset on DC streams [Why] The issue only occurs during the GPU reset code path. We first backup the current state prior to commiting 0 streams internally from DM to DC. This state backup contains valid link encoder assignments. DC will clear the link encoder assignments as part of current state (but not the backup, since it was a copied before the commit) and free the extra stream reference it held. DC requires that the link
backup, since it was a copied before the commit) and free the extra stream reference it held. DC requires that the link encoder assignments remain cleared/invalid prior to commiting. Since the backup still has valid assignments we call the interface post reset to clear them. This routine also releases the extra reference that the link encoder interface held - resulting in a double free (and eventually a NULL pointer dereference). [How] We'll have to do a full DC commit anyway after GPU reset because the stream count previously went to 0. We don't need to retain the assignment that we had backed up, so just copy off of the now clean current state assignment after the reset has occcurred with
nt that we had backed up, so just copy off of the now clean current state assignment after the reset has occcurred with the new link_enc_cfg_copy() interface. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/bbfcdd6289ba6f00f0cd7d496946dce9f6c600ac - https://git.kernel.org/stable/c/32685b32d825ca08c5dec826477332df886c4743
CVE ID: CVE-2022-49204 State: PUBLISHED Published: 2025-02-26T01:55:44.678Z Last Updated: 2025-05-04T08:32:17.906Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix more uncharged while msg has more_data In tcp_bpf_send_verdict(), if msg has more data after tcp_bpf_sendmsg_redir(): tcp_bpf_send_verdict() tosend = msg->sg.size //msg->sg.size = 22220 case __SK_REDIRECT: sk_msg_return() //uncharged msg->sg.size(22220) sk->sk_forward_alloc tcp_bpf_sendmsg_redir() //after tcp_bpf_sendmsg_redir, msg->sg.size=11000 goto more_data; tosend = msg->sg.size //msg->sg.size = 11000 case __SK_REDIRECT: sk_msg_return() //uncharg
sg.size=11000 goto more_data; tosend = msg->sg.size //msg->sg.size = 11000 case __SK_REDIRECT: sk_msg_return() //uncharged msg->sg.size(11000) to sk->sk_forward_alloc The msg->sg.size(11000) has been uncharged twice, to fix we can charge the remaining msg->sg.size before goto more data. This issue can cause the following info: WARNING: CPU: 0 PID: 9860 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Call Trace: <TASK> inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal
fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 ? vfs_write+0x237/0x290 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Call Trace: <TASK> __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> References: - https://git.kernel.org/stable/c/244ce90c8d0
ad_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> References: - https://git.kernel.org/stable/c/244ce90c8d0bd10ebf957da02c6f3fcd5d920bdf - https://git.kernel.org/stable/c/7b812a369e6416ab06d83cdd39d8e3f752781dd0 - https://git.kernel.org/stable/c/168ff181f5b6e7fce684c98a30d35da1dbf8f82a - https://git.kernel.org/stable/c/87d532d41ef937e16f61b3d2094f3a2ac49be365 - https://git.kernel.org/stable/c/abb4caa477a5450817d2aa1198edce66450aecf8 - https://git.kernel.org/stable/c/84472b436e760ba439e1969a9e3c5ae7c86de39d
CVE ID: CVE-2022-49205 State: PUBLISHED Published: 2025-02-26T01:55:45.177Z Last Updated: 2025-05-04T08:32:19.084Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix double uncharge the mem of sk_msg If tcp_bpf_sendmsg is running during a tear down operation, psock may be freed. tcp_bpf_sendmsg() tcp_bpf_send_verdict() sk_msg_return() tcp_bpf_sendmsg_redir() unlikely(!psock)) sk_msg_free() The mem of msg has been uncharged in tcp_bpf_send_verdict() by sk_msg_return(), and would be uncharged by sk_msg_free() again. When psock is null, we can simply returning an error code, this would then trigger the sk_msg_free_no
_msg_free() again. When psock is null, we can simply returning an error code, this would then trigger the sk_msg_free_nocharge in the error path of __SK_REDIRECT and would have the side effect of throwing an error up to user space. This would be a slight change in behavior from user side but would look the same as an error if the redirect on the socket threw an error. This issue can cause the following info: WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Call Trace: <TASK> __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+
work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> References: - https://git.kernel.org/stable/c/94c6ac22abcdede72bfaa0f4c22fb370891f4002 - https://git.kernel.org/stable/c/cd84ea3920aef936c559b63099ef0013ce6b2325 - https://git.kernel.org/stable/c/cb6f141ae705af0101e819065a79e6d029f6e393 - https://git.kernel.org/stable/c/223f3c51ab163852dd4819d357dcf33039929434 - https://git.kernel.org/stable/c/ac3ecb7760c750c8e4fc09c719241d8e6e88028c - https://git.kernel.org/stable/c/2486ab434b2c2a14e9237296db00b1e1b7ae3273
CVE ID: CVE-2022-49206 State: PUBLISHED Published: 2025-02-26T01:55:45.685Z Last Updated: 2025-10-01T19:56:58.741Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix memory leak in error flow for subscribe event routine In case the second xa_insert() fails, the obj_event is not released. Fix the error unwind flow to free that memory to avoid a memory leak. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0174a89663a5ef83617da15bf24c0af2f62b6c7f - https://git.kernel.org/stable/c/c98d903ff9e79c210beddea4e6bc15ac38e25aa5 - https://git.kernel.org/stable/c/8dd392e352d3269938
://git.kernel.org/stable/c/c98d903ff9e79c210beddea4e6bc15ac38e25aa5 - https://git.kernel.org/stable/c/8dd392e352d3269938fea32061a74655a613f929 - https://git.kernel.org/stable/c/d66498507801fd9a20307a15a0814a0a016c3cde - https://git.kernel.org/stable/c/414b4e8738484379f18d6c4e780787c80dbf8a2c - https://git.kernel.org/stable/c/087f9c3f2309ed183f7e4b85ae57121d8663224d
CVE ID: CVE-2022-49207 State: PUBLISHED Published: 2025-02-26T01:55:46.177Z Last Updated: 2025-10-01T19:47:06.855Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix memleak in sk_psock_queue_msg If tcp_bpf_sendmsg is running during a tear down operation we may enqueue data on the ingress msg queue while tear down is trying to free it. sk1 (redirect sk2) sk2 ------------------- --------------- tcp_bpf_sendmsg() tcp_bpf_send_verdict() tcp_bpf_sendmsg_redir() bpf_tcp_ingress() sock_map_close() lock_sock() lock_sock() ... blocking sk_psock_stop sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED); release_sock(sk); lock_
_sock() lock_sock() ... blocking sk_psock_stop sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED); release_sock(sk); lock_sock() sk_mem_charge() get_page() sk_psock_queue_msg() sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED); drop_sk_msg() release_sock() While drop_sk_msg(), the msg has charged memory form sk by sk_mem_charge and has sg pages need to put. To fix we use sk_msg_free() and then kfee() msg. This issue can cause the following info: WARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0 Call Trace: <IRQ> inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xe5f/0xe90 ? sk_filter_trim_cap+0x10d/0x230 ? tcp_v4_do_rcv+0x161/0x250 tcp_v4_do_rcv+0x161/0x250
tcp_rcv_state_process+0xe5f/0xe90 ? sk_filter_trim_cap+0x10d/0x230 ? tcp_v4_do_rcv+0x161/0x250 tcp_v4_do_rcv+0x161/0x250 tcp_v4_rcv+0xc3a/0xce0 ip_protocol_deliver_rcu+0x3d/0x230 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0xfd/0x110 ? ip_protocol_deliver_rcu+0x230/0x230 ip_rcv+0xd6/0x100 ? ip_local_deliver+0x110/0x110 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0xa4/0x160 __napi_poll+0x29/0x1b0 net_rx_action+0x287/0x300 __do_softirq+0xff/0x2fc do_softirq+0x79/0x90 </IRQ> WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0 Call Trace: <TASK> __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 ? process_one_work+0x
l Trace: <TASK> __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ef9785f429794567792561a584901faa9291d3ee - https://git.kernel.org/stable/c/4dd2e947d3be13a4de3b3028859b9a6497266bcf - https://git.kernel.org/stable/c/03948ed6553960db62f1c33bec29e64d7c191a3f - https://git.kernel.org/stable/c/938d3480b92fa5e454b7734294f12a7b75126f09
CVE ID: CVE-2022-49208 State: PUBLISHED Published: 2025-02-26T01:55:46.666Z Last Updated: 2025-10-01T19:47:06.592Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent some integer underflows My static checker complains that: drivers/infiniband/hw/irdma/ctrl.c:3605 irdma_sc_ceq_init() warn: can subtract underflow 'info->dev->hmc_fpm_misc.max_ceqs'? It appears that "info->dev->hmc_fpm_misc.max_ceqs" comes from the firmware in irdma_sc_parse_fpm_query_buf() so, yes, there is a chance that it could be zero. Even if we trust the firmware, it's easy enough to change the condition just as a hardenning measure. Additiona
be zero. Even if we trust the firmware, it's easy enough to change the condition just as a hardenning measure. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d52dab6e03550f9c97121b0c11c0a3ed78ee76a4 - https://git.kernel.org/stable/c/f21056f15bbeacab7b4b87af232f5599d1f2bff1 - https://git.kernel.org/stable/c/7340c3675d7ac946f4019b84cd7c64ed542dfe4c - https://git.kernel.org/stable/c/6f6dbb819dfc1a35bcb8b709b5c83a3ea8beff75
CVE ID: CVE-2022-49209 State: PUBLISHED Published: 2025-02-26T01:55:47.154Z Last Updated: 2025-10-01T19:47:06.352Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc() returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is greater than osize after sk_msg_alloc(), memleak occurs. To fix we use sk_msg_trim() to release the allocated memory, then goto wait for memory. Other call paths of sk_msg_alloc() have
e use sk_msg_trim() to release the allocated memory, then goto wait for memory. Other call paths of sk_msg_alloc() have the similar issue, such as tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(), as Cong Wang suggested. This issue can cause the following info: WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Call Trace: <TASK> inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare
0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Call Trace: <TASK> __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30 </TASK> Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/6d03722c34d9603df325f67c6d30dc1b7b3c6067 - https://git.kernel.org/stable/c/bec34a91eba3483e1830c02bdd36f8f968642047 - https://
2c34d9603df325f67c6d30dc1b7b3c6067 - https://git.kernel.org/stable/c/bec34a91eba3483e1830c02bdd36f8f968642047 - https://git.kernel.org/stable/c/de3a8d8fab0710186f7864ec812836d8d70da3c9 - https://git.kernel.org/stable/c/f677328f05f52d535cbdc15cb04476db49477eb4 - https://git.kernel.org/stable/c/d0b85dfc6f01d26808e2576c6537c131b590e270 - https://git.kernel.org/stable/c/9c34e38c4a870eb30b13f42f5b44f42e9d19ccb8
CVE ID: CVE-2022-49210 State: PUBLISHED Published: 2025-02-26T01:55:47.679Z Last Updated: 2025-10-01T19:47:06.119Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: MIPS: pgalloc: fix memory leak caused by pgd_free() pgd page is freed by generic implementation pgd_free() since commit f9cb654cb550 ("asm-generic: pgalloc: provide generic pgd_free()"), however, there are scenarios that the system uses more than one page as the pgd table, in such cases the generic implementation pgd_free() won't be applicable anymore. For example, when PAGE_SIZE_4KB is enabled and MIPS_VA_BITS_48 is not enabled in a 64bit system, the macro "PGD_ORDER"
. For example, when PAGE_SIZE_4KB is enabled and MIPS_VA_BITS_48 is not enabled in a 64bit system, the macro "PGD_ORDER" will be set as "1", which will cause allocating two pages as the pgd table. Well, at the same time, the generic implementation pgd_free() just free one pgd page, which will result in the memory leak. The memory leak can be easily detected by executing shell command: "while true; do ls > /dev/null; grep MemFree /proc/meminfo; done" Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/fa3d44424579972cc7c4fac3d9cf227798ebdfa0 - https://git.kernel.org/stable/c/d29cda15cab086d82d692de016f7249545d4b6b4 - https://git.kernel.org/stable/c
27798ebdfa0 - https://git.kernel.org/stable/c/d29cda15cab086d82d692de016f7249545d4b6b4 - https://git.kernel.org/stable/c/5a8501d34b261906e4c76ec9da679f2cb4d309ed - https://git.kernel.org/stable/c/1bf0d78c8cc3cf615a6e7bf33ada70b73592f0a1 - https://git.kernel.org/stable/c/2bc5bab9a763d520937e4f3fe8df51c6a1eceb97
CVE ID: CVE-2022-49211 State: PUBLISHED Published: 2025-02-26T01:55:48.176Z Last Updated: 2025-10-01T20:17:06.796Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mips: cdmm: Fix refcount leak in mips_cdmm_phys_base The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ef1728e3cb9e43f38ed10cde705a7ba2b4ad2d35 - https://git.kernel.org/stable/c/69155dc2e04777aa94207a73a8b10f12b8428a68 - https://git.kerne
38ed10cde705a7ba2b4ad2d35 - https://git.kernel.org/stable/c/69155dc2e04777aa94207a73a8b10f12b8428a68 - https://git.kernel.org/stable/c/4680c2ac9aabda82acd23ebbd1f900fb6a889cd3 - https://git.kernel.org/stable/c/721ab4be20d4448dd04c2cc8ed99cd4f3e45f765 - https://git.kernel.org/stable/c/4528668ca331f7ce5999b7746657b46db5b3b785
CVE ID: CVE-2022-49212 State: PUBLISHED Published: 2025-02-26T01:55:48.690Z Last Updated: 2025-10-01T19:47:05.977Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init The reference counting issue happens in several error handling paths on a refcounted object "nc->dmac". In these paths, the function simply returns the error code, forgetting to balance the reference count of "nc->dmac", increased earlier by dma_request_channel(), which may cause refcount leaks. Fix it by decrementing the refcount of specific object in those error paths. Additional Analyst Notes: - C
fcount leaks. Fix it by decrementing the refcount of specific object in those error paths. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0856bf27057561f42b37df111603cf5a0d040294 - https://git.kernel.org/stable/c/9843c9c98f26c6ad843260b19bfdaa2598f2ae1e - https://git.kernel.org/stable/c/9b08d211db4c447eb1a07df65e45e0aa772e0fa6 - https://git.kernel.org/stable/c/a3587259ae553e41d1ce8c7435351a5d6b299a11 - https://git.kernel.org/stable/c/fe0e2ce5c87e9c0b9485ff566362030aa55972cf - https://git.kernel.org/stable/c/8baea2b96fa90af8d0f937caf4cf2105ee094d93 - https://git.kernel.org/stable/c/f1694169f3674cdf7553aed06864254635679878 - https://git.kernel.
0f937caf4cf2105ee094d93 - https://git.kernel.org/stable/c/f1694169f3674cdf7553aed06864254635679878 - https://git.kernel.org/stable/c/fecbd4a317c95d73c849648c406bcf1b6a0ec1cf