Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/tegra: Fix reference leak in tegra_dsi_ganged_probe<br /> <br /> The reference taken by &amp;#39;of_find_device_by_node()&amp;#39; must be released when<br /> not needed anymore. Add put_device() call to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm8001: Fix abort all task initialization<br /> <br /> In pm80xx_send_abort_all(), the n_elem field of the ccb used is not<br /> initialized to 0. This missing initialization sometimes lead to the task<br /> completion path seeing the ccb with a non-zero n_elem resulting in the<br /> execution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(),<br /> causing a crash such as:<br /> <br /> [ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280<br /> [ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012<br /> [ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0<br /> [ 197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0<br /> [ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b<br /> [ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000<br /> [ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000<br /> [ 197.741493] FS: 0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000<br /> [ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0<br /> [ 197.762656] Call Trace:<br /> [ 197.765127] <br /> [ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx]<br /> [ 197.772364] ? do_raw_spin_unlock+0x54/0x220<br /> [ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx]<br /> [ 197.782406] process_oq+0xe85/0x7890 [pm80xx]<br /> [ 197.786817] ? lock_acquire+0x194/0x490<br /> [ 197.790697] ? handle_irq_event+0x10e/0x1b0<br /> [ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx]<br /> [ 197.800378] ? __wake_up_bit+0x100/0x100<br /> [ 197.804340] ? lock_is_held_type+0x98/0x110<br /> [ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx]<br /> [ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0<br /> [ 197.818785] __do_softirq+0x1b5/0x82d<br /> [ 197.822485] ? do_raw_spin_unlock+0x54/0x220<br /> [ 197.826799] __irq_exit_rcu+0x17e/0x1e0<br /> [ 197.830678] irq_exit_rcu+0xa/0x20<br /> [ 197.834114] common_interrupt+0x78/0x90<br /> [ 197.840051] <br /> [ 197.844236] <br /> [ 197.848397] asm_common_interrupt+0x1e/0x40<br /> <br /> Avoid this issue by always initializing the ccb n_elem field to 0 in<br /> pm8001_send_abort_all(), pm8001_send_read_log() and<br /> pm80xx_send_abort_all().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/dp: Fix OOB read when handling Post Cursor2 register<br /> <br /> The link_status array was not large enough to read the Adjust Request<br /> Post Cursor2 register, so remove the common helper function to avoid<br /> an OOB read, found with a -Warray-bounds build:<br /> <br /> drivers/gpu/drm/drm_dp_helper.c: In function &amp;#39;drm_dp_get_adjust_request_post_cursor&amp;#39;:<br /> drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of &amp;#39;const u8[6]&amp;#39; {aka &amp;#39;const unsigned char[6]&amp;#39;} [-Werror=array-bounds]<br /> 59 | return link_status[r - DP_LANE0_1_STATUS];<br /> | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~<br /> drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing &amp;#39;link_status&amp;#39;<br /> 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],<br /> | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br /> <br /> Replace the only user of the helper with an open-coded fetch and decode,<br /> similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pci: fix memory leak during D3hot to D0 transition<br /> <br /> If &amp;#39;vfio_pci_core_device::needs_pm_restore&amp;#39; is set (PCI device does<br /> not have No_Soft_Reset bit set in its PMCSR config register), then<br /> the current PCI state will be saved locally in<br /> &amp;#39;vfio_pci_core_device::pm_save&amp;#39; during D0-&gt;D3hot transition and same<br /> will be restored back during D3hot-&gt;D0 transition.<br /> For saving the PCI state locally, pci_store_saved_state() is being<br /> used and the pci_load_and_free_saved_state() will free the allocated<br /> memory.<br /> <br /> But for reset related IOCTLs, vfio driver calls PCI reset-related<br /> API&amp;#39;s which will internally change the PCI power state back to D0. So,<br /> when the guest resumes, then it will get the current state as D0 and it<br /> will skip the call to vfio_pci_set_power_state() for changing the<br /> power state to D0 explicitly. In this case, the memory pointed by<br /> &amp;#39;pm_save&amp;#39; will never be freed. In a malicious sequence, the state changing<br /> to D3hot followed by VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET can be<br /> run in a loop and it can cause an OOM situation.<br /> <br /> This patch frees the earlier allocated memory first before overwriting<br /> &amp;#39;pm_save&amp;#39; to prevent the mentioned memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btmtksdio: Fix kernel oops in btmtksdio_interrupt<br /> <br /> Fix the following kernel oops in btmtksdio_interrrupt<br /> <br /> [ 14.339134] btmtksdio_interrupt+0x28/0x54<br /> [ 14.339139] process_sdio_pending_irqs+0x68/0x1a0<br /> [ 14.339144] sdio_irq_work+0x40/0x70<br /> [ 14.339154] process_one_work+0x184/0x39c<br /> [ 14.339160] worker_thread+0x228/0x3e8<br /> [ 14.339168] kthread+0x148/0x3ac<br /> [ 14.339176] ret_from_fork+0x10/0x30<br /> <br /> That happened because hdev-&gt;power_on is already called before<br /> sdio_set_drvdata which btmtksdio_interrupt handler relies on is not<br /> properly set up.<br /> <br /> The details are shown as the below: hci_register_dev would run<br /> queue_work(hdev-&gt;req_workqueue, &amp;hdev-&gt;power_on) as WQ_HIGHPRI<br /> workqueue_struct to complete the power-on sequeunce and thus hci_power_on<br /> may run before sdio_set_drvdata is done in btmtksdio_probe.<br /> <br /> The hci_dev_do_open in hci_power_on would initialize the device and enable<br /> the interrupt and thus it is possible that btmtksdio_interrupt is being<br /> called right before sdio_set_drvdata is filled out.<br /> <br /> When btmtksdio_interrupt is being called and sdio_set_drvdata is not filled<br /> , the kernel oops is going to happen because btmtksdio_interrupt access an<br /> uninitialized pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: fix race between xmit and reset<br /> <br /> There is a race between reset and the transmit paths that can lead to<br /> ibmvnic_xmit() accessing an scrq after it has been freed in the reset<br /> path. It can result in a crash like:<br /> <br /> Kernel attempted to read user page (0) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000000<br /> Faulting instruction address: 0xc0080000016189f8<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> ...<br /> NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic]<br /> LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280<br /> Call Trace:<br /> [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable)<br /> [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280<br /> [c000000000c9cfcc] sch_direct_xmit+0xec/0x330<br /> [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0<br /> [c000000000c00ad4] __dev_queue_xmit+0x394/0x730<br /> [c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding]<br /> [c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding]<br /> [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280<br /> [c000000000c00ca4] __dev_queue_xmit+0x564/0x730<br /> [c000000000cf97e0] neigh_hh_output+0xd0/0x180<br /> [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0<br /> [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0<br /> [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0<br /> [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0<br /> [c000000000d2d984] tcp_retransmit_skb+0x34/0x130<br /> [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0<br /> [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330<br /> [c000000000d317bc] tcp_write_timer+0x5c/0x200<br /> [c000000000243270] call_timer_fn+0x50/0x1c0<br /> [c000000000243704] __run_timers.part.0+0x324/0x460<br /> [c000000000243894] run_timer_softirq+0x54/0xa0<br /> [c000000000ea713c] __do_softirq+0x15c/0x3e0<br /> [c000000000166258] __irq_exit_rcu+0x158/0x190<br /> [c000000000166420] irq_exit+0x20/0x40<br /> [c00000000002853c] timer_interrupt+0x14c/0x2b0<br /> [c000000000009a00] decrementer_common_virt+0x210/0x220<br /> --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c<br /> <br /> The immediate cause of the crash is the access of tx_scrq in the following<br /> snippet during a reset, where the tx_scrq can be either NULL or an address<br /> that will soon be invalid:<br /> <br /> ibmvnic_xmit()<br /> {<br /> ...<br /> tx_scrq = adapter-&gt;tx_scrq[queue_num];<br /> txq = netdev_get_tx_queue(netdev, queue_num);<br /> ind_bufp = &amp;tx_scrq-&gt;ind_buf;<br /> <br /> if (test_bit(0, &amp;adapter-&gt;resetting)) {<br /> ...<br /> }<br /> <br /> But beyond that, the call to ibmvnic_xmit() itself is not safe during a<br /> reset and the reset path attempts to avoid this by stopping the queue in<br /> ibmvnic_cleanup(). However just after the queue was stopped, an in-flight<br /> ibmvnic_complete_tx() could have restarted the queue even as the reset is<br /> progressing.<br /> <br /> Since the queue was restarted we could get a call to ibmvnic_xmit() which<br /> can then access the bad tx_scrq (or other fields).<br /> <br /> We cannot however simply have ibmvnic_complete_tx() check the -&gt;resetting<br /> bit and skip starting the queue. This can race at the "back-end" of a good<br /> reset which just restarted the queue but has not cleared the -&gt;resetting<br /> bit yet. If we skip restarting the queue due to -&gt;resetting being true,<br /> the queue would remain stopped indefinitely potentially leading to transmit<br /> timeouts.<br /> <br /> IOW -&gt;resetting is too broad for this purpose. Instead use a new flag<br /> that indicates whether or not the queues are active. Only the open/<br /> reset paths control when the queues are active. ibmvnic_complete_tx()<br /> and others wake up the queue only if the queue is marked active.<br /> <br /> So we will have:<br /> A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()<br /> <br /> -&gt;resetting = true<br /> -&gt;tx_queues_active = false<br /> disable tx queues<br /> ...<br /> -&gt;tx_queues_active = true<br /> start tx queues<br /> <br /> B. Tx interrupt in ibmvnic_complete_tx():<br /> <br /> if (-&gt;tx_queues_active)<br /> netif_wake_subqueue();<br /> <br /> To ensure that -&gt;tx_queues_active and state of the queues are consistent,<br /> we need a lock which:<br /> <br /> - must also be taken in the interrupt path (ibmvnic_complete_tx())<br /> - shared across the multiple<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_uart: add missing NULL check in h5_enqueue<br /> <br /> Syzbot hit general protection fault in __pm_runtime_resume(). The problem<br /> was in missing NULL check.<br /> <br /> hu-&gt;serdev can be NULL and we should not blindly pass &amp;serdev-&gt;dev<br /> somewhere, since it will cause GPF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix double free during GPU reset on DC streams<br /> <br /> [Why]<br /> The issue only occurs during the GPU reset code path.<br /> <br /> We first backup the current state prior to commiting 0 streams<br /> internally from DM to DC. This state backup contains valid link<br /> encoder assignments.<br /> <br /> DC will clear the link encoder assignments as part of current state<br /> (but not the backup, since it was a copied before the commit) and<br /> free the extra stream reference it held.<br /> <br /> DC requires that the link encoder assignments remain cleared/invalid<br /> prior to commiting. Since the backup still has valid assignments we<br /> call the interface post reset to clear them. This routine also<br /> releases the extra reference that the link encoder interface held -<br /> resulting in a double free (and eventually a NULL pointer dereference).<br /> <br /> [How]<br /> We&amp;#39;ll have to do a full DC commit anyway after GPU reset because<br /> the stream count previously went to 0.<br /> <br /> We don&amp;#39;t need to retain the assignment that we had backed up, so<br /> just copy off of the now clean current state assignment after the<br /> reset has occcurred with the new link_enc_cfg_copy() interface.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix more uncharged while msg has more_data<br /> <br /> In tcp_bpf_send_verdict(), if msg has more data after<br /> tcp_bpf_sendmsg_redir():<br /> <br /> tcp_bpf_send_verdict()<br /> tosend = msg-&gt;sg.size //msg-&gt;sg.size = 22220<br /> case __SK_REDIRECT:<br /> sk_msg_return() //uncharged msg-&gt;sg.size(22220) sk-&gt;sk_forward_alloc<br /> tcp_bpf_sendmsg_redir() //after tcp_bpf_sendmsg_redir, msg-&gt;sg.size=11000<br /> goto more_data;<br /> tosend = msg-&gt;sg.size //msg-&gt;sg.size = 11000<br /> case __SK_REDIRECT:<br /> sk_msg_return() //uncharged msg-&gt;sg.size(11000) to sk-&gt;sk_forward_alloc<br /> <br /> The msg-&gt;sg.size(11000) has been uncharged twice, to fix we can charge the<br /> remaining msg-&gt;sg.size before goto more data.<br /> <br /> This issue can cause the following info:<br /> WARNING: CPU: 0 PID: 9860 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0<br /> Call Trace:<br /> <br /> inet_csk_destroy_sock+0x55/0x110<br /> __tcp_close+0x279/0x470<br /> tcp_close+0x1f/0x60<br /> inet_release+0x3f/0x80<br /> __sock_release+0x3d/0xb0<br /> sock_close+0x11/0x20<br /> __fput+0x92/0x250<br /> task_work_run+0x6a/0xa0<br /> do_exit+0x33b/0xb60<br /> do_group_exit+0x2f/0xa0<br /> get_signal+0xb6/0x950<br /> arch_do_signal_or_restart+0xac/0x2a0<br /> ? vfs_write+0x237/0x290<br /> exit_to_user_mode_prepare+0xa9/0x200<br /> syscall_exit_to_user_mode+0x12/0x30<br /> do_syscall_64+0x46/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> <br /> WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260<br /> Call Trace:<br /> <br /> __sk_destruct+0x24/0x1f0<br /> sk_psock_destroy+0x19b/0x1c0<br /> process_one_work+0x1b3/0x3c0<br /> worker_thread+0x30/0x350<br /> ? process_one_work+0x3c0/0x3c0<br /> kthread+0xe6/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix double uncharge the mem of sk_msg<br /> <br /> If tcp_bpf_sendmsg is running during a tear down operation, psock may be<br /> freed.<br /> <br /> tcp_bpf_sendmsg()<br /> tcp_bpf_send_verdict()<br /> sk_msg_return()<br /> tcp_bpf_sendmsg_redir()<br /> unlikely(!psock))<br /> sk_msg_free()<br /> <br /> The mem of msg has been uncharged in tcp_bpf_send_verdict() by<br /> sk_msg_return(), and would be uncharged by sk_msg_free() again. When psock<br /> is null, we can simply returning an error code, this would then trigger<br /> the sk_msg_free_nocharge in the error path of __SK_REDIRECT and would have<br /> the side effect of throwing an error up to user space. This would be a<br /> slight change in behavior from user side but would look the same as an<br /> error if the redirect on the socket threw an error.<br /> <br /> This issue can cause the following info:<br /> WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260<br /> Call Trace:<br /> <br /> __sk_destruct+0x24/0x1f0<br /> sk_psock_destroy+0x19b/0x1c0<br /> process_one_work+0x1b3/0x3c0<br /> worker_thread+0x30/0x350<br /> ? process_one_work+0x3c0/0x3c0<br /> kthread+0xe6/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix memory leak in error flow for subscribe event routine<br /> <br /> In case the second xa_insert() fails, the obj_event is not released. Fix<br /> the error unwind flow to free that memory to avoid a memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix memleak in sk_psock_queue_msg<br /> <br /> If tcp_bpf_sendmsg is running during a tear down operation we may enqueue<br /> data on the ingress msg queue while tear down is trying to free it.<br /> <br /> sk1 (redirect sk2) sk2<br /> ------------------- ---------------<br /> tcp_bpf_sendmsg()<br /> tcp_bpf_send_verdict()<br /> tcp_bpf_sendmsg_redir()<br /> bpf_tcp_ingress()<br /> sock_map_close()<br /> lock_sock()<br /> lock_sock() ... blocking<br /> sk_psock_stop<br /> sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED);<br /> release_sock(sk);<br /> lock_sock()<br /> sk_mem_charge()<br /> get_page()<br /> sk_psock_queue_msg()<br /> sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED);<br /> drop_sk_msg()<br /> release_sock()<br /> <br /> While drop_sk_msg(), the msg has charged memory form sk by sk_mem_charge<br /> and has sg pages need to put. To fix we use sk_msg_free() and then kfee()<br /> msg.<br /> <br /> This issue can cause the following info:<br /> WARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0<br /> Call Trace:<br /> <br /> inet_csk_destroy_sock+0x55/0x110<br /> tcp_rcv_state_process+0xe5f/0xe90<br /> ? sk_filter_trim_cap+0x10d/0x230<br /> ? tcp_v4_do_rcv+0x161/0x250<br /> tcp_v4_do_rcv+0x161/0x250<br /> tcp_v4_rcv+0xc3a/0xce0<br /> ip_protocol_deliver_rcu+0x3d/0x230<br /> ip_local_deliver_finish+0x54/0x60<br /> ip_local_deliver+0xfd/0x110<br /> ? ip_protocol_deliver_rcu+0x230/0x230<br /> ip_rcv+0xd6/0x100<br /> ? ip_local_deliver+0x110/0x110<br /> __netif_receive_skb_one_core+0x85/0xa0<br /> process_backlog+0xa4/0x160<br /> __napi_poll+0x29/0x1b0<br /> net_rx_action+0x287/0x300<br /> __do_softirq+0xff/0x2fc<br /> do_softirq+0x79/0x90<br /> <br /> <br /> WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0<br /> Call Trace:<br /> <br /> __sk_destruct+0x24/0x1f0<br /> sk_psock_destroy+0x19b/0x1c0<br /> process_one_work+0x1b3/0x3c0<br /> ? process_one_work+0x3c0/0x3c0<br /> worker_thread+0x30/0x350<br /> ? process_one_work+0x3c0/0x3c0<br /> kthread+0xe6/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br />