Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mips: cdmm: Fix refcount leak in mips_cdmm_phys_base<br /> <br /> The of_find_compatible_node() function returns a node pointer with<br /> refcount incremented, We should use of_node_put() on it when done<br /> Add the missing of_node_put() to release the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init<br /> <br /> The reference counting issue happens in several error handling paths<br /> on a refcounted object "nc-&gt;dmac". In these paths, the function simply<br /> returns the error code, forgetting to balance the reference count of<br /> "nc-&gt;dmac", increased earlier by dma_request_channel(), which may<br /> cause refcount leaks.<br /> <br /> Fix it by decrementing the refcount of specific object in those error<br /> paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath10k: Fix error handling in ath10k_setup_msa_resources<br /> <br /> The device_node pointer is returned by of_parse_phandle() with refcount<br /> incremented. We should use of_node_put() on it when done.<br /> <br /> This function only calls of_node_put() in the regular path.<br /> And it will cause refcount leak in error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64s: Don&amp;#39;t use DSISR for SLB faults<br /> <br /> Since commit 46ddcb3950a2 ("powerpc/mm: Show if a bad page fault on data<br /> is read or write.") we use page_fault_is_write(regs-&gt;dsisr) in<br /> __bad_page_fault() to determine if the fault is for a read or write, and<br /> change the message printed accordingly.<br /> <br /> But SLB faults, aka Data Segment Interrupts, don&amp;#39;t set DSISR (Data<br /> Storage Interrupt Status Register) to a useful value. All ISA versions<br /> from v2.03 through v3.1 specify that the Data Segment Interrupt sets<br /> DSISR "to an undefined value". As far as I can see there&amp;#39;s no mention of<br /> SLB faults setting DSISR in any BookIV content either.<br /> <br /> This manifests as accesses that should be a read being incorrectly<br /> reported as writes, for example, using the xmon "dump" command:<br /> <br /> 0:mon&gt; d 0x5deadbeef0000000<br /> 5deadbeef0000000<br /> [359526.415354][ C6] BUG: Unable to handle kernel data access on write at 0x5deadbeef0000000<br /> [359526.415611][ C6] Faulting instruction address: 0xc00000000010a300<br /> cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf400]<br /> pc: c00000000010a300: mread+0x90/0x190<br /> <br /> If we disassemble the PC, we see a load instruction:<br /> <br /> 0:mon&gt; di c00000000010a300<br /> c00000000010a300 89490000 lbz r10,0(r9)<br /> <br /> We can also see in exceptions-64s.S that the data_access_slb block<br /> doesn&amp;#39;t set IDSISR=1, which means it doesn&amp;#39;t load DSISR into pt_regs. So<br /> the value we&amp;#39;re using to determine if the fault is a read/write is some<br /> stale value in pt_regs from a previous page fault.<br /> <br /> Rework the printing logic to separate the SLB fault case out, and only<br /> print read/write in the cases where we can determine it.<br /> <br /> The result looks like eg:<br /> <br /> 0:mon&gt; d 0x5deadbeef0000000<br /> 5deadbeef0000000<br /> [ 721.779525][ C6] BUG: Unable to handle kernel data access at 0x5deadbeef0000000<br /> [ 721.779697][ C6] Faulting instruction address: 0xc00000000014cbe0<br /> cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390]<br /> <br /> 0:mon&gt; d 0<br /> 0000000000000000<br /> [ 742.793242][ C6] BUG: Kernel NULL pointer dereference at 0x00000000<br /> [ 742.793316][ C6] Faulting instruction address: 0xc00000000014cbe0<br /> cpu 0x6: Vector: 380 (Data SLB Access) at [c00000000ffbf390]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: Fix race at socket teardown<br /> <br /> Fix a race in the xsk socket teardown code that can lead to a NULL pointer<br /> dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by<br /> setting xs-&gt;state to XSK_UNBOUND, sets xs-&gt;dev to NULL and then waits for any<br /> NAPI processing to terminate using synchronize_net(). After that, the release<br /> code starts to tear down the socket state and free allocated memory.<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000c0<br /> PGD 8000000932469067 P4D 8000000932469067 PUD 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2<br /> Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015<br /> RIP: 0010:__xsk_sendmsg+0x2c/0x690<br /> [...]<br /> RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258<br /> RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800<br /> RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800<br /> R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000<br /> FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> ? aa_sk_perm+0x43/0x1b0<br /> xsk_sendmsg+0xf0/0x110<br /> sock_sendmsg+0x65/0x70<br /> __sys_sendto+0x113/0x190<br /> ? debug_smp_processor_id+0x17/0x20<br /> ? fpregs_assert_state_consistent+0x23/0x50<br /> ? exit_to_user_mode_prepare+0xa5/0x1d0<br /> __x64_sys_sendto+0x29/0x30<br /> do_syscall_64+0x3b/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> There are two problems with the current code. First, setting xs-&gt;dev to NULL<br /> before waiting for all users to stop using the socket is not correct. The<br /> entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()<br /> are all guarded by a test that xs-&gt;state is in the state XSK_BOUND and if not,<br /> it returns right away. But one process might have passed this test but still<br /> have not gotten to the point in which it uses xs-&gt;dev in the code. In this<br /> interim, a second process executing xsk_unbind_dev() might have set xs-&gt;dev to<br /> NULL which will lead to a crash for the first process. The solution here is<br /> just to get rid of this NULL assignment since it is not used anymore. Before<br /> commit 42fddcc7c64b ("xsk: use state member for socket synchronization"),<br /> xs-&gt;dev was the gatekeeper to admit processes into the data plane functions,<br /> but it was replaced with the state variable xs-&gt;state in the aforementioned<br /> commit.<br /> <br /> The second problem is that synchronize_net() does not wait for any process in<br /> xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the<br /> state they rely on might be cleaned up prematurely. This can happen when the<br /> notifier gets called (at driver unload for example) as it uses xsk_unbind_dev().<br /> Solve this by extending the RCU critical region from just the ndo_xsk_wakeup<br /> to the whole functions mentioned above, so that both the test of xs-&gt;state ==<br /> XSK_BOUND and the last use of any member of xs is covered by the RCU critical<br /> section. This will guarantee that when synchronize_net() completes, there will<br /> be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and<br /> state can be cleaned up safely. Note that we need to drop the RCU lock for the<br /> skb xmit path as it uses functions that might sleep. Due to this, we have to<br /> retest the xs-&gt;state after we grab the mutex that protects the skb xmit code<br /> from, among a number of things, an xsk_unbind_dev() being executed from the<br /> notifier at the same time.

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.