Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-fc: avoid deadlock on delete association path<br /> <br /> When deleting an association the shutdown path is deadlocking because we<br /> try to flush the nvmet_wq nested. Avoid this by deadlock by deferring<br /> the put work into its own work item.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]<br /> <br /> With default config, the value of NR_CPUS is 64. When HW platform has<br /> more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC<br /> is the maximum cpu number in MADT table (max physical number) which can<br /> exceed the supported maximum cpu number (NR_CPUS, max logical number),<br /> but kernel should not crash. Kernel should boot cpus with NR_CPUS, let<br /> the remainder cpus stay in BIOS.<br /> <br /> The potential crash reason is that the array acpi_core_pic[NR_CPUS] can<br /> be overflowed when parsing MADT table, and it is obvious that CORE_PIC<br /> should be corresponding to physical core rather than logical core, so it<br /> is better to define the array as acpi_core_pic[MAX_CORE_PIC].<br /> <br /> With the patch, system can boot up 64 vcpus with qemu parameter -smp 128,<br /> otherwise system will crash with the following message.<br /> <br /> [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000420000004259, era == 90000000037a5f0c, ra == 90000000037a46ec<br /> [ 0.000000] Oops[#1]:<br /> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.8.0-rc2+ #192<br /> [ 0.000000] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022<br /> [ 0.000000] pc 90000000037a5f0c ra 90000000037a46ec tp 9000000003c90000 sp 9000000003c93d60<br /> [ 0.000000] a0 0000000000000019 a1 9000000003d93bc0 a2 0000000000000000 a3 9000000003c93bd8<br /> [ 0.000000] a4 9000000003c93a74 a5 9000000083c93a67 a6 9000000003c938f0 a7 0000000000000005<br /> [ 0.000000] t0 0000420000004201 t1 0000000000000000 t2 0000000000000001 t3 0000000000000001<br /> [ 0.000000] t4 0000000000000003 t5 0000000000000000 t6 0000000000000030 t7 0000000000000063<br /> [ 0.000000] t8 0000000000000014 u0 ffffffffffffffff s9 0000000000000000 s0 9000000003caee98<br /> [ 0.000000] s1 90000000041b0480 s2 9000000003c93da0 s3 9000000003c93d98 s4 9000000003c93d90<br /> [ 0.000000] s5 9000000003caa000 s6 000000000a7fd000 s7 000000000f556b60 s8 000000000e0a4330<br /> [ 0.000000] ra: 90000000037a46ec platform_init+0x214/0x250<br /> [ 0.000000] ERA: 90000000037a5f0c efi_runtime_init+0x30/0x94<br /> [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE)<br /> [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)<br /> [ 0.000000] ECFG: 00070800 (LIE=11 VS=7)<br /> [ 0.000000] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)<br /> [ 0.000000] BADV: 0000420000004259<br /> [ 0.000000] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)<br /> [ 0.000000] Modules linked in:<br /> [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____))<br /> [ 0.000000] Stack : 9000000003c93a14 9000000003800898 90000000041844f8 90000000037a46ec<br /> [ 0.000000] 000000000a7fd000 0000000008290000 0000000000000000 0000000000000000<br /> [ 0.000000] 0000000000000000 0000000000000000 00000000019d8000 000000000f556b60<br /> [ 0.000000] 000000000a7fd000 000000000f556b08 9000000003ca7700 9000000003800000<br /> [ 0.000000] 9000000003c93e50 9000000003800898 9000000003800108 90000000037a484c<br /> [ 0.000000] 000000000e0a4330 000000000f556b60 000000000a7fd000 000000000f556b08<br /> [ 0.000000] 9000000003ca7700 9000000004184000 0000000000200000 000000000e02b018<br /> [ 0.000000] 000000000a7fd000 90000000037a0790 9000000003800108 0000000000000000<br /> [ 0.000000] 0000000000000000 000000000e0a4330 000000000f556b60 000000000a7fd000<br /> [ 0.000000] 000000000f556b08 000000000eaae298 000000000eaa5040 0000000000200000<br /> [ 0.000000] ...<br /> [ 0.000000] Call Trace:<br /> [ 0.000000] [] efi_runtime_init+0x30/0x94<br /> [ 0.000000] [] platform_init+0x214/0x250<br /> [ 0.000000] [] setup_arch+0x124/0x45c<br /> [ 0.000000] [] start_kernel+0x90/0x670<br /> [ 0.000000] [] kernel_entry+0xd8/0xdc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: Don&amp;#39;t ignore suspended array in md_check_recovery()<br /> <br /> mddev_suspend() never stop sync_thread, hence it doesn&amp;#39;t make sense to<br /> ignore suspended array in md_check_recovery(), which might cause<br /> sync_thread can&amp;#39;t be unregistered.<br /> <br /> After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following<br /> hang can be triggered by test shell/integrity-caching.sh:<br /> <br /> 1) suspend the array:<br /> raid_postsuspend<br /> mddev_suspend<br /> <br /> 2) stop the array:<br /> raid_dtr<br /> md_stop<br /> __md_stop_writes<br /> stop_sync_thread<br /> set_bit(MD_RECOVERY_INTR, &amp;mddev-&gt;recovery);<br /> md_wakeup_thread_directly(mddev-&gt;sync_thread);<br /> wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &amp;mddev-&gt;recovery))<br /> <br /> 3) sync thread done:<br /> md_do_sync<br /> set_bit(MD_RECOVERY_DONE, &amp;mddev-&gt;recovery);<br /> md_wakeup_thread(mddev-&gt;thread);<br /> <br /> 4) daemon thread can&amp;#39;t unregister sync thread:<br /> md_check_recovery<br /> if (mddev-&gt;suspended)<br /> return; -&gt; return directly<br /> md_read_sync_thread<br /> clear_bit(MD_RECOVERY_RUNNING, &amp;mddev-&gt;recovery);<br /> -&gt; MD_RECOVERY_RUNNING can&amp;#39;t be cleared, hence step 2 hang;<br /> <br /> This problem is not just related to dm-raid, fix it by ignoring<br /> suspended array in md_check_recovery(). And follow up patches will<br /> improve dm-raid better to frozen sync thread during suspend.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: Don&amp;#39;t ignore read-only array in md_check_recovery()<br /> <br /> Usually if the array is not read-write, md_check_recovery() won&amp;#39;t<br /> register new sync_thread in the first place. And if the array is<br /> read-write and sync_thread is registered, md_set_readonly() will<br /> unregister sync_thread before setting the array read-only. md/raid<br /> follow this behavior hence there is no problem.<br /> <br /> After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following<br /> hang can be triggered by test shell/integrity-caching.sh:<br /> <br /> 1) array is read-only. dm-raid update super block:<br /> rs_update_sbs<br /> ro = mddev-&gt;ro<br /> mddev-&gt;ro = 0<br /> -&gt; set array read-write<br /> md_update_sb<br /> <br /> 2) register new sync thread concurrently.<br /> <br /> 3) dm-raid set array back to read-only:<br /> rs_update_sbs<br /> mddev-&gt;ro = ro<br /> <br /> 4) stop the array:<br /> raid_dtr<br /> md_stop<br /> stop_sync_thread<br /> set_bit(MD_RECOVERY_INTR, &amp;mddev-&gt;recovery);<br /> md_wakeup_thread_directly(mddev-&gt;sync_thread);<br /> wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &amp;mddev-&gt;recovery))<br /> <br /> 5) sync thread done:<br /> md_do_sync<br /> set_bit(MD_RECOVERY_DONE, &amp;mddev-&gt;recovery);<br /> md_wakeup_thread(mddev-&gt;thread);<br /> <br /> 6) daemon thread can&amp;#39;t unregister sync thread:<br /> md_check_recovery<br /> if (!md_is_rdwr(mddev) &amp;&amp;<br /> !test_bit(MD_RECOVERY_NEEDED, &amp;mddev-&gt;recovery))<br /> return;<br /> -&gt; -&gt; MD_RECOVERY_RUNNING can&amp;#39;t be cleared, hence step 4 hang;<br /> <br /> The root cause is that dm-raid manipulate &amp;#39;mddev-&gt;ro&amp;#39; by itself,<br /> however, dm-raid really should stop sync thread before setting the<br /> array read-only. Unfortunately, I need to read more code before I<br /> can refacter the handler of &amp;#39;mddev-&gt;ro&amp;#39; in dm-raid, hence let&amp;#39;s fix<br /> the problem the easy way for now to prevent dm-raid regression.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: Don&amp;#39;t suspend the array for interrupted reshape<br /> <br /> md_start_sync() will suspend the array if there are spares that can be<br /> added or removed from conf, however, if reshape is still in progress,<br /> this won&amp;#39;t happen at all or data will be corrupted(remove_and_add_spares<br /> won&amp;#39;t be called from md_choose_sync_action for reshape), hence there is<br /> no need to suspend the array if reshape is not done yet.<br /> <br /> Meanwhile, there is a potential deadlock for raid456:<br /> <br /> 1) reshape is interrupted;<br /> <br /> 2) set one of the disk WantReplacement, and add a new disk to the array,<br /> however, recovery won&amp;#39;t start until the reshape is finished;<br /> <br /> 3) then issue an IO across reshpae position, this IO will wait for<br /> reshape to make progress;<br /> <br /> 4) continue to reshape, then md_start_sync() found there is a spare disk<br /> that can be added to conf, mddev_suspend() is called;<br /> <br /> Step 4 and step 3 is waiting for each other, deadlock triggered. Noted<br /> this problem is found by code review, and it&amp;#39;s not reporduced yet.<br /> <br /> Fix this porblem by don&amp;#39;t suspend the array for interrupted reshape,<br /> this is safe because conf won&amp;#39;t be changed until reshape is done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/swap: fix race when skipping swapcache<br /> <br /> When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads<br /> swapin the same entry at the same time, they get different pages (A, B). <br /> Before one thread (T0) finishes the swapin and installs page (A) to the<br /> PTE, another thread (T1) could finish swapin of page (B), swap_free the<br /> entry, then swap out the possibly modified page reusing the same entry. <br /> It breaks the pte_same check in (T0) because PTE value is unchanged,<br /> causing ABA problem. Thread (T0) will install a stalled page (A) into the<br /> PTE and cause data corruption.<br /> <br /> One possible callstack is like this:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> do_swap_page() do_swap_page() with same entry<br /> <br /> <br /> swap_read_folio()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries/iommu: DLPAR add doesn&amp;#39;t completely initialize pci_controller<br /> <br /> When a PCI device is dynamically added, the kernel oopses with a NULL<br /> pointer dereference:<br /> <br /> BUG: Kernel NULL pointer dereference on read at 0x00000030<br /> Faulting instruction address: 0xc0000000006bbe5c<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse<br /> CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66<br /> Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries<br /> NIP: c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8<br /> REGS: c00000009924f240 TRAP: 0300 Not tainted (6.7.0-203405+)<br /> MSR: 8000000000009033 CR: 24002220 XER: 20040006<br /> CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0<br /> ...<br /> NIP sysfs_add_link_to_group+0x34/0x94<br /> LR iommu_device_link+0x5c/0x118<br /> Call Trace:<br /> iommu_init_device+0x26c/0x318 (unreliable)<br /> iommu_device_link+0x5c/0x118<br /> iommu_init_device+0xa8/0x318<br /> iommu_probe_device+0xc0/0x134<br /> iommu_bus_notifier+0x44/0x104<br /> notifier_call_chain+0xb8/0x19c<br /> blocking_notifier_call_chain+0x64/0x98<br /> bus_notify+0x50/0x7c<br /> device_add+0x640/0x918<br /> pci_device_add+0x23c/0x298<br /> of_create_pci_dev+0x400/0x884<br /> of_scan_pci_dev+0x124/0x1b0<br /> __of_scan_bus+0x78/0x18c<br /> pcibios_scan_phb+0x2a4/0x3b0<br /> init_phb_dynamic+0xb8/0x110<br /> dlpar_add_slot+0x170/0x3b8 [rpadlpar_io]<br /> add_slot_store.part.0+0xb4/0x130 [rpadlpar_io]<br /> kobj_attr_store+0x2c/0x48<br /> sysfs_kf_write+0x64/0x78<br /> kernfs_fop_write_iter+0x1b0/0x290<br /> vfs_write+0x350/0x4a0<br /> ksys_write+0x84/0x140<br /> system_call_exception+0x124/0x330<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> Commit a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities<br /> and allow blocking domains") broke DLPAR add of PCI devices.<br /> <br /> The above added iommu_device structure to pci_controller. During<br /> system boot, PCI devices are discovered and this newly added iommu_device<br /> structure is initialized by a call to iommu_device_register().<br /> <br /> During DLPAR add of a PCI device, a new pci_controller structure is<br /> allocated but there are no calls made to iommu_device_register()<br /> interface.<br /> <br /> Fix is to register the iommu device during DLPAR add as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devlink: fix possible use-after-free and memory leaks in devlink_init()<br /> <br /> The pernet operations structure for the subsystem must be registered<br /> before registering the generic netlink family.<br /> <br /> Make an unregister in case of unsuccessful registration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: fix memory double free when handle zero packet<br /> <br /> 829 if (request-&gt;complete) {<br /> 830 spin_unlock(&amp;priv_dev-&gt;lock);<br /> 831 usb_gadget_giveback_request(&amp;priv_ep-&gt;endpoint,<br /> 832 request);<br /> 833 spin_lock(&amp;priv_dev-&gt;lock);<br /> 834 }<br /> 835<br /> 836 if (request-&gt;buf == priv_dev-&gt;zlp_buf)<br /> 837 cdns3_gadget_ep_free_request(&amp;priv_ep-&gt;endpoint, request);<br /> <br /> Driver append an additional zero packet request when queue a packet, which<br /> length mod max packet size is 0. When transfer complete, run to line 831,<br /> usb_gadget_giveback_request() will free this requestion. 836 condition is<br /> true, so cdns3_gadget_ep_free_request() free this request again.<br /> <br /> Log:<br /> <br /> [ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]<br /> [ 1920.140696][ T150]<br /> [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):<br /> [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3]<br /> [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]<br /> <br /> Add check at line 829, skip call usb_gadget_giveback_request() if it is<br /> additional zero length packet request. Needn&amp;#39;t call<br /> usb_gadget_giveback_request() because it is allocated in this driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()<br /> <br /> ...<br /> cdns3_gadget_ep_free_request(&amp;priv_ep-&gt;endpoint, &amp;priv_req-&gt;request);<br /> list_del_init(&amp;priv_req-&gt;list);<br /> ...<br /> <br /> &amp;#39;priv_req&amp;#39; actually free at cdns3_gadget_ep_free_request(). But<br /> list_del_init() use priv_req-&gt;list after it.<br /> <br /> [ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4<br /> [ 1542.642868][ T534]<br /> [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):<br /> [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4<br /> [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]<br /> [ 1542.671571][ T534] usb_ep_disable+0x44/0xe4<br /> [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8<br /> [ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368<br /> [ 1542.685478][ T534] ffs_func_disable+0x18/0x28<br /> <br /> Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this<br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: sr: fix possible use-after-free and null-ptr-deref<br /> <br /> The pernet operations structure for the subsystem must be registered<br /> before registering the generic netlink family.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: pass correct message length to ip6_append_data<br /> <br /> l2tp_ip6_sendmsg needs to avoid accounting for the transport header<br /> twice when splicing more data into an already partially-occupied skbuff.<br /> <br /> To manage this, we check whether the skbuff contains data using<br /> skb_queue_empty when deciding how much data to append using<br /> ip6_append_data.<br /> <br /> However, the code which performed the calculation was incorrect:<br /> <br /> ulen = len + skb_queue_empty(&amp;sk-&gt;sk_write_queue) ? transhdrlen : 0;<br /> <br /> ...due to C operator precedence, this ends up setting ulen to<br /> transhdrlen for messages with a non-zero length, which results in<br /> corrupted packets on the wire.<br /> <br /> Add parentheses to correct the calculation in line with the original<br /> intent.