Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD<br /> <br /> net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code<br /> the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload<br /> before overwriting it with skb_copy_bits().<br /> <br /> skb_put() reserves nla_total_size(payload_len), i.e. the header plus the<br /> NLA_ALIGN() padding, but only payload_len bytes are copied in. When<br /> payload_len is not a multiple of 4 the 1-3 padding bytes are never<br /> initialized and are leaked to user space inside the netlink message.<br /> <br /> KMSAN confirms the leak for the software path when the packet payload<br /> length is not 4-byte aligned:<br /> <br /> BUG: KMSAN: kernel-infoleak in _copy_to_iter<br /> _copy_to_iter<br /> __skb_datagram_iter<br /> skb_copy_datagram_iter<br /> netlink_recvmsg<br /> sock_recvmsg<br /> __sys_recvfrom<br /> Uninit was created at:<br /> kmem_cache_alloc_node_noprof<br /> __alloc_skb<br /> net_dm_packet_work<br /> Bytes 173-175 of 176 are uninitialized<br /> <br /> Use __nla_reserve(), which sets up the attribute header and zeroes the<br /> padding, instead of open coding the attribute construction.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream()<br /> <br /> In tipc_recvmsg(), the copy length is computed as:<br /> <br /> copy = min_t(int, dlen - offset, buflen);<br /> <br /> buflen is size_t but min_t(int, ...) casts it to int. When buflen<br /> exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it<br /> wraps negative, wins the comparison, and the negative copy length<br /> propagates to simple_copy_to_iter() where int-to-size_t promotion<br /> makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the<br /> same pattern.<br /> <br /> Kernel panic - not syncing: kernel: panic_on_warn set ...<br /> RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521)<br /> Call Trace:<br /> __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402)<br /> skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534)<br /> tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934)<br /> io_recvmsg+0x47e/0xda0<br /> <br /> Fix by changing min_t(int, ...) to min_t(size_t, ...) in both<br /> functions. The result is always

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rds: tcp: unregister sysctl before tearing down listen socket<br /> <br /> rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via<br /> rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since<br /> rds_tcp_skbuf_handler() derives the netns from<br /> rtn-&gt;rds_tcp_listen_sock-&gt;sk, a concurrent sysctl write can race with<br /> netns teardown and dereference the freed socket/sk.<br /> <br /> KASAN reports the race as:<br /> <br /> BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0<br /> rds_tcp_skbuf_handler net/rds/tcp.c:721<br /> proc_sys_call_handler fs/proc/proc_sysctl.c<br /> vfs_write fs/read_write.c<br /> __x64_sys_pwrite64 fs/read_write.c<br /> <br /> Fix this by unregistering the RDS TCP sysctl table before calling<br /> rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl<br /> handlers from starting and waits for in-flight handlers to finish, so<br /> the listen socket can then be released safely. The fix was tested<br /> against the linked reproducer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix max_vport related crash on allocation error during init<br /> <br /> Set adapter-&gt;max_vports only after successful allocation of vports, netdevs<br /> and vport_config buffers. This fixes possible crashes on reset or rmmod,<br /> following failed allocation on init<br /> <br /> [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -&gt; 0102)<br /> [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated<br /> [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 320.416918] #PF: supervisor read access in kernel mode<br /> [ 320.416942] #PF: error_code(0x0000) - not-present page<br /> [ 320.416963] PGD 2099657067 P4D 0<br /> [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI<br /> ...<br /> [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf]<br /> [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20<br /> [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246<br /> [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c<br /> [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000<br /> [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000<br /> [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000<br /> [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20<br /> [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000<br /> [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0<br /> [ 320.417385] PKRU: 55555554<br /> [ 320.417398] Call Trace:<br /> [ 320.417412] <br /> [ 320.417429] pci_device_remove+0x42/0xb0<br /> [ 320.417459] device_release_driver_internal+0x1a9/0x210<br /> [ 320.417492] driver_detach+0x4b/0x90<br /> [ 320.417516] bus_remove_driver+0x70/0x100<br /> [ 320.417539] pci_unregister_driver+0x2e/0xb0<br /> [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0<br /> [ 320.417592] ? kmem_cache_free+0x31e/0x550<br /> [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190<br /> [ 320.417644] ? do_syscall_64+0x38/0x6b0<br /> [ 320.417665] do_syscall_64+0xc8/0x6b0<br /> [ 320.417683] ? clear_bhb_loop+0x30/0x80<br /> [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 320.417727] RIP: 0033:0x7f963bb30beb

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: prevent tstamp ring allocation for non-PF VSI types<br /> <br /> The pf-&gt;txtime_txqs bitmap tracks which Tx queues have ETF (Earliest<br /> TxTime First) offload enabled. This bitmap is indexed by queue number<br /> and is set by ice_offload_txtime(), which only operates on PF VSI<br /> queues.<br /> <br /> However, ice_is_txtime_ena() does not check the VSI type before<br /> consulting the bitmap. When ETF offload is enabled on PF Tx queue 0,<br /> bit 0 is set in pf-&gt;txtime_txqs. During a subsequent PCI reset<br /> rebuild, the CTRL VSI&amp;#39;s Tx queue 0 is reconfigured and<br /> ice_is_txtime_ena() is called for that ring. Since it only checks<br /> pf-&gt;txtime_txqs by queue index without distinguishing VSI type, it<br /> finds bit 0 set and returns true, matching the PF VSI&amp;#39;s ETF queue,<br /> not the CTRL VSI&amp;#39;s. This causes ice_vsi_cfg_txq() to spuriously<br /> allocate a tstamp_ring for the CTRL VSI ring.<br /> <br /> Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring()<br /> takes an early return at the !netdev check before reaching<br /> ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset<br /> leaks one 64-byte tstamp_ring.<br /> <br /> Fix this by restricting ice_is_txtime_ena() to return true only for<br /> PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix MCIA register buffer overflow on 32 dword reads<br /> <br /> The MCIA register can return up to 32 dwords (128 bytes) when the device<br /> advertises the mcia_32dwords capability, but struct<br /> mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just<br /> 12 dwords (48 bytes) of data.<br /> <br /> mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then<br /> memcpy()s that many bytes out of the register, potentially reading past<br /> the end of the &amp;#39;out&amp;#39; buffer. On kernels built with FORTIFY_SOURCE this<br /> is caught as a buffer overflow while reading the module EEPROM via<br /> ethtool:<br /> <br /> detected buffer overflow in memcpy<br /> kernel BUG at lib/string_helpers.c:1048!<br /> RIP: 0010:fortify_panic+0x13/0x20<br /> Call Trace:<br /> mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core]<br /> mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core]<br /> mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core]<br /> eeprom_prepare_data+0xf3/0x170<br /> ethnl_default_doit+0xf1/0x3b0<br /> <br /> Extend the mcia_reg layout to 32 dwords.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: restrict socket creation to the initial network namespace<br /> <br /> QRTR keeps its entire port and node state in module-global variables<br /> that are not partitioned per network namespace: qrtr_local_nid is a<br /> single global node id (always 1) and qrtr_ports is a single global<br /> xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that<br /> global state with no network-namespace check, and qrtr_create() places<br /> no restriction on the namespace a socket is created in.<br /> <br /> As a result an unprivileged process that creates an AF_QIPCRTR socket<br /> in a separate network namespace, e.g. via<br /> unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams -<br /> including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR<br /> sockets owned by another namespace, and vice versa. The receiving<br /> socket sees such a message as coming from node id 1, indistinguishable<br /> from a legitimate local client, breaking the isolation that network<br /> namespaces are expected to provide.<br /> <br /> QRTR is a transport to global hardware endpoints (the modem and other<br /> remote processors) and has no per-namespace semantics; its in-kernel<br /> name service already creates its socket in init_net only. Confine the<br /> socket family to the initial network namespace, as other<br /> non-namespace-aware socket families do (see llc_ui_create() and the<br /> ieee802154 socket code).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: Zero-extend signed ALU32 div/mod results<br /> <br /> ALU32 operations write a 32-bit result and leave the upper 32 bits of<br /> the BPF register zero. The LoongArch JIT sign-extends the result of<br /> signed ALU32 BPF_DIV and BPF_MOD (off=1), so a negative 32-bit quotient<br /> or remainder leaves bits 63:32 set in JITted code while the verifier<br /> and interpreter model those bits as zero.<br /> <br /> Keep sign-extension on the operands, which signed divide needs, and<br /> zero-extend the ALU32 result after the divide or modulo instruction,<br /> matching the unsigned ALU32 div/mod paths and every other ALU32<br /> operation in this JIT.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers<br /> <br /> drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw<br /> message and then unconditionally does:<br /> <br /> memcpy(bytes, &amp;raw-&gt;msg[idx], num_bytes);<br /> <br /> without checking that idx + num_bytes curlen. raw-&gt;msg[] is<br /> 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger<br /> than the remaining payload, the memcpy reads past the received data<br /> into whatever follows in raw-&gt;msg[].<br /> <br /> drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted<br /> with a /* TODO check */ comment since the code was introduced).<br /> <br /> Fix both functions by using a single combined check<br /> (idx + num_bytes &gt; curlen) before each memcpy. Since num_bytes is u8,<br /> it is always &gt;= 0, so this strictly subsumes the simpler idx &gt; curlen<br /> form and no separate step is needed.<br /> <br /> [added missing fixes tag]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()<br /> <br /> The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks<br /> for both runtime PM and system sleep. This causes the DSI clocks to be<br /> disabled twice: once during runtime suspend and again during system<br /> suspend, resulting in a WARN message from the clock framework when<br /> attempting to disable already-disabled clocks.<br /> <br /> [ 84.384540] clk:231:5 already disabled<br /> [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac<br /> ...<br /> [ 84.579183] Call trace:<br /> [ 84.581624] clk_core_disable+0xa4/0xac<br /> [ 84.585457] clk_disable+0x30/0x4c<br /> [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi]<br /> [ 84.593651] pm_generic_suspend+0x2c/0x44<br /> [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c<br /> [ 84.601670] dpm_run_callback+0x8c/0x14c<br /> [ 84.605588] __device_suspend+0x1a0/0x56c<br /> [ 84.609594] dpm_suspend+0x17c/0x21c<br /> [ 84.613165] dpm_suspend_start+0xa0/0xa8<br /> [ 84.617083] suspend_devices_and_enter+0x12c/0x634<br /> [ 84.621872] pm_suspend+0x1fc/0x368<br /> <br /> To address this issue, replace UNIVERSAL_DEV_PM_OPS() with<br /> RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime<br /> PM, as the DRM framework manages system-wide power transitions through<br /> the bridge enable() and disable() hooks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imagination: Count paired job fence as dependency in prepare_job()<br /> <br /> The DRM scheduler&amp;#39;s prepare_job() callback counts the remaining<br /> non-signaled native dependencies for a job, preventing job submission<br /> until those (plus job data and fence update) can fit in the job queue&amp;#39;s<br /> CCCB.<br /> <br /> This means checking which dependencies can be waited upon in the<br /> firmware, i.e. whether they are backed by a UFO object, i.e. whether<br /> their drm_sched_fence::parent has been assigned to a<br /> pvr_queue_fence::base fence. That happens when the job owning the fence<br /> is submitted to the firmware.<br /> <br /> Paired geometry and fragment jobs are submitted at the same time, which<br /> means the dependency between them can&amp;#39;t be checked this way before<br /> submission.<br /> <br /> Update job_count_remaining_native_deps() to take into account the<br /> dependency between paired jobs.<br /> <br /> This fixes cases where prepare_job() underestimated the space left in<br /> an almost full fragment CCCB, wrongly unblocking run_job(), which then<br /> returned early without writing the full sequence of commands to the<br /> CCCB.<br /> <br /> The above lead to kernel warnings such as the following and potentially<br /> job timeouts (depending on waiters on the missing commands):<br /> <br /> [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47<br /> [ 375.703160] Modules linked in:<br /> [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT<br /> [ 375.703613] Tainted: [W]=WARN<br /> [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT)<br /> [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched]<br /> [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr]<br /> [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr]<br /> [ 375.703921] sp : ffff800084a97650<br /> [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000<br /> [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000<br /> [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008<br /> [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000<br /> [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000<br /> [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3<br /> [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008<br /> [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000<br /> [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f<br /> [ 375.704317] Call trace:<br /> [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P)<br /> [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr]<br /> [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr]<br /> [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched]<br /> [ 375.704623] process_one_work+0x520/0x1288<br /> [ 375.704658] worker_thread+0x3f0/0xb3c<br /> [ 375.704680] kthread+0x334/0x3d8<br /> [ 375.704706] ret_from_fork+0x10/0x20<br /> [ 375.704736] ---[ end trace 0000000000000000 ]---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/rockchip: analogix_dp: Add missing error check for platform_get_resource()<br /> <br /> Add missing error check for platform_get_resource() return value to<br /> prevent NULL pointer dereference when memory resource is not available.