Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folio<br /> <br /> Commit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages to<br /> be offlined) add page poison checks in do_migrate_range in order to make<br /> offline hwpoisoned page possible by introducing isolate_lru_page and<br /> try_to_unmap for hwpoisoned page. However folio lock must be held before<br /> calling try_to_unmap. Add it to fix this problem.<br /> <br /> Warning will be produced if folio is not locked during unmap:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at ./include/linux/swapops.h:400!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015<br /> pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : try_to_unmap_one+0xb08/0xd3c<br /> lr : try_to_unmap_one+0x3dc/0xd3c<br /> Call trace:<br /> try_to_unmap_one+0xb08/0xd3c (P)<br /> try_to_unmap_one+0x3dc/0xd3c (L)<br /> rmap_walk_anon+0xdc/0x1f8<br /> rmap_walk+0x3c/0x58<br /> try_to_unmap+0x88/0x90<br /> unmap_poisoned_folio+0x30/0xa8<br /> do_migrate_range+0x4a0/0x568<br /> offline_pages+0x5a4/0x670<br /> memory_block_action+0x17c/0x374<br /> memory_subsys_offline+0x3c/0x78<br /> device_offline+0xa4/0xd0<br /> state_store+0x8c/0xf0<br /> dev_attr_store+0x18/0x2c<br /> sysfs_kf_write+0x44/0x54<br /> kernfs_fop_write_iter+0x118/0x1a8<br /> vfs_write+0x3a8/0x4bc<br /> ksys_write+0x6c/0xf8<br /> __arm64_sys_write+0x1c/0x28<br /> invoke_syscall+0x44/0x100<br /> el0_svc_common.constprop.0+0x40/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x30/0xd0<br /> el0t_64_sync_handler+0xc8/0xcc<br /> el0t_64_sync+0x198/0x19c<br /> Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000)<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethtool: netlink: Allow NULL nlattrs when getting a phy_device<br /> <br /> ethnl_req_get_phydev() is used to lookup a phy_device, in the case an<br /> ethtool netlink command targets a specific phydev within a netdev&amp;#39;s<br /> topology.<br /> <br /> It takes as a parameter a const struct nlattr *header that&amp;#39;s used for<br /> error handling :<br /> <br /> if (!phydev) {<br /> NL_SET_ERR_MSG_ATTR(extack, header,<br /> "no phy matching phyindex");<br /> return ERR_PTR(-ENODEV);<br /> }<br /> <br /> In the notify path after a -&gt;set operation however, there&amp;#39;s no request<br /> attributes available.<br /> <br /> The typical callsite for the above function looks like:<br /> <br /> phydev = ethnl_req_get_phydev(req_base, tb[ETHTOOL_A_XXX_HEADER],<br /> info-&gt;extack);<br /> <br /> So, when tb is NULL (such as in the ethnl notify path), we have a nice<br /> crash.<br /> <br /> It turns out that there&amp;#39;s only the PLCA command that is in that case, as<br /> the other phydev-specific commands don&amp;#39;t have a notification.<br /> <br /> This commit fixes the crash by passing the cmd index and the nlattr<br /> array separately, allowing NULL-checking it directly inside the helper.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cdx: Fix possible UAF error in driver_override_show()<br /> <br /> Fixed a possible UAF problem in driver_override_show() in drivers/cdx/cdx.c<br /> <br /> This function driver_override_show() is part of DEVICE_ATTR_RW, which<br /> includes both driver_override_show() and driver_override_store().<br /> These functions can be executed concurrently in sysfs.<br /> <br /> The driver_override_store() function uses driver_set_override() to<br /> update the driver_override value, and driver_set_override() internally<br /> locks the device (device_lock(dev)). If driver_override_show() reads<br /> cdx_dev-&gt;driver_override without locking, it could potentially access<br /> a freed pointer if driver_override_store() frees the string<br /> concurrently. This could lead to printing a kernel address, which is a<br /> security risk since DEVICE_ATTR can be read by all users.<br /> <br /> Additionally, a similar pattern is used in drivers/amba/bus.c, as well<br /> as many other bus drivers, where device_lock() is taken in the show<br /> function, and it has been working without issues.<br /> <br /> This potential bug was detected by our experimental static analysis<br /> tool, which analyzes locking APIs and paired functions to identify<br /> data races and atomicity violations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: atm: cxacru: fix a flaw in existing endpoint checks<br /> <br /> Syzbot once again identified a flaw in usb endpoint checking, see [1].<br /> This time the issue stems from a commit authored by me (2eabb655a968<br /> ("usb: atm: cxacru: fix endpoint checking in cxacru_bind()")).<br /> <br /> While using usb_find_common_endpoints() may usually be enough to<br /> discard devices with wrong endpoints, in this case one needs more<br /> than just finding and identifying the sufficient number of endpoints<br /> of correct types - one needs to check the endpoint&amp;#39;s address as well.<br /> <br /> Since cxacru_bind() fills URBs with CXACRU_EP_CMD address in mind,<br /> switch the endpoint verification approach to usb_check_XXX_endpoints()<br /> instead to fix incomplete ep testing.<br /> <br /> [1] Syzbot report:<br /> usb 5-1: BOGUS urb xfer, pipe 3 != type 1<br /> WARNING: CPU: 0 PID: 1378 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503<br /> ...<br /> RIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503<br /> ...<br /> Call Trace:<br /> <br /> cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649<br /> cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline]<br /> cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223<br /> usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058<br /> cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377<br /> usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396<br /> really_probe+0x2b9/0xad0 drivers/base/dd.c:658<br /> __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800<br /> driver_probe_device+0x50/0x430 drivers/base/dd.c:830<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: renesas_usbhs: Flush the notify_hotplug_work<br /> <br /> When performing continuous unbind/bind operations on the USB drivers<br /> available on the Renesas RZ/G2L SoC, a kernel crash with the message<br /> "Unable to handle kernel NULL pointer dereference at virtual address"<br /> may occur. This issue points to the usbhsc_notify_hotplug() function.<br /> <br /> Flush the delayed work to avoid its execution when driver resources are<br /> unavailable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: Fix NULL pointer access<br /> <br /> Resources should be released only after all threads that utilize them<br /> have been destroyed.<br /> This commit ensures that resources are not released prematurely by waiting<br /> for the associated workqueue to complete before deallocating them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Fix potential memory corruption in child_cfs_rq_on_list<br /> <br /> child_cfs_rq_on_list attempts to convert a &amp;#39;prev&amp;#39; pointer to a cfs_rq.<br /> This &amp;#39;prev&amp;#39; pointer can originate from struct rq&amp;#39;s leaf_cfs_rq_list,<br /> making the conversion invalid and potentially leading to memory<br /> corruption. Depending on the relative positions of leaf_cfs_rq_list and<br /> the task group (tg) pointer within the struct, this can cause a memory<br /> fault or access garbage data.<br /> <br /> The issue arises in list_add_leaf_cfs_rq, where both<br /> cfs_rq-&gt;leaf_cfs_rq_list and rq-&gt;leaf_cfs_rq_list are added to the same<br /> leaf list. Also, rq-&gt;tmp_alone_branch can be set to rq-&gt;leaf_cfs_rq_list.<br /> <br /> This adds a check `if (prev == &amp;rq-&gt;leaf_cfs_rq_list)` after the main<br /> conditional in child_cfs_rq_on_list. This ensures that the container_of<br /> operation will convert a correct cfs_rq struct.<br /> <br /> This check is sufficient because only cfs_rqs on the same CPU are added<br /> to the list, so verifying the &amp;#39;prev&amp;#39; pointer against the current rq&amp;#39;s list<br /> head is enough.<br /> <br /> Fixes a potential memory corruption issue that due to current struct<br /> layout might not be manifesting as a crash but could lead to unpredictable<br /> behavior when the layout changes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vlan: enforce underlying device type<br /> <br /> Currently, VLAN devices can be created on top of non-ethernet devices.<br /> <br /> Besides the fact that it doesn&amp;#39;t make much sense, this also causes a<br /> bug which leaks the address of a kernel function to usermode.<br /> <br /> When creating a VLAN device, we initialize GARP (garp_init_applicant)<br /> and MRP (mrp_init_applicant) for the underlying device.<br /> <br /> As part of the initialization process, we add the multicast address of<br /> each applicant to the underlying device, by calling dev_mc_add.<br /> <br /> __dev_mc_add uses dev-&gt;addr_len to determine the length of the new<br /> multicast address.<br /> <br /> This causes an out-of-bounds read if dev-&gt;addr_len is greater than 6,<br /> since the multicast addresses provided by GARP and MRP are only 6<br /> bytes long.<br /> <br /> This behaviour can be reproduced using the following commands:<br /> <br /> ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo<br /> ip l set up dev gretest<br /> ip link add link gretest name vlantest type vlan id 100<br /> <br /> Then, the following command will display the address of garp_pdu_rcv:<br /> <br /> ip maddr show | grep 01:80:c2:00:00:21<br /> <br /> Fix the bug by enforcing the type of the underlying device during VLAN<br /> device initialization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: Fix KMSAN uninit-value warning with bpf<br /> <br /> Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the<br /> ppp driver not initializing a 2-byte header when using socket filter.<br /> <br /> The following code can generate a PPP filter BPF program:<br /> &amp;#39;&amp;#39;&amp;#39;<br /> struct bpf_program fp;<br /> pcap_t *handle;<br /> handle = pcap_open_dead(DLT_PPP_PPPD, 65535);<br /> pcap_compile(handle, &amp;fp, "ip and outbound", 0, 0);<br /> bpf_dump(&amp;fp, 1);<br /> &amp;#39;&amp;#39;&amp;#39;<br /> Its output is:<br /> &amp;#39;&amp;#39;&amp;#39;<br /> (000) ldh [2]<br /> (001) jeq #0x21 jt 2 jf 5<br /> (002) ldb [0]<br /> (003) jeq #0x1 jt 4 jf 5<br /> (004) ret #65535<br /> (005) ret #0<br /> &amp;#39;&amp;#39;&amp;#39;<br /> Wen can find similar code at the following link:<br /> https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680<br /> The maintainer of this code repository is also the original maintainer<br /> of the ppp driver.<br /> <br /> As you can see the BPF program skips 2 bytes of data and then reads the<br /> &amp;#39;Protocol&amp;#39; field to determine if it&amp;#39;s an IP packet. Then it read the first<br /> byte of the first 2 bytes to determine the direction.<br /> <br /> The issue is that only the first byte indicating direction is initialized<br /> in current ppp driver code while the second byte is not initialized.<br /> <br /> For normal BPF programs generated by libpcap, uninitialized data won&amp;#39;t be<br /> used, so it&amp;#39;s not a problem. However, for carefully crafted BPF programs,<br /> such as those generated by syzkaller [2], which start reading from offset<br /> 0, the uninitialized data will be used and caught by KMSAN.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791<br /> [2] https://syzkaller.appspot.com/text?tag=ReproC&amp;x=11994913980000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: clean up ROC on failure<br /> <br /> If the firmware fails to start the session protection, then we<br /> do call iwl_mvm_roc_finished() here, but that won&amp;#39;t do anything<br /> at all because IWL_MVM_STATUS_ROC_P2P_RUNNING was never set.<br /> Set IWL_MVM_STATUS_ROC_P2P_RUNNING in the failure/stop path.<br /> If it started successfully before, it&amp;#39;s already set, so that<br /> doesn&amp;#39;t matter, and if it didn&amp;#39;t start it needs to be set to<br /> clean up.<br /> <br /> Not doing so will lead to a WARN_ON() later on a fresh remain-<br /> on-channel, since the link is already active when activated as<br /> it was never deactivated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: memory-failure: update ttu flag inside unmap_poisoned_folio<br /> <br /> Patch series "mm: memory_failure: unmap poisoned folio during migrate<br /> properly", v3.<br /> <br /> Fix two bugs during folio migration if the folio is poisoned.<br /> <br /> <br /> This patch (of 3):<br /> <br /> Commit 6da6b1d4a7df ("mm/hwpoison: convert TTU_IGNORE_HWPOISON to<br /> TTU_HWPOISON") introduce TTU_HWPOISON to replace TTU_IGNORE_HWPOISON in<br /> order to stop send SIGBUS signal when accessing an error page after a<br /> memory error on a clean folio. However during page migration, anon folio<br /> must be set with TTU_HWPOISON during unmap_*(). For pagecache we need<br /> some policy just like the one in hwpoison_user_mappings to set this flag. <br /> So move this policy from hwpoison_user_mappings to unmap_poisoned_folio to<br /> handle this warning properly.<br /> <br /> Warning will be produced during unamp poison folio with the following log:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 365 at mm/rmap.c:1847 try_to_unmap_one+0x8fc/0xd3c<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 365 Comm: bash Tainted: G W 6.13.0-rc1-00018-gacdb4bbda7ab #42<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015<br /> pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : try_to_unmap_one+0x8fc/0xd3c<br /> lr : try_to_unmap_one+0x3dc/0xd3c<br /> Call trace:<br /> try_to_unmap_one+0x8fc/0xd3c (P)<br /> try_to_unmap_one+0x3dc/0xd3c (L)<br /> rmap_walk_anon+0xdc/0x1f8<br /> rmap_walk+0x3c/0x58<br /> try_to_unmap+0x88/0x90<br /> unmap_poisoned_folio+0x30/0xa8<br /> do_migrate_range+0x4a0/0x568<br /> offline_pages+0x5a4/0x670<br /> memory_block_action+0x17c/0x374<br /> memory_subsys_offline+0x3c/0x78<br /> device_offline+0xa4/0xd0<br /> state_store+0x8c/0xf0<br /> dev_attr_store+0x18/0x2c<br /> sysfs_kf_write+0x44/0x54<br /> kernfs_fop_write_iter+0x118/0x1a8<br /> vfs_write+0x3a8/0x4bc<br /> ksys_write+0x6c/0xf8<br /> __arm64_sys_write+0x1c/0x28<br /> invoke_syscall+0x44/0x100<br /> el0_svc_common.constprop.0+0x40/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x30/0xd0<br /> el0t_64_sync_handler+0xc8/0xcc<br /> el0t_64_sync+0x198/0x19c<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> [mawupeng1@huawei.com: unmap_poisoned_folio(): remove shadowed local `mapping&amp;#39;, per Miaohe]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: fix nfs_release_folio() to not deadlock via kcompactd writeback<br /> <br /> Add PF_KCOMPACTD flag and current_is_kcompactd() helper to check for it so<br /> nfs_release_folio() can skip calling nfs_wb_folio() from kcompactd.<br /> <br /> Otherwise NFS can deadlock waiting for kcompactd enduced writeback which<br /> recurses back to NFS (which triggers writeback to NFSD via NFS loopback<br /> mount on the same host, NFSD blocks waiting for XFS&amp;#39;s call to<br /> __filemap_get_folio):<br /> <br /> 6070.550357] INFO: task kcompactd0:58 blocked for more than 4435 seconds.<br /> <br /> {---<br /> [58] "kcompactd0"<br /> [] folio_wait_bit+0xe8/0x200<br /> [] folio_wait_writeback+0x2b/0x80<br /> [] nfs_wb_folio+0x80/0x1b0 [nfs]<br /> [] nfs_release_folio+0x68/0x130 [nfs]<br /> [] split_huge_page_to_list_to_order+0x362/0x840<br /> [] migrate_pages_batch+0x43d/0xb90<br /> [] migrate_pages_sync+0x9a/0x240<br /> [] migrate_pages+0x93c/0x9f0<br /> [] compact_zone+0x8e2/0x1030<br /> [] compact_node+0xdb/0x120<br /> [] kcompactd+0x121/0x2e0<br /> [] kthread+0xcf/0x100<br /> [] ret_from_fork+0x31/0x40<br /> [] ret_from_fork_asm+0x1a/0x30<br /> ---}<br /> <br /> [akpm@linux-foundation.org: fix build]