Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost: move vdpa group bound check to vhost_vdpa<br /> <br /> Remove duplication by consolidating these here. This reduces the<br /> posibility of a parent driver missing them.<br /> <br /> While we&amp;#39;re at it, fix a bug in vdpa_sim where a valid ASID can be<br /> assigned to a group equal to ngroups, causing an out of bound write.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: chips-media: wave5: Fix SError of kernel panic when closed<br /> <br /> SError of kernel panic rarely happened while testing fluster.<br /> The root cause was to enter suspend mode because timeout of autosuspend<br /> delay happened.<br /> <br /> [ 48.834439] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError<br /> [ 48.834455] CPU: 0 UID: 0 PID: 1067 Comm: v4l2h265dec0:sr Not tainted 6.12.9-gc9e21a1ebd75-dirty #7<br /> [ 48.834461] Hardware name: ti Texas Instruments J721S2 EVM/Texas Instruments J721S2 EVM, BIOS 2025.01-00345-gbaf3aaa8ecfa 01/01/2025<br /> [ 48.834464] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 48.834468] pc : wave5_dec_clr_disp_flag+0x40/0x80 [wave5]<br /> [ 48.834488] lr : wave5_dec_clr_disp_flag+0x40/0x80 [wave5]<br /> [ 48.834495] sp : ffff8000856e3a30<br /> [ 48.834497] x29: ffff8000856e3a30 x28: ffff0008093f6010 x27: ffff000809158130<br /> [ 48.834504] x26: 0000000000000000 x25: ffff00080b625000 x24: ffff000804a9ba80<br /> [ 48.834509] x23: ffff000802343028 x22: ffff000809158150 x21: ffff000802218000<br /> [ 48.834513] x20: ffff0008093f6000 x19: ffff0008093f6000 x18: 0000000000000000<br /> [ 48.834518] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff74009618<br /> [ 48.834523] x14: 000000010000000c x13: 0000000000000000 x12: 0000000000000000<br /> [ 48.834527] x11: ffffffffffffffff x10: ffffffffffffffff x9 : ffff000802343028<br /> [ 48.834532] x8 : ffff00080b6252a0 x7 : 0000000000000038 x6 : 0000000000000000<br /> [ 48.834536] x5 : ffff00080b625060 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 48.834541] x2 : 0000000000000000 x1 : ffff800084bf0118 x0 : ffff800084bf0000<br /> [ 48.834547] Kernel panic - not syncing: Asynchronous SError Interrupt<br /> [ 48.834549] CPU: 0 UID: 0 PID: 1067 Comm: v4l2h265dec0:sr Not tainted 6.12.9-gc9e21a1ebd75-dirty #7<br /> [ 48.834554] Hardware name: ti Texas Instruments J721S2 EVM/Texas Instruments J721S2 EVM, BIOS 2025.01-00345-gbaf3aaa8ecfa 01/01/2025<br /> [ 48.834556] Call trace:<br /> [ 48.834559] dump_backtrace+0x94/0xec<br /> [ 48.834574] show_stack+0x18/0x24<br /> [ 48.834579] dump_stack_lvl+0x38/0x90<br /> [ 48.834585] dump_stack+0x18/0x24<br /> [ 48.834588] panic+0x35c/0x3e0<br /> [ 48.834592] nmi_panic+0x40/0x8c<br /> [ 48.834595] arm64_serror_panic+0x64/0x70<br /> [ 48.834598] do_serror+0x3c/0x78<br /> [ 48.834601] el1h_64_error_handler+0x34/0x4c<br /> [ 48.834605] el1h_64_error+0x64/0x68<br /> [ 48.834608] wave5_dec_clr_disp_flag+0x40/0x80 [wave5]<br /> [ 48.834615] wave5_vpu_dec_clr_disp_flag+0x54/0x80 [wave5]<br /> [ 48.834622] wave5_vpu_dec_buf_queue+0x19c/0x1a0 [wave5]<br /> [ 48.834628] __enqueue_in_driver+0x3c/0x74 [videobuf2_common]<br /> [ 48.834639] vb2_core_qbuf+0x508/0x61c [videobuf2_common]<br /> [ 48.834646] vb2_qbuf+0xa4/0x168 [videobuf2_v4l2]<br /> [ 48.834656] v4l2_m2m_qbuf+0x80/0x238 [v4l2_mem2mem]<br /> [ 48.834666] v4l2_m2m_ioctl_qbuf+0x18/0x24 [v4l2_mem2mem]<br /> [ 48.834673] v4l_qbuf+0x48/0x5c [videodev]<br /> [ 48.834704] __video_do_ioctl+0x180/0x3f0 [videodev]<br /> [ 48.834725] video_usercopy+0x2ec/0x68c [videodev]<br /> [ 48.834745] video_ioctl2+0x18/0x24 [videodev]<br /> [ 48.834766] v4l2_ioctl+0x40/0x60 [videodev]<br /> [ 48.834786] __arm64_sys_ioctl+0xa8/0xec<br /> [ 48.834793] invoke_syscall+0x44/0x100<br /> [ 48.834800] el0_svc_common.constprop.0+0xc0/0xe0<br /> [ 48.834804] do_el0_svc+0x1c/0x28<br /> [ 48.834809] el0_svc+0x30/0xd0<br /> [ 48.834813] el0t_64_sync_handler+0xc0/0xc4<br /> [ 48.834816] el0t_64_sync+0x190/0x194<br /> [ 48.834820] SMP: stopping secondary CPUs<br /> [ 48.834831] Kernel Offset: disabled<br /> [ 48.834833] CPU features: 0x08,00002002,80200000,4200421b<br /> [ 48.834837] Memory Limit: none<br /> [ 49.161404] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c/tw9906: Fix potential memory leak in tw9906_probe()<br /> <br /> In one of the error paths in tw9906_probe(), the memory allocated in<br /> v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that<br /> by calling v4l2_ctrl_handler_free() on the handler in that error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_skbedit: fix divide-by-zero in tcf_skbedit_hash()<br /> <br /> Commit 38a6f0865796 ("net: sched: support hash selecting tx queue")<br /> added SKBEDIT_F_TXQ_SKBHASH support. The inclusive range size is<br /> computed as:<br /> <br /> mapping_mod = queue_mapping_max - queue_mapping + 1;<br /> <br /> The range size can be 65536 when the requested range covers all possible<br /> u16 queue IDs (e.g. queue_mapping=0 and queue_mapping_max=U16_MAX).<br /> That value cannot be represented in a u16 and previously wrapped to 0,<br /> so tcf_skbedit_hash() could trigger a divide-by-zero:<br /> <br /> queue_mapping += skb_get_hash(skb) % params-&gt;mapping_mod;<br /> <br /> Compute mapping_mod in a wider type and reject ranges larger than U16_MAX<br /> to prevent params-&gt;mapping_mod from becoming 0 and avoid the crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kexec: add a sanity check on previous kernel&amp;#39;s ima kexec buffer<br /> <br /> When the second-stage kernel is booted via kexec with a limiting command<br /> line such as "mem=", the physical range that contains the carried<br /> over IMA measurement list may fall outside the truncated RAM leading to a<br /> kernel panic.<br /> <br /> BUG: unable to handle page fault for address: ffff97793ff47000<br /> RIP: ima_restore_measurement_list+0xdc/0x45a<br /> #PF: error_code(0x0000) – not-present page<br /> <br /> Other architectures already validate the range with page_is_ram(), as done<br /> in commit cbf9c4b9617b ("of: check previous kernel&amp;#39;s ima-kexec-buffer<br /> against memory bounds") do a similar check on x86.<br /> <br /> Without carrying the measurement list across kexec, the attestation<br /> would fail.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntb: ntb_hw_switchtec: Fix array-index-out-of-bounds access<br /> <br /> Number of MW LUTs depends on NTB configuration and can be set to MAX_MWS,<br /> This patch protects against invalid index out of bounds access to mw_sizes<br /> When invalid access print message to user that configuration is not valid.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: ti: k3-socinfo: Fix regmap leak on probe failure<br /> <br /> The mmio regmap allocated during probe is never freed.<br /> <br /> Switch to using the device managed allocator so that the regmap is<br /> released on probe failures (e.g. probe deferral) and on driver unbind.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add signal type check for dcn401 get_phyd32clk_src<br /> <br /> Trying to access link enc on a dpia link will cause a crash otherwise

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: fix zero-frag skb in frag_list on partial sendmsg error<br /> <br /> Syzkaller reported a warning in kcm_write_msgs() when processing a<br /> message with a zero-fragment skb in the frag_list.<br /> <br /> When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb,<br /> it allocates a new skb (tskb) and links it into the frag_list before<br /> copying data. If the copy subsequently fails (e.g. -EFAULT from<br /> user memory), tskb remains in the frag_list with zero fragments:<br /> <br /> head skb (msg being assembled, NOT yet in sk_write_queue)<br /> +-----------+<br /> | frags[17] | (MAX_SKB_FRAGS, all filled with data)<br /> | frag_list-+--&gt; tskb<br /> +-----------+ +----------+<br /> | frags[0] | (empty! copy failed before filling)<br /> +----------+<br /> <br /> For SOCK_SEQPACKET with partial data already copied, the error path<br /> saves this message via partial_message for later completion. For<br /> SOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so a<br /> subsequent zero-length write(fd, NULL, 0) completes the message and<br /> queues it to sk_write_queue. kcm_write_msgs() then walks the<br /> frag_list and hits:<br /> <br /> WARN_ON(!skb_shinfo(skb)-&gt;nr_frags)<br /> <br /> TCP has a similar pattern where skbs are enqueued before data copy<br /> and cleaned up on failure via tcp_remove_empty_skb(). KCM was<br /> missing the equivalent cleanup.<br /> <br /> Fix this by tracking the predecessor skb (frag_prev) when allocating<br /> a new frag_list entry. On error, if the tail skb has zero frags,<br /> use frag_prev to unlink and free it in O(1) without walking the<br /> singly-linked frag_list. frag_prev is safe to dereference because<br /> the entire message chain is only held locally (or in kcm-&gt;seq_skb)<br /> and is not added to sk_write_queue until MSG_EOR, so the send path<br /> cannot free it underneath us.<br /> <br /> Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the log<br /> if the condition is somehow hit repeatedly.<br /> <br /> There are currently no KCM selftests in the kernel tree; a simple<br /> reproducer is available at [1].<br /> <br /> [1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: prevent races in -&gt;query_interfaces()<br /> <br /> It was possible for two query interface works to be concurrently trying<br /> to update the interfaces.<br /> <br /> Prevent this by checking and updating iface_last_update under<br /> iface_lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs: -&gt;d_compare() must not block<br /> <br /> ... so don&amp;#39;t use __getname() there. Switch it (and ntfs_d_hash(), while<br /> we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash()<br /> almost certainly can do with smaller allocations, but let ntfs folks<br /> deal with that - keep the allocation size as-is for now.<br /> <br /> Stop abusing names_cachep in ntfs, period - various uses of that thing<br /> in there have nothing to do with pathnames; just use k[mz]alloc() and<br /> be done with that. For now let&amp;#39;s keep sizes as-in, but AFAICS none of<br /> the users actually want PATH_MAX.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> team: avoid NETDEV_CHANGEMTU event when unregistering slave<br /> <br /> syzbot is reporting<br /> <br /> unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 3<br /> ref_tracker: netdev@ffff88807dcf8618 has 1/2 users at<br /> __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline]<br /> netdev_hold include/linux/netdevice.h:4429 [inline]<br /> inetdev_init+0x201/0x4e0 net/ipv4/devinet.c:286<br /> inetdev_event+0x251/0x1610 net/ipv4/devinet.c:1600<br /> notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85<br /> call_netdevice_notifiers_mtu net/core/dev.c:2318 [inline]<br /> netif_set_mtu_ext+0x5aa/0x800 net/core/dev.c:9886<br /> netif_set_mtu+0xd7/0x1b0 net/core/dev.c:9907<br /> dev_set_mtu+0x126/0x260 net/core/dev_api.c:248<br /> team_port_del+0xb07/0xcb0 drivers/net/team/team_core.c:1333<br /> team_del_slave drivers/net/team/team_core.c:1936 [inline]<br /> team_device_event+0x207/0x5b0 drivers/net/team/team_core.c:2929<br /> notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85<br /> call_netdevice_notifiers_extack net/core/dev.c:2281 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2295 [inline]<br /> __dev_change_net_namespace+0xcb7/0x2050 net/core/dev.c:12592<br /> do_setlink+0x2ce/0x4590 net/core/rtnetlink.c:3060<br /> rtnl_changelink net/core/rtnetlink.c:3776 [inline]<br /> __rtnl_newlink net/core/rtnetlink.c:3935 [inline]<br /> rtnl_newlink+0x15a9/0x1be0 net/core/rtnetlink.c:4072<br /> rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958<br /> netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894<br /> <br /> problem. Ido Schimmel found steps to reproduce<br /> <br /> ip link add name team1 type team<br /> ip link add name dummy1 mtu 1499 master team1 type dummy<br /> ip netns add ns1<br /> ip link set dev dummy1 netns ns1<br /> ip -n ns1 link del dev dummy1<br /> <br /> and also found that the same issue was fixed in the bond driver in<br /> commit f51048c3e07b ("bonding: avoid NETDEV_CHANGEMTU event when<br /> unregistering slave").<br /> <br /> Let&amp;#39;s do similar thing for the team driver, with commit ad7c7b2172c3 ("net:<br /> hold netdev instance lock during sysfs operations") and commit 303a8487a657<br /> ("net: s/__dev_set_mtu/__netif_set_mtu/") also applied.