Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: xscale: Check for PTP support properly<br /> <br /> In ixp4xx_get_ts_info() ixp46x_ptp_find() is called<br /> unconditionally despite this feature only existing on<br /> ixp46x, leading to the following splat from tcpdump:<br /> <br /> root@OpenWrt:~# tcpdump -vv -X -i eth0<br /> (...)<br /> Unable to handle kernel NULL pointer dereference at virtual address<br /> 00000238 when read<br /> (...)<br /> Call trace:<br /> ptp_clock_index from ixp46x_ptp_find+0x1c/0x38<br /> ixp46x_ptp_find from ixp4xx_get_ts_info+0x4c/0x64<br /> ixp4xx_get_ts_info from __ethtool_get_ts_info+0x90/0x108<br /> __ethtool_get_ts_info from __dev_ethtool+0xa00/0x2648<br /> __dev_ethtool from dev_ethtool+0x160/0x234<br /> dev_ethtool from dev_ioctl+0x2cc/0x460<br /> dev_ioctl from sock_ioctl+0x1ec/0x524<br /> sock_ioctl from sys_ioctl+0x51c/0xa94<br /> sys_ioctl from ret_fast_syscall+0x0/0x44<br /> (...)<br /> Segmentation fault<br /> <br /> Check for ixp46x in ixp46x_ptp_find() before trying to set up<br /> PTP to avoid this.<br /> <br /> To avoid altering the returned error code from ixp4xx_hwtstamp_set()<br /> which before this patch was -EOPNOTSUPP, we return -EOPNOTSUPP<br /> from ixp4xx_hwtstamp_set() if ixp46x_ptp_find() fails no matter<br /> the error code. The helper function ixp46x_ptp_find() helper<br /> returns -ENODEV.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix post open error handling<br /> <br /> Closing a queue doesn&amp;#39;t guarantee that all associated page pools are<br /> terminated right away, let the refcounting do the work instead of<br /> releasing the zcrx ctx directly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: rs9: Reserve 8 struct clk_hw slots for for 9FGV0841<br /> <br /> The 9FGV0841 has 8 outputs and registers 8 struct clk_hw, make sure<br /> there are 8 slots for those newly registered clk_hw pointers, else<br /> there is going to be out of bounds write when pointers 4..7 are set<br /> into struct rs9_driver_data .clk_dif[4..7] field.<br /> <br /> Since there are other structure members past this struct clk_hw<br /> pointer array, writing to .clk_dif[4..7] fields corrupts both<br /> the struct rs9_driver_data content and data around it, sometimes<br /> without crashing the kernel. However, the kernel does surely<br /> crash when the driver is unbound or during suspend.<br /> <br /> Fix this, increase the struct clk_hw pointer array size to the<br /> maximum output count of 9FGV0841, which is the biggest chip that<br /> is supported by this driver.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udplite: Fix null-ptr-deref in __udp_enqueue_schedule_skb().<br /> <br /> syzbot reported null-ptr-deref of udp_sk(sk)-&gt;udp_prod_queue. [0]<br /> <br /> Since the cited commit, udp_lib_init_sock() can fail, as can<br /> udp_init_sock() and udpv6_init_sock().<br /> <br /> Let&amp;#39;s handle the error in udplite_sk_init() and udplitev6_sk_init().<br /> <br /> [0]:<br /> BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:82 [inline]<br /> BUG: KASAN: null-ptr-deref in atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]<br /> BUG: KASAN: null-ptr-deref in __udp_enqueue_schedule_skb+0x151/0x1480 net/ipv4/udp.c:1719<br /> Read of size 4 at addr 0000000000000008 by task syz.2.18/2944<br /> <br /> CPU: 1 UID: 0 PID: 2944 Comm: syz.2.18 Not tainted syzkaller #0 PREEMPTLAZY<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120<br /> kasan_report+0xa2/0xe0 mm/kasan/report.c:595<br /> check_region_inline mm/kasan/generic.c:-1 [inline]<br /> kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200<br /> instrument_atomic_read include/linux/instrumented.h:82 [inline]<br /> atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]<br /> __udp_enqueue_schedule_skb+0x151/0x1480 net/ipv4/udp.c:1719<br /> __udpv6_queue_rcv_skb net/ipv6/udp.c:795 [inline]<br /> udpv6_queue_rcv_one_skb+0xa2e/0x1ad0 net/ipv6/udp.c:906<br /> udp6_unicast_rcv_skb+0x227/0x380 net/ipv6/udp.c:1064<br /> ip6_protocol_deliver_rcu+0xe17/0x1540 net/ipv6/ip6_input.c:438<br /> ip6_input_finish+0x191/0x350 net/ipv6/ip6_input.c:489<br /> NF_HOOK+0x354/0x3f0 include/linux/netfilter.h:318<br /> ip6_input+0x16c/0x2b0 net/ipv6/ip6_input.c:500<br /> NF_HOOK+0x354/0x3f0 include/linux/netfilter.h:318<br /> __netif_receive_skb_one_core net/core/dev.c:6149 [inline]<br /> __netif_receive_skb+0xd3/0x370 net/core/dev.c:6262<br /> process_backlog+0x4d6/0x1160 net/core/dev.c:6614<br /> __napi_poll+0xae/0x320 net/core/dev.c:7678<br /> napi_poll net/core/dev.c:7741 [inline]<br /> net_rx_action+0x60d/0xdc0 net/core/dev.c:7893<br /> handle_softirqs+0x209/0x8d0 kernel/softirq.c:622<br /> do_softirq+0x52/0x90 kernel/softirq.c:523<br /> <br /> <br /> __local_bh_enable_ip+0xe7/0x120 kernel/softirq.c:450<br /> local_bh_enable include/linux/bottom_half.h:33 [inline]<br /> rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline]<br /> __dev_queue_xmit+0x109c/0x2dc0 net/core/dev.c:4856<br /> __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline]<br /> ip6_finish_output+0x158/0x4e0 net/ipv6/ip6_output.c:219<br /> NF_HOOK_COND include/linux/netfilter.h:307 [inline]<br /> ip6_output+0x342/0x580 net/ipv6/ip6_output.c:246<br /> ip6_send_skb+0x1d7/0x3c0 net/ipv6/ip6_output.c:1984<br /> udp_v6_send_skb+0x9a5/0x1770 net/ipv6/udp.c:1442<br /> udp_v6_push_pending_frames+0xa2/0x140 net/ipv6/udp.c:1469<br /> udpv6_sendmsg+0xfe0/0x2830 net/ipv6/udp.c:1759<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0xe5/0x270 net/socket.c:742<br /> __sys_sendto+0x3eb/0x580 net/socket.c:2206<br /> __do_sys_sendto net/socket.c:2213 [inline]<br /> __se_sys_sendto net/socket.c:2209 [inline]<br /> __x64_sys_sendto+0xde/0x100 net/socket.c:2209<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd2/0xf20 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f67b4d9c629<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f67b5c98028 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 00007f67b5015fa0 RCX: 00007f67b4d9c629<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003<br /> RBP: 00007f67b4e32b39 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000040000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f67b5016038 R14: 00007f67b5015fa0 R15: 00007ffe3cb66dd8<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix interlaced plain identification for encoded extents<br /> <br /> Only plain data whose start position and on-disk physical length are<br /> both aligned to the block size should be classified as interlaced<br /> plain extents. Otherwise, it must be treated as shifted plain extents.<br /> <br /> This issue was found by syzbot using a crafted compressed image<br /> containing plain extents with unaligned physical lengths, which can<br /> cause OOB read in z_erofs_transform_plain().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Skip dev-iotlb flush for inaccessible PCIe device without scalable mode<br /> <br /> PCIe endpoints with ATS enabled and passed through to userspace<br /> (e.g., QEMU, DPDK) can hard-lock the host when their link drops,<br /> either by surprise removal or by a link fault.<br /> <br /> Commit 4fc82cd907ac ("iommu/vt-d: Don&amp;#39;t issue ATS Invalidation<br /> request when device is disconnected") adds pci_dev_is_disconnected()<br /> to devtlb_invalidation_with_pasid() so ATS invalidation is skipped<br /> only when the device is being safely removed, but it applies only<br /> when Intel IOMMU scalable mode is enabled.<br /> <br /> With scalable mode disabled or unsupported, a system hard-lock<br /> occurs when a PCIe endpoint&amp;#39;s link drops because the Intel IOMMU<br /> waits indefinitely for an ATS invalidation that cannot complete.<br /> <br /> Call Trace:<br /> qi_submit_sync<br /> qi_flush_dev_iotlb<br /> __context_flush_dev_iotlb.part.0<br /> domain_context_clear_one_cb<br /> pci_for_each_dma_alias<br /> device_block_translation<br /> blocking_domain_attach_dev<br /> iommu_deinit_device<br /> __iommu_group_remove_device<br /> iommu_release_device<br /> iommu_bus_notifier<br /> blocking_notifier_call_chain<br /> bus_notify<br /> device_del<br /> pci_remove_bus_device<br /> pci_stop_and_remove_bus_device<br /> pciehp_unconfigure_device<br /> pciehp_disable_slot<br /> pciehp_handle_presence_or_link_change<br /> pciehp_ist<br /> <br /> Commit 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release")<br /> adds intel_pasid_teardown_sm_context() to intel_iommu_release_device(),<br /> which calls qi_flush_dev_iotlb() and can also hard-lock the system<br /> when a PCIe endpoint&amp;#39;s link drops.<br /> <br /> Call Trace:<br /> qi_submit_sync<br /> qi_flush_dev_iotlb<br /> __context_flush_dev_iotlb.part.0<br /> intel_context_flush_no_pasid<br /> device_pasid_table_teardown<br /> pci_pasid_table_teardown<br /> pci_for_each_dma_alias<br /> intel_pasid_teardown_sm_context<br /> intel_iommu_release_device<br /> iommu_deinit_device<br /> __iommu_group_remove_device<br /> iommu_release_device<br /> iommu_bus_notifier<br /> blocking_notifier_call_chain<br /> bus_notify<br /> device_del<br /> pci_remove_bus_device<br /> pci_stop_and_remove_bus_device<br /> pciehp_unconfigure_device<br /> pciehp_disable_slot<br /> pciehp_handle_presence_or_link_change<br /> pciehp_ist<br /> <br /> Sometimes the endpoint loses connection without a link-down event<br /> (e.g., due to a link fault); killing the process (virsh destroy)<br /> then hard-locks the host.<br /> <br /> Call Trace:<br /> qi_submit_sync<br /> qi_flush_dev_iotlb<br /> __context_flush_dev_iotlb.part.0<br /> domain_context_clear_one_cb<br /> pci_for_each_dma_alias<br /> device_block_translation<br /> blocking_domain_attach_dev<br /> __iommu_attach_device<br /> __iommu_device_set_domain<br /> __iommu_group_set_domain_internal<br /> iommu_detach_group<br /> vfio_iommu_type1_detach_group<br /> vfio_group_detach_container<br /> vfio_group_fops_release<br /> __fput<br /> <br /> pci_dev_is_disconnected() only covers safe-removal paths;<br /> pci_device_is_present() tests accessibility by reading<br /> vendor/device IDs and internally calls pci_dev_is_disconnected().<br /> On a ConnectX-5 (8 GT/s, x2) this costs ~70 µs.<br /> <br /> Since __context_flush_dev_iotlb() is only called on<br /> {attach,release}_dev paths (not hot), add pci_device_is_present()<br /> there to skip inaccessible devices and avoid the hard-lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: tegra-video: Fix memory leak in __tegra_channel_try_format()<br /> <br /> The state object allocated by __v4l2_subdev_state_alloc() must be freed<br /> with __v4l2_subdev_state_free() when it is no longer needed.<br /> <br /> In __tegra_channel_try_format(), two error paths return directly after<br /> v4l2_subdev_call() fails, without freeing the allocated &amp;#39;sd_state&amp;#39;<br /> object. This violates the requirement and causes a memory leak.<br /> <br /> Fix this by introducing a cleanup label and using goto statements in the<br /> error paths to ensure that __v4l2_subdev_state_free() is always called<br /> before the function returns.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/bitmap: fix GPF in write_page caused by resize race<br /> <br /> A General Protection Fault occurs in write_page() during array resize:<br /> RIP: 0010:write_page+0x22b/0x3c0 [md_mod]<br /> <br /> This is a use-after-free race between bitmap_daemon_work() and<br /> __bitmap_resize(). The daemon iterates over `bitmap-&gt;storage.filemap`<br /> without locking, while the resize path frees that storage via<br /> md_bitmap_file_unmap(). `quiesce()` does not stop the md thread,<br /> allowing concurrent access to freed pages.<br /> <br /> Fix by holding `mddev-&gt;bitmap_info.mutex` during the bitmap update.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (nct7363) Fix a resource leak in nct7363_present_pwm_fanin<br /> <br /> When calling of_parse_phandle_with_args(), the caller is responsible<br /> to call of_node_put() to release the reference of device node.<br /> In nct7363_present_pwm_fanin, it does not release the reference,<br /> causing a resource leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: always flush state and policy upon NETDEV_UNREGISTER event<br /> <br /> syzbot is reporting that "struct xfrm_state" refcount is leaking.<br /> <br /> unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 2<br /> ref_tracker: netdev@ffff888052f24618 has 1/1 users at<br /> __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline]<br /> netdev_tracker_alloc include/linux/netdevice.h:4412 [inline]<br /> xfrm_dev_state_add+0x3a5/0x1080 net/xfrm/xfrm_device.c:316<br /> xfrm_state_construct net/xfrm/xfrm_user.c:986 [inline]<br /> xfrm_add_sa+0x34ff/0x5fa0 net/xfrm/xfrm_user.c:1022<br /> xfrm_user_rcv_msg+0x58e/0xc00 net/xfrm/xfrm_user.c:3507<br /> netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2550<br /> xfrm_netlink_rcv+0x71/0x90 net/xfrm/xfrm_user.c:3529<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa5d/0xc30 net/socket.c:2592<br /> ___sys_sendmsg+0x134/0x1d0 net/socket.c:2646<br /> __sys_sendmsg+0x16d/0x220 net/socket.c:2678<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> This is because commit d77e38e612a0 ("xfrm: Add an IPsec hardware<br /> offloading API") implemented xfrm_dev_unregister() as no-op despite<br /> xfrm_dev_state_add() from xfrm_state_construct() acquires a reference<br /> to "struct net_device".<br /> I guess that that commit expected that NETDEV_DOWN event is fired before<br /> NETDEV_UNREGISTER event fires, and also assumed that xfrm_dev_state_add()<br /> is called only if (dev-&gt;features &amp; NETIF_F_HW_ESP) != 0.<br /> <br /> Sabrina Dubroca identified steps to reproduce the same symptoms as below.<br /> <br /> echo 0 &gt; /sys/bus/netdevsim/new_device<br /> dev=$(ls -1 /sys/bus/netdevsim/devices/netdevsim0/net/)<br /> ip xfrm state add src 192.168.13.1 dst 192.168.13.2 proto esp \<br /> spi 0x1000 mode tunnel aead &amp;#39;rfc4106(gcm(aes))&amp;#39; $key 128 \<br /> offload crypto dev $dev dir out<br /> ethtool -K $dev esp-hw-offload off<br /> echo 0 &gt; /sys/bus/netdevsim/del_device<br /> <br /> Like these steps indicate, the NETIF_F_HW_ESP bit can be cleared after<br /> xfrm_dev_state_add() acquired a reference to "struct net_device".<br /> Also, xfrm_dev_state_add() does not check for the NETIF_F_HW_ESP bit<br /> when acquiring a reference to "struct net_device".<br /> <br /> Commit 03891f820c21 ("xfrm: handle NETDEV_UNREGISTER for xfrm device")<br /> re-introduced the NETDEV_UNREGISTER event to xfrm_dev_event(), but that<br /> commit for unknown reason chose to share xfrm_dev_down() between the<br /> NETDEV_DOWN event and the NETDEV_UNREGISTER event.<br /> I guess that that commit missed the behavior in the previous paragraph.<br /> <br /> Therefore, we need to re-introduce xfrm_dev_unregister() in order to<br /> release the reference to "struct net_device" by unconditionally flushing<br /> state and policy.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: remove xfs_attr_leaf_hasname<br /> <br /> The calling convention of xfs_attr_leaf_hasname() is problematic, because<br /> it returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer<br /> when xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a<br /> non-NULL buffer pointer for an already released buffer when<br /> xfs_attr3_leaf_lookup_int fails with other error values.<br /> <br /> Fix this by simply open coding xfs_attr_leaf_hasname in the callers, so<br /> that the buffer release code is done by each caller of<br /> xfs_attr3_leaf_read.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix freemap adjustments when adding xattrs to leaf blocks<br /> <br /> xfs/592 and xfs/794 both trip this assertion in the leaf block freemap<br /> adjustment code after ~20 minutes of running on my test VMs:<br /> <br /> ASSERT(ichdr-&gt;firstused &gt;= ichdr-&gt;count * sizeof(xfs_attr_leaf_entry_t)<br /> + xfs_attr3_leaf_hdr_size(leaf));<br /> <br /> Upon enabling quite a lot more debugging code, I narrowed this down to<br /> fsstress trying to set a local extended attribute with namelen=3 and<br /> valuelen=71. This results in an entry size of 80 bytes.<br /> <br /> At the start of xfs_attr3_leaf_add_work, the freemap looks like this:<br /> <br /> i 0 base 448 size 0 rhs 448 count 46<br /> i 1 base 388 size 132 rhs 448 count 46<br /> i 2 base 2120 size 4 rhs 448 count 46<br /> firstused = 520<br /> <br /> where "rhs" is the first byte past the end of the leaf entry array.<br /> This is inconsistent -- the entries array ends at byte 448, but<br /> freemap[1] says there&amp;#39;s free space starting at byte 388!<br /> <br /> By the end of the function, the freemap is in worse shape:<br /> <br /> i 0 base 456 size 0 rhs 456 count 47<br /> i 1 base 388 size 52 rhs 456 count 47<br /> i 2 base 2120 size 4 rhs 456 count 47<br /> firstused = 440<br /> <br /> Important note: 388 is not aligned with the entries array element size<br /> of 8 bytes.<br /> <br /> Based on the incorrect freemap, the name area starts at byte 440, which<br /> is below the end of the entries array! That&amp;#39;s why the assertion<br /> triggers and the filesystem shuts down.<br /> <br /> How did we end up here? First, recall from the previous patch that the<br /> freemap array in an xattr leaf block is not intended to be a<br /> comprehensive map of all free space in the leaf block. In other words,<br /> it&amp;#39;s perfectly legal to have a leaf block with:<br /> <br /> * 376 bytes in use by the entries array<br /> * freemap[0] has [base = 376, size = 8]<br /> * freemap[1] has [base = 388, size = 1500]<br /> * the space between 376 and 388 is free, but the freemap stopped<br /> tracking that some time ago<br /> <br /> If we add one xattr, the entries array grows to 384 bytes, and<br /> freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we<br /> add a second xattr, the entries array grows to 392 bytes, and freemap[0]<br /> gets pushed up to [base = 392, size = 0]. This is bad, because<br /> freemap[1] hasn&amp;#39;t been updated, and now the entries array and the free<br /> space claim the same space.<br /> <br /> The fix here is to adjust all freemap entries so that none of them<br /> collide with the entries array. Note that this fix relies on commit<br /> 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and<br /> the previous patch that resets zero length freemap entries to have<br /> base = 0.