Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: mv88e6xxx: don&amp;#39;t use devres for mdiobus<br /> <br /> As explained in commits:<br /> 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres")<br /> 5135e96a3dd2 ("net: dsa: don&amp;#39;t allocate the slave_mii_bus using devres")<br /> <br /> mdiobus_free() will panic when called from devm_mdiobus_free() shutdown) do not apply. But there is one more which applies here.<br /> <br /> If the DSA master itself is on a bus that calls -&gt;remove from -&gt;shutdown<br /> (like dpaa2-eth, which is on the fsl-mc bus), there is a device link<br /> between the switch and the DSA master, and device_links_unbind_consumers()<br /> will unbind the Marvell switch driver on shutdown.<br /> <br /> systemd-shutdown[1]: Powering off.<br /> mv88e6085 0x0000000008b96000:00 sw_gl0: Link is Down<br /> fsl-mc dpbp.9: Removing from iommu group 7<br /> fsl-mc dpbp.8: Removing from iommu group 7<br /> ------------[ cut here ]------------<br /> kernel BUG at drivers/net/phy/mdio_bus.c:677!<br /> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00040-gdc05f73788e5 #15<br /> pc : mdiobus_free+0x44/0x50<br /> lr : devm_mdiobus_free+0x10/0x20<br /> Call trace:<br /> mdiobus_free+0x44/0x50<br /> devm_mdiobus_free+0x10/0x20<br /> devres_release_all+0xa0/0x100<br /> __device_release_driver+0x190/0x220<br /> device_release_driver_internal+0xac/0xb0<br /> device_links_unbind_consumers+0xd4/0x100<br /> __device_release_driver+0x4c/0x220<br /> device_release_driver_internal+0xac/0xb0<br /> device_links_unbind_consumers+0xd4/0x100<br /> __device_release_driver+0x94/0x220<br /> device_release_driver+0x28/0x40<br /> bus_remove_device+0x118/0x124<br /> device_del+0x174/0x420<br /> fsl_mc_device_remove+0x24/0x40<br /> __fsl_mc_device_remove+0xc/0x20<br /> device_for_each_child+0x58/0xa0<br /> dprc_remove+0x90/0xb0<br /> fsl_mc_driver_remove+0x20/0x5c<br /> __device_release_driver+0x21c/0x220<br /> device_release_driver+0x28/0x40<br /> bus_remove_device+0x118/0x124<br /> device_del+0x174/0x420<br /> fsl_mc_bus_remove+0x80/0x100<br /> fsl_mc_bus_shutdown+0xc/0x1c<br /> platform_shutdown+0x20/0x30<br /> device_shutdown+0x154/0x330<br /> kernel_power_off+0x34/0x6c<br /> __do_sys_reboot+0x15c/0x250<br /> __arm64_sys_reboot+0x20/0x30<br /> invoke_syscall.constprop.0+0x4c/0xe0<br /> do_el0_svc+0x4c/0x150<br /> el0_svc+0x24/0xb0<br /> el0t_64_sync_handler+0xa8/0xb0<br /> el0t_64_sync+0x178/0x17c<br /> <br /> So the same treatment must be applied to all DSA switch drivers, which<br /> is: either use devres for both the mdiobus allocation and registration,<br /> or don&amp;#39;t use devres at all.<br /> <br /> The Marvell driver already has a good structure for mdiobus removal, so<br /> just plug in mdiobus_free and get rid of devres.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case<br /> <br /> syzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY)<br /> calls over the same TCP socket would again trigger the<br /> infamous warning in inet_sock_destruct()<br /> <br /> WARN_ON(sk_forward_alloc_get(sk));<br /> <br /> While Talal took into account a mix of regular copied data<br /> and MSG_ZEROCOPY one in the same skb, the sendpage() path<br /> has been forgotten.<br /> <br /> We want the charging to happen for sendpage(), because<br /> pages could be coming from a pipe. What is missing is the<br /> downgrading of pure zerocopy status to make sure<br /> sk_forward_alloc will stay synced.<br /> <br /> Add tcp_downgrade_zcopy_pure() helper so that we can<br /> use it from the two callers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: stm32: fix a refcount leak in stm32_usbphyc_pll_enable()<br /> <br /> This error path needs to decrement "usbphyc-&gt;n_pll_cons.counter" before<br /> returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: nSVM: fix potential NULL derefernce on nested migration<br /> <br /> Turns out that due to review feedback and/or rebases<br /> I accidentally moved the call to nested_svm_load_cr3 to be too early,<br /> before the NPT is enabled, which is very wrong to do.<br /> <br /> KVM can&amp;#39;t even access guest memory at that point as nested NPT<br /> is needed for that, and of course it won&amp;#39;t initialize the walk_mmu,<br /> which is main issue the patch was addressing.<br /> <br /> Fix this for real.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ieee802154: at86rf230: Stop leaking skb&amp;#39;s<br /> <br /> Upon error the ieee802154_xmit_complete() helper is not called. Only<br /> ieee802154_wake_queue() is called manually. In the Tx case we then leak<br /> the skb structure.<br /> <br /> Free the skb structure upon error before returning when appropriate.<br /> <br /> As the &amp;#39;is_tx = 0&amp;#39; cannot be moved in the complete handler because of a<br /> possible race between the delay in switching to STATE_RX_AACK_ON and a<br /> new interrupt, we introduce an intermediate &amp;#39;was_tx&amp;#39; boolean just for<br /> this purpose.<br /> <br /> There is no Fixes tag applying here, many changes have been made on this<br /> area and the issue kind of always existed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Fix data TLB miss in sba_unmap_sg<br /> <br /> Rolf Eike Beer reported the following bug:<br /> <br /> [1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018<br /> [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4<br /> [1274934.746891] Hardware name: 9000/785/C8000<br /> [1274934.746891]<br /> [1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI<br /> [1274934.746891] PSW: 00001000000001001111111000001110 Not tainted<br /> [1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000<br /> [1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001<br /> [1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001<br /> [1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0<br /> [1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007<br /> [1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001<br /> [1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0<br /> [1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118<br /> [1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800<br /> [1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000<br /> [1274934.746891]<br /> [1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec<br /> [1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018<br /> [1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff<br /> [1274934.746891] ORIG_R28: 0000000040acdd58<br /> [1274934.746891] IAOQ[0]: sba_unmap_sg+0xb0/0x118<br /> [1274934.746891] IAOQ[1]: sba_unmap_sg+0xb4/0x118<br /> [1274934.746891] RP(r2): sba_unmap_sg+0xac/0x118<br /> [1274934.746891] Backtrace:<br /> [1274934.746891] [] dma_unmap_sg_attrs+0x6c/0x70<br /> [1274934.746891] [] scsi_dma_unmap+0x54/0x60<br /> [1274934.746891] [] mptscsih_io_done+0x150/0xd70<br /> [1274934.746891] [] mpt_interrupt+0x168/0xa68<br /> [1274934.746891] [] __handle_irq_event_percpu+0xc8/0x278<br /> [1274934.746891] [] handle_irq_event_percpu+0x3c/0xd8<br /> [1274934.746891] [] handle_percpu_irq+0xb4/0xf0<br /> [1274934.746891] [] generic_handle_irq+0x50/0x70<br /> [1274934.746891] [] call_on_stack+0x18/0x24<br /> [1274934.746891]<br /> [1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)<br /> <br /> The bug is caused by overrunning the sglist and incorrectly testing<br /> sg_dma_len(sglist) before nents. Normally this doesn&amp;#39;t cause a crash,<br /> but in this case sglist crossed a page boundary. This occurs in the<br /> following code:<br /> <br /> while (sg_dma_len(sglist) &amp;&amp; nents--) {<br /> <br /> The fix is simply to test nents first and move the decrement of nents<br /> into the loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Fix potential use-after-free during probe<br /> <br /> Kasan has reported the following use after free on dev-&gt;iommu.<br /> when a device probe fails and it is in process of freeing dev-&gt;iommu<br /> in dev_iommu_free function, a deferred_probe_work_func runs in parallel<br /> and tries to access dev-&gt;iommu-&gt;fwspec in of_iommu_configure path thus<br /> causing use after free.<br /> <br /> BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4<br /> Read of size 8 at addr ffffff87a2f1acb8 by task kworker/u16:2/153<br /> <br /> Workqueue: events_unbound deferred_probe_work_func<br /> Call trace:<br /> dump_backtrace+0x0/0x33c<br /> show_stack+0x18/0x24<br /> dump_stack_lvl+0x16c/0x1e0<br /> print_address_description+0x84/0x39c<br /> __kasan_report+0x184/0x308<br /> kasan_report+0x50/0x78<br /> __asan_load8+0xc0/0xc4<br /> of_iommu_configure+0xb4/0x4a4<br /> of_dma_configure_id+0x2fc/0x4d4<br /> platform_dma_configure+0x40/0x5c<br /> really_probe+0x1b4/0xb74<br /> driver_probe_device+0x11c/0x228<br /> __device_attach_driver+0x14c/0x304<br /> bus_for_each_drv+0x124/0x1b0<br /> __device_attach+0x25c/0x334<br /> device_initial_probe+0x24/0x34<br /> bus_probe_device+0x78/0x134<br /> deferred_probe_work_func+0x130/0x1a8<br /> process_one_work+0x4c8/0x970<br /> worker_thread+0x5c8/0xaec<br /> kthread+0x1f8/0x220<br /> ret_from_fork+0x10/0x18<br /> <br /> Allocated by task 1:<br /> ____kasan_kmalloc+0xd4/0x114<br /> __kasan_kmalloc+0x10/0x1c<br /> kmem_cache_alloc_trace+0xe4/0x3d4<br /> __iommu_probe_device+0x90/0x394<br /> probe_iommu_group+0x70/0x9c<br /> bus_for_each_dev+0x11c/0x19c<br /> bus_iommu_probe+0xb8/0x7d4<br /> bus_set_iommu+0xcc/0x13c<br /> arm_smmu_bus_init+0x44/0x130 [arm_smmu]<br /> arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]<br /> platform_drv_probe+0xe4/0x13c<br /> really_probe+0x2c8/0xb74<br /> driver_probe_device+0x11c/0x228<br /> device_driver_attach+0xf0/0x16c<br /> __driver_attach+0x80/0x320<br /> bus_for_each_dev+0x11c/0x19c<br /> driver_attach+0x38/0x48<br /> bus_add_driver+0x1dc/0x3a4<br /> driver_register+0x18c/0x244<br /> __platform_driver_register+0x88/0x9c<br /> init_module+0x64/0xff4 [arm_smmu]<br /> do_one_initcall+0x17c/0x2f0<br /> do_init_module+0xe8/0x378<br /> load_module+0x3f80/0x4a40<br /> __se_sys_finit_module+0x1a0/0x1e4<br /> __arm64_sys_finit_module+0x44/0x58<br /> el0_svc_common+0x100/0x264<br /> do_el0_svc+0x38/0xa4<br /> el0_svc+0x20/0x30<br /> el0_sync_handler+0x68/0xac<br /> el0_sync+0x160/0x180<br /> <br /> Freed by task 1:<br /> kasan_set_track+0x4c/0x84<br /> kasan_set_free_info+0x28/0x4c<br /> ____kasan_slab_free+0x120/0x15c<br /> __kasan_slab_free+0x18/0x28<br /> slab_free_freelist_hook+0x204/0x2fc<br /> kfree+0xfc/0x3a4<br /> __iommu_probe_device+0x284/0x394<br /> probe_iommu_group+0x70/0x9c<br /> bus_for_each_dev+0x11c/0x19c<br /> bus_iommu_probe+0xb8/0x7d4<br /> bus_set_iommu+0xcc/0x13c<br /> arm_smmu_bus_init+0x44/0x130 [arm_smmu]<br /> arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]<br /> platform_drv_probe+0xe4/0x13c<br /> really_probe+0x2c8/0xb74<br /> driver_probe_device+0x11c/0x228<br /> device_driver_attach+0xf0/0x16c<br /> __driver_attach+0x80/0x320<br /> bus_for_each_dev+0x11c/0x19c<br /> driver_attach+0x38/0x48<br /> bus_add_driver+0x1dc/0x3a4<br /> driver_register+0x18c/0x244<br /> __platform_driver_register+0x88/0x9c<br /> init_module+0x64/0xff4 [arm_smmu]<br /> do_one_initcall+0x17c/0x2f0<br /> do_init_module+0xe8/0x378<br /> load_module+0x3f80/0x4a40<br /> __se_sys_finit_module+0x1a0/0x1e4<br /> __arm64_sys_finit_module+0x44/0x58<br /> el0_svc_common+0x100/0x264<br /> do_el0_svc+0x38/0xa4<br /> el0_svc+0x20/0x30<br /> el0_sync_handler+0x68/0xac<br /> el0_sync+0x160/0x180<br /> <br /> Fix this by setting dev-&gt;iommu to NULL first and<br /> then freeing dev_iommu structure in dev_iommu_free<br /> function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: don&amp;#39;t try to NUMA-migrate COW pages that have other uses<br /> <br /> Oded Gabbay reports that enabling NUMA balancing causes corruption with<br /> his Gaudi accelerator test load:<br /> <br /> "All the details are in the bug, but the bottom line is that somehow,<br /> this patch causes corruption when the numa balancing feature is<br /> enabled AND we don&amp;#39;t use process affinity AND we use GUP to pin pages<br /> so our accelerator can DMA to/from system memory.<br /> <br /> Either disabling numa balancing, using process affinity to bind to<br /> specific numa-node or reverting this patch causes the bug to<br /> disappear"<br /> <br /> and Oded bisected the issue to commit 09854ba94c6a ("mm: do_wp_page()<br /> simplification").<br /> <br /> Now, the NUMA balancing shouldn&amp;#39;t actually be changing the writability<br /> of a page, and as such shouldn&amp;#39;t matter for COW. But it appears it<br /> does. Suspicious.<br /> <br /> However, regardless of that, the condition for enabling NUMA faults in<br /> change_pte_range() is nonsensical. It uses "page_mapcount(page)" to<br /> decide if a COW page should be NUMA-protected or not, and that makes<br /> absolutely no sense.<br /> <br /> The number of mappings a page has is irrelevant: not only does GUP get a<br /> reference to a page as in Oded&amp;#39;s case, but the other mappings migth be<br /> paged out and the only reference to them would be in the page count.<br /> <br /> Since we should never try to NUMA-balance a page that we can&amp;#39;t move<br /> anyway due to other references, just fix the code to use &amp;#39;page_count()&amp;#39;.<br /> Oded confirms that that fixes his issue.<br /> <br /> Now, this does imply that something in NUMA balancing ends up changing<br /> page protections (other than the obvious one of making the page<br /> inaccessible to get the NUMA faulting information). Otherwise the COW<br /> simplification wouldn&amp;#39;t matter - since doing the GUP on the page would<br /> make sure it&amp;#39;s writable.<br /> <br /> The cause of that permission change would be good to figure out too,<br /> since it clearly results in spurious COW events - but fixing the<br /> nonsensical test that just happened to work before is obviously the<br /> CorrectThing(tm) to do regardless.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/cio: verify the driver availability for path_event call<br /> <br /> If no driver is attached to a device or the driver does not provide the<br /> path_event function, an FCES path-event on this device could end up in a<br /> kernel-panic. Verify the driver availability before the path_event<br /> function call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix list corruption in perf_cgroup_switch()<br /> <br /> There&amp;#39;s list corruption on cgrp_cpuctx_list. This happens on the<br /> following path:<br /> <br /> perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list)<br /> cpu_ctx_sched_in<br /> ctx_sched_in<br /> ctx_pinned_sched_in<br /> merge_sched_in<br /> perf_cgroup_event_disable: remove the event from the list<br /> <br /> Use list_for_each_entry_safe() to allow removing an entry during<br /> iteration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: vmscan: remove deadlock due to throttling failing to make progress<br /> <br /> A soft lockup bug in kcompactd was reported in a private bugzilla with<br /> the following visible in dmesg;<br /> <br /> watchdog: BUG: soft lockup - CPU#33 stuck for 26s! [kcompactd0:479]<br /> watchdog: BUG: soft lockup - CPU#33 stuck for 52s! [kcompactd0:479]<br /> watchdog: BUG: soft lockup - CPU#33 stuck for 78s! [kcompactd0:479]<br /> watchdog: BUG: soft lockup - CPU#33 stuck for 104s! [kcompactd0:479]<br /> <br /> The machine had 256G of RAM with no swap and an earlier failed<br /> allocation indicated that node 0 where kcompactd was run was potentially<br /> unreclaimable;<br /> <br /> Node 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB<br /> inactive_file:0kB unevictable:64kB isolated(anon):0kB isolated(file):0kB<br /> mapped:8kB dirty:0kB writeback:0kB shmem:26780kB shmem_thp:<br /> 0kB shmem_pmdmapped: 0kB anon_thp: 23480320kB writeback_tmp:0kB<br /> kernel_stack:2272kB pagetables:24500kB all_unreclaimable? yes<br /> <br /> Vlastimil Babka investigated a crash dump and found that a task<br /> migrating pages was trying to drain PCP lists;<br /> <br /> PID: 52922 TASK: ffff969f820e5000 CPU: 19 COMMAND: "kworker/u128:3"<br /> Call Trace:<br /> __schedule<br /> schedule<br /> schedule_timeout<br /> wait_for_completion<br /> __flush_work<br /> __drain_all_pages<br /> __alloc_pages_slowpath.constprop.114<br /> __alloc_pages<br /> alloc_migration_target<br /> migrate_pages<br /> migrate_to_node<br /> do_migrate_pages<br /> cpuset_migrate_mm_workfn<br /> process_one_work<br /> worker_thread<br /> kthread<br /> ret_from_fork<br /> <br /> This failure is specific to CONFIG_PREEMPT=n builds. The root of the<br /> problem is that kcompact0 is not rescheduling on a CPU while a task that<br /> has isolated a large number of the pages from the LRU is waiting on<br /> kcompact0 to reschedule so the pages can be released. While<br /> shrink_inactive_list() only loops once around too_many_isolated, reclaim<br /> can continue without rescheduling if sc-&gt;skipped_deactivate == 1 which<br /> could happen if there was no file LRU and the inactive anon list was not<br /> low.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: buffer: Fix file related error handling in IIO_BUFFER_GET_FD_IOCTL<br /> <br /> If we fail to copy the just created file descriptor to userland, we<br /> try to clean up by putting back &amp;#39;fd&amp;#39; and freeing &amp;#39;ib&amp;#39;. The code uses<br /> put_unused_fd() for the former which is wrong, as the file descriptor<br /> was already published by fd_install() which gets called internally by<br /> anon_inode_getfd().<br /> <br /> This makes the error handling code leaving a half cleaned up file<br /> descriptor table around and a partially destructed &amp;#39;file&amp;#39; object,<br /> allowing userland to play use-after-free tricks on us, by abusing<br /> the still usable fd and making the code operate on a dangling<br /> &amp;#39;file-&gt;private_data&amp;#39; pointer.<br /> <br /> Instead of leaving the kernel in a partially corrupted state, don&amp;#39;t<br /> attempt to explicitly clean up and leave this to the process exit<br /> path that&amp;#39;ll release any still valid fds, including the one created<br /> by the previous call to anon_inode_getfd(). Simply return -EFAULT to<br /> indicate the error.