Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gso: fix ownership in __udp_gso_segment<br /> <br /> In __udp_gso_segment the skb destructor is removed before segmenting the<br /> skb but the socket reference is kept as-is. This is an issue if the<br /> original skb is later orphaned as we can hit the following bug:<br /> <br /> kernel BUG at ./include/linux/skbuff.h:3312! (skb_orphan)<br /> RIP: 0010:ip_rcv_core+0x8b2/0xca0<br /> Call Trace:<br /> ip_rcv+0xab/0x6e0<br /> __netif_receive_skb_one_core+0x168/0x1b0<br /> process_backlog+0x384/0x1100<br /> __napi_poll.constprop.0+0xa1/0x370<br /> net_rx_action+0x925/0xe50<br /> <br /> The above can happen following a sequence of events when using<br /> OpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes an<br /> OVS_ACTION_ATTR_OUTPUT action:<br /> <br /> 1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb<br /> goes through queue_gso_packets and then __udp_gso_segment, where its<br /> destructor is removed.<br /> 2. The segments&amp;#39; data are copied and sent to userspace.<br /> 3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the<br /> same original skb is sent to its path.<br /> 4. If it later hits skb_orphan, we hit the bug.<br /> <br /> Fix this by also removing the reference to the socket in<br /> __udp_gso_segment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()<br /> <br /> The system can experience a random crash a few minutes after the driver is<br /> removed. This issue occurs due to improper handling of memory freeing in<br /> the ishtp_hid_remove() function.<br /> <br /> The function currently frees the `driver_data` directly within the loop<br /> that destroys the HID devices, which can lead to accessing freed memory.<br /> Specifically, `hid_destroy_device()` uses `driver_data` when it calls<br /> `hid_ishtp_set_feature()` to power off the sensor, so freeing<br /> `driver_data` beforehand can result in accessing invalid memory.<br /> <br /> This patch resolves the issue by storing the `driver_data` in a temporary<br /> variable before calling `hid_destroy_device()`, and then freeing the<br /> `driver_data` after the device is destroyed.

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.