Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: do not delay dst_entries_add() in dst_release()<br /> <br /> dst_entries_add() uses per-cpu data that might be freed at netns<br /> dismantle from ip6_route_net_exit() calling dst_entries_destroy()<br /> <br /> Before ip6_route_net_exit() can be called, we release all<br /> the dsts associated with this netns, via calls to dst_release(),<br /> which waits an rcu grace period before calling dst_destroy()<br /> <br /> dst_entries_add() use in dst_destroy() is racy, because<br /> dst_entries_destroy() could have been called already.<br /> <br /> Decrementing the number of dsts must happen sooner.<br /> <br /> Notes:<br /> <br /> 1) in CONFIG_XFRM case, dst_destroy() can call<br /> dst_release_immediate(child), this might also cause UAF<br /> if the child does not have DST_NOCOUNT set.<br /> IPSEC maintainers might take a look and see how to address this.<br /> <br /> 2) There is also discussion about removing this count of dst,<br /> which might happen in future kernels.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/fbdev-dma: Only cleanup deferred I/O if necessary<br /> <br /> Commit 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if<br /> necessary") initializes deferred I/O only if it is used.<br /> drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup()<br /> unconditionally with struct fb_info.fbdefio == NULL. KASAN with the<br /> out-of-tree Apple silicon display driver posts following warning from<br /> __flush_work() of a random struct work_struct instead of the expected<br /> NULL pointer derefs.<br /> <br /> [ 22.053799] ------------[ cut here ]------------<br /> [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580<br /> [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram<br /> [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev<br /> [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT)<br /> [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 22.078567] pc : __flush_work+0x4d8/0x580<br /> [ 22.079471] lr : __flush_work+0x54/0x580<br /> [ 22.080345] sp : ffffc000836ef820<br /> [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128<br /> [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358<br /> [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470<br /> [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000<br /> [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005<br /> [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000<br /> [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e<br /> [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001<br /> [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020<br /> [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000<br /> [ 22.096955] Call trace:<br /> [ 22.097505] __flush_work+0x4d8/0x580<br /> [ 22.098330] flush_delayed_work+0x80/0xb8<br /> [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130<br /> [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper]<br /> [ 22.101559] unregister_framebuffer+0x210/0x2f0<br /> [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60<br /> [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper]<br /> [ 22.105147] drm_client_dev_unregister+0x1cc/0x230<br /> [ 22.106217] drm_dev_unregister+0x58/0x570<br /> [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm]<br /> [ 22.108199] component_del+0x1f8/0x3a8<br /> [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp]<br /> [ 22.110357] platform_shutdown+0x70/0x90<br /> [ 22.111219] device_shutdown+0x368/0x4d8<br /> [ 22.112095] kernel_restart+0x6c/0x1d0<br /> [ 22.112946] __arm64_sys_reboot+0x1c8/0x328<br /> [ 22.113868] invoke_syscall+0x78/0x1a8<br /> [ 22.114703] do_el0_svc+0x124/0x1a0<br /> [ 22.115498] el0_svc+0x3c/0xe0<br /> [ 22.116181] el0t_64_sync_handler+0x70/0xc0<br /> [ 22.117110] el0t_64_sync+0x190/0x198<br /> [ 22.117931] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xtables: avoid NFPROTO_UNSPEC where needed<br /> <br /> syzbot managed to call xt_cluster match via ebtables:<br /> <br /> WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780<br /> [..]<br /> ebt_do_table+0x174b/0x2a40<br /> <br /> Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet<br /> processing. As this is only useful to restrict locally terminating<br /> TCP/UDP traffic, register this for ipv4 and ipv6 family only.<br /> <br /> Pablo points out that this is a general issue, direct users of the<br /> set/getsockopt interface can call into targets/matches that were only<br /> intended for use with ip(6)tables.<br /> <br /> Check all UNSPEC matches and targets for similar issues:<br /> <br /> - matches and targets are fine except if they assume skb_network_header()<br /> is valid -- this is only true when called from inet layer: ip(6) stack<br /> pulls the ip/ipv6 header into linear data area.<br /> - targets that return XT_CONTINUE or other xtables verdicts must be<br /> restricted too, they are incompatbile with the ebtables traverser, e.g.<br /> EBT_CONTINUE is a completely different value than XT_CONTINUE.<br /> <br /> Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as<br /> they are provided for use by ip(6)tables.<br /> <br /> The MARK target is also used by arptables, so register for NFPROTO_ARP too.<br /> <br /> While at it, bail out if connbytes fails to enable the corresponding<br /> conntrack family.<br /> <br /> This change passes the selftests in iptables.git.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: accept TCA_STAB only for root qdisc<br /> <br /> Most qdiscs maintain their backlog using qdisc_pkt_len(skb)<br /> on the assumption it is invariant between the enqueue()<br /> and dequeue() handlers.<br /> <br /> Unfortunately syzbot can crash a host rather easily using<br /> a TBF + SFQ combination, with an STAB on SFQ [1]<br /> <br /> We can&amp;#39;t support TCA_STAB on arbitrary level, this would<br /> require to maintain per-qdisc storage.<br /> <br /> [1]<br /> [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 88.798611] #PF: supervisor read access in kernel mode<br /> [ 88.799014] #PF: error_code(0x0000) - not-present page<br /> [ 88.799506] PGD 0 P4D 0<br /> [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117<br /> [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq<br /> [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00<br /> All code<br /> ========<br /> 0: 0f b7 50 12 movzwl 0x12(%rax),%edx<br /> 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax<br /> b: 00<br /> c: 48 89 d6 mov %rdx,%rsi<br /> f: 48 29 d0 sub %rdx,%rax<br /> 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx<br /> 19: 48 c1 e0 03 shl $0x3,%rax<br /> 1d: 48 01 c2 add %rax,%rdx<br /> 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx)<br /> 25: 7e c0 jle 0xffffffffffffffe7<br /> 27: 48 8b 3a mov (%rdx),%rdi<br /> 2a:* 4c 8b 07 mov (%rdi),%r8

In Minecraft mod "Command Block IDE" up to and including version 0.4.9, a missing authorization (CWE-862) allows any user to modify "function" files used by the game when installed on a dedicated server.

An issue in DCME-320-L

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kthread: unpark only parked kthread<br /> <br /> Calling into kthread unparking unconditionally is mostly harmless when<br /> the kthread is already unparked. The wake up is then simply ignored<br /> because the target is not in TASK_PARKED state.<br /> <br /> However if the kthread is per CPU, the wake up is preceded by a call<br /> to kthread_bind() which expects the task to be inactive and in<br /> TASK_PARKED state, which obviously isn&amp;#39;t the case if it is unparked.<br /> <br /> As a result, calling kthread_stop() on an unparked per-cpu kthread<br /> triggers such a warning:<br /> <br /> WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525<br /> <br /> kthread_stop+0x17a/0x630 kernel/kthread.c:707<br /> destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810<br /> wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257<br /> netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693<br /> default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769<br /> ops_exit_list net/core/net_namespace.c:178 [inline]<br /> cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640<br /> process_one_work kernel/workqueue.c:3231 [inline]<br /> process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312<br /> worker_thread+0x86d/0xd70 kernel/workqueue.c:3393<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> Fix this with skipping unecessary unparking while stopping a kthread.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()<br /> <br /> This patch addresses an issue with improper reference count handling in the<br /> ice_sriov_set_msix_vec_count() function.<br /> <br /> First, the function calls ice_get_vf_by_id(), which increments the<br /> reference count of the vf pointer. If the subsequent call to<br /> ice_get_vf_vsi() fails, the function currently returns an error without<br /> decrementing the reference count of the vf pointer, leading to a reference<br /> count leak. The correct behavior, as implemented in this patch, is to<br /> decrement the reference count using ice_put_vf(vf) before returning an<br /> error when vsi is NULL.<br /> <br /> Second, the function calls ice_sriov_get_irqs(), which sets<br /> vf-&gt;first_vector_idx. If this call returns a negative value, indicating an<br /> error, the function returns an error without decrementing the reference<br /> count of the vf pointer, resulting in another reference count leak. The<br /> patch addresses this by adding a call to ice_put_vf(vf) before returning<br /> an error when vf-&gt;first_vector_idx

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()<br /> <br /> This patch addresses a reference count handling issue in the<br /> ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(),<br /> which increments the reference count of the relevant resources. However,<br /> if the condition WARN_ON((!vsi || !vsi-&gt;netdev)) is met, the function<br /> currently returns an error without properly releasing the resources<br /> acquired by ice_dpll_get_pins(), leading to a reference count leak.<br /> <br /> To resolve this, the check has been moved to the top of the function. This<br /> ensures that the function verifies the state before any resources are<br /> acquired, avoiding the need for additional resource management in the<br /> error path.<br /> <br /> This bug was identified by an experimental static analysis tool developed<br /> by our team. The tool specializes in analyzing reference count operations<br /> and detecting potential issues where resources are not properly managed.<br /> In this case, the tool flagged the missing release operation as a<br /> potential problem, which led to the development of this patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> device-dax: correct pgoff align in dax_set_mapping()<br /> <br /> pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise,<br /> vmf-&gt;address not aligned to fault_size will be aligned to the next<br /> alignment, that can result in memory failure getting the wrong address.<br /> <br /> It&amp;#39;s a subtle situation that only can be observed in<br /> page_mapped_in_vma() after the page is page fault handled by<br /> dev_dax_huge_fault. Generally, there is little chance to perform<br /> page_mapped_in_vma in dev-dax&amp;#39;s page unless in specific error injection<br /> to the dax device to trigger an MCE - memory-failure. In that case,<br /> page_mapped_in_vma() will be triggered to determine which task is<br /> accessing the failure address and kill that task in the end.<br /> <br /> <br /> We used self-developed dax device (which is 2M aligned mapping) , to<br /> perform error injection to random address. It turned out that error<br /> injected to non-2M-aligned address was causing endless MCE until panic.<br /> Because page_mapped_in_vma() kept resulting wrong address and the task<br /> accessing the failure address was never killed properly:<br /> <br /> <br /> [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3784.049006] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3784.448042] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3784.792026] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3785.162502] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3785.461116] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3785.764730] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3786.042128] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3786.464293] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3786.818090] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> [ 3787.085297] mce: Uncorrected hardware memory error in user-access at <br /> 200c9742380<br /> [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: <br /> Recovered<br /> <br /> It took us several weeks to pinpoint this problem,  but we eventually<br /> used bpftrace to trace the page fault and mce address and successfully<br /> identified the issue.<br /> <br /> <br /> Joao added:<br /> <br /> ; Likely we never reproduce in production because we always pin<br /> : device-dax regions in the region align they provide (Qemu does<br /> : similarly with prealloc in hugetlb/file backed memory). I think this<br /> : bug requires that we touch *unpinned* device-dax regions unaligned to<br /> : the device-dax selected alignment (page size i.e. 4K/2M/1G)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: Remove LED entry from LEDs list on unregister<br /> <br /> Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct<br /> ordering") correctly fixed a problem with using devm_ but missed<br /> removing the LED entry from the LEDs list.<br /> <br /> This cause kernel panic on specific scenario where the port for the PHY<br /> is torn down and up and the kmod for the PHY is removed.<br /> <br /> On setting the port down the first time, the assosiacted LEDs are<br /> correctly unregistered. The associated kmod for the PHY is now removed.<br /> The kmod is now added again and the port is now put up, the associated LED<br /> are registered again.<br /> On putting the port down again for the second time after these step, the<br /> LED list now have 4 elements. With the first 2 already unregistered<br /> previously and the 2 new one registered again.<br /> <br /> This cause a kernel panic as the first 2 element should have been<br /> removed.<br /> <br /> Fix this by correctly removing the element when LED is unregistered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Fix an unsafe loop on the list<br /> <br /> The kernel may crash when deleting a genetlink family if there are still<br /> listeners for that family:<br /> <br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> ...<br /> NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0<br /> LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0<br /> Call Trace:<br /> __netlink_clear_multicast_users+0x74/0xc0<br /> genl_unregister_family+0xd4/0x2d0<br /> <br /> Change the unsafe loop on the list to a safe one, because inside the<br /> loop there is an element removal from this list.