Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sunrpc: fix cache_request leak in cache_release<br /> <br /> When a reader&amp;#39;s file descriptor is closed while in the middle of reading<br /> a cache_request (rp-&gt;offset != 0), cache_release() decrements the<br /> request&amp;#39;s readers count but never checks whether it should free the<br /> request.<br /> <br /> In cache_read(), when readers drops to 0 and CACHE_PENDING is clear, the<br /> cache_request is removed from the queue and freed along with its buffer<br /> and cache_head reference. cache_release() lacks this cleanup.<br /> <br /> The only other path that frees requests with readers == 0 is<br /> cache_dequeue(), but it runs only when CACHE_PENDING transitions from<br /> set to clear. If that transition already happened while readers was<br /> still non-zero, cache_dequeue() will have skipped the request, and no<br /> subsequent call will clean it up.<br /> <br /> Add the same cleanup logic from cache_read() to cache_release(): after<br /> decrementing readers, check if it reached 0 with CACHE_PENDING clear,<br /> and if so, dequeue and free the cache_request.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: atmel-sha204a - Fix OOM -&gt;tfm_count leak<br /> <br /> If memory allocation fails, decrement -&gt;tfm_count to avoid blocking<br /> future reads.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix krb5 mount with username option<br /> <br /> Customer reported that some of their krb5 mounts were failing against<br /> a single server as the client was trying to mount the shares with<br /> wrong credentials. It turned out the client was reusing SMB session<br /> from first mount to try mounting the other shares, even though a<br /> different username= option had been specified to the other mounts.<br /> <br /> By using username mount option along with sec=krb5 to search for<br /> principals from keytab is supported by cifs.upcall(8) since<br /> cifs-utils-4.8. So fix this by matching username mount option in<br /> match_session() even with Kerberos.<br /> <br /> For example, the second mount below should fail with -ENOKEY as there<br /> is no &amp;#39;foobar&amp;#39; principal in keytab (/etc/krb5.keytab). The client<br /> ends up reusing SMB session from first mount to perform the second<br /> one, which is wrong.<br /> <br /> ```<br /> $ ktutil<br /> ktutil: add_entry -password -p testuser -k 1 -e aes256-cts<br /> Password for testuser@ZELDA.TEST:<br /> ktutil: write_kt /etc/krb5.keytab<br /> ktutil: quit<br /> $ klist -ke<br /> Keytab name: FILE:/etc/krb5.keytab<br /> KVNO Principal<br /> ---- ----------------------------------------------------------------<br /> 1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96)<br /> $ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser<br /> $ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar<br /> $ mount -t cifs | grep -Po &amp;#39;username=\K\w+&amp;#39;<br /> testuser<br /> testuser<br /> ```

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Validate L2CAP_INFO_RSP payload length before access<br /> <br /> l2cap_information_rsp() checks that cmd_len covers the fixed<br /> l2cap_info_rsp header (type + result, 4 bytes) but then reads<br /> rsp-&gt;data without verifying that the payload is present:<br /> <br /> - L2CAP_IT_FEAT_MASK calls get_unaligned_le32(rsp-&gt;data), which reads<br /> 4 bytes past the header (needs cmd_len &gt;= 8).<br /> <br /> - L2CAP_IT_FIXED_CHAN reads rsp-&gt;data[0], 1 byte past the header<br /> (needs cmd_len &gt;= 5).<br /> <br /> A truncated L2CAP_INFO_RSP with result == L2CAP_IR_SUCCESS triggers an<br /> out-of-bounds read of adjacent skb data.<br /> <br /> Guard each data access with the required payload length check. If the<br /> payload is too short, skip the read and let the state machine complete<br /> with safe defaults (feat_mask and remote_fixed_chan remain zero from<br /> kzalloc), so the info timer cleanup and l2cap_conn_start() still run<br /> and the connection is not stalled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: fix crash in ieee80211_chan_bw_change for AP_VLAN stations<br /> <br /> ieee80211_chan_bw_change() iterates all stations and accesses<br /> link-&gt;reserved.oper via sta-&gt;sdata-&gt;link[link_id]. For stations on<br /> AP_VLAN interfaces (e.g. 4addr WDS clients), sta-&gt;sdata points to<br /> the VLAN sdata, whose link never participates in chanctx reservations.<br /> This leaves link-&gt;reserved.oper zero-initialized with chan == NULL,<br /> causing a NULL pointer dereference in __ieee80211_sta_cap_rx_bw()<br /> when accessing chandef-&gt;chan-&gt;band during CSA.<br /> <br /> Resolve the VLAN sdata to its parent AP sdata using get_bss_sdata()<br /> before accessing link data.<br /> <br /> [also change sta-&gt;sdata in ARRAY_SIZE even if it doesn&amp;#39;t matter]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: fix OOB access in DBG_BUF_PRODUCER async event handler<br /> <br /> The ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCER handler in<br /> bnxt_async_event_process() uses a firmware-supplied &amp;#39;type&amp;#39; field<br /> directly as an index into bp-&gt;bs_trace[] without bounds validation.<br /> <br /> The &amp;#39;type&amp;#39; field is a 16-bit value extracted from DMA-mapped completion<br /> ring memory that the NIC writes directly to host RAM. A malicious or<br /> compromised NIC can supply any value from 0 to 65535, causing an<br /> out-of-bounds access into kernel heap memory.<br /> <br /> The bnxt_bs_trace_check_wrap() call then dereferences bs_trace-&gt;magic_byte<br /> and writes to bs_trace-&gt;last_offset and bs_trace-&gt;wrapped, leading to<br /> kernel memory corruption or a crash.<br /> <br /> Fix by adding a bounds check and defining BNXT_TRACE_MAX as<br /> DBG_LOG_BUFFER_FLUSH_REQ_TYPE_ERR_QPC_TRACE + 1 to cover all currently<br /> defined firmware trace types (0x0 through 0xc).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: fix use-after-free access to PTP clock<br /> <br /> PTP clock is registered on every opening of the interface and destroyed on<br /> every closing. However it may be accessed via get_ts_info ethtool call<br /> which is possible while the interface is just present in the kernel.<br /> <br /> BUG: KASAN: use-after-free in ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426<br /> Read of size 4 at addr ffff8880194345cc by task syz.0.6/948<br /> <br /> CPU: 1 PID: 948 Comm: syz.0.6 Not tainted 6.1.164+ #109<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x8d/0xba lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:316 [inline]<br /> print_report+0x17f/0x496 mm/kasan/report.c:420<br /> kasan_report+0xd9/0x180 mm/kasan/report.c:524<br /> ptp_clock_index+0x47/0x50 drivers/ptp/ptp_clock.c:426<br /> gem_get_ts_info+0x138/0x1e0 drivers/net/ethernet/cadence/macb_main.c:3349<br /> macb_get_ts_info+0x68/0xb0 drivers/net/ethernet/cadence/macb_main.c:3371<br /> __ethtool_get_ts_info+0x17c/0x260 net/ethtool/common.c:558<br /> ethtool_get_ts_info net/ethtool/ioctl.c:2367 [inline]<br /> __dev_ethtool net/ethtool/ioctl.c:3017 [inline]<br /> dev_ethtool+0x2b05/0x6290 net/ethtool/ioctl.c:3095<br /> dev_ioctl+0x637/0x1070 net/core/dev_ioctl.c:510<br /> sock_do_ioctl+0x20d/0x2c0 net/socket.c:1215<br /> sock_ioctl+0x577/0x6d0 net/socket.c:1320<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x18c/0x210 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:46 [inline]<br /> do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> <br /> Allocated by task 457:<br /> kmalloc include/linux/slab.h:563 [inline]<br /> kzalloc include/linux/slab.h:699 [inline]<br /> ptp_clock_register+0x144/0x10e0 drivers/ptp/ptp_clock.c:235<br /> gem_ptp_init+0x46f/0x930 drivers/net/ethernet/cadence/macb_ptp.c:375<br /> macb_open+0x901/0xd10 drivers/net/ethernet/cadence/macb_main.c:2920<br /> __dev_open+0x2ce/0x500 net/core/dev.c:1501<br /> __dev_change_flags+0x56a/0x740 net/core/dev.c:8651<br /> dev_change_flags+0x92/0x170 net/core/dev.c:8722<br /> do_setlink+0xaf8/0x3a80 net/core/rtnetlink.c:2833<br /> __rtnl_newlink+0xbf4/0x1940 net/core/rtnetlink.c:3608<br /> rtnl_newlink+0x63/0xa0 net/core/rtnetlink.c:3655<br /> rtnetlink_rcv_msg+0x3c6/0xed0 net/core/rtnetlink.c:6150<br /> netlink_rcv_skb+0x15d/0x430 net/netlink/af_netlink.c:2511<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x6d7/0xa30 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x97e/0xeb0 net/netlink/af_netlink.c:1872<br /> sock_sendmsg_nosec net/socket.c:718 [inline]<br /> __sock_sendmsg+0x14b/0x180 net/socket.c:730<br /> __sys_sendto+0x320/0x3b0 net/socket.c:2152<br /> __do_sys_sendto net/socket.c:2164 [inline]<br /> __se_sys_sendto net/socket.c:2160 [inline]<br /> __x64_sys_sendto+0xdc/0x1b0 net/socket.c:2160<br /> do_syscall_x64 arch/x86/entry/common.c:46 [inline]<br /> do_syscall_64+0x35/0x80 arch/x86/entry/common.c:76<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Freed by task 938:<br /> kasan_slab_free include/linux/kasan.h:177 [inline]<br /> slab_free_hook mm/slub.c:1729 [inline]<br /> slab_free_freelist_hook mm/slub.c:1755 [inline]<br /> slab_free mm/slub.c:3687 [inline]<br /> __kmem_cache_free+0xbc/0x320 mm/slub.c:3700<br /> device_release+0xa0/0x240 drivers/base/core.c:2507<br /> kobject_cleanup lib/kobject.c:681 [inline]<br /> kobject_release lib/kobject.c:712 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> kobject_put+0x1cd/0x350 lib/kobject.c:729<br /> put_device+0x1b/0x30 drivers/base/core.c:3805<br /> ptp_clock_unregister+0x171/0x270 drivers/ptp/ptp_clock.c:391<br /> gem_ptp_remove+0x4e/0x1f0 drivers/net/ethernet/cadence/macb_ptp.c:404<br /> macb_close+0x1c8/0x270 drivers/net/ethernet/cadence/macb_main.c:2966<br /> __dev_close_many+0x1b9/0x310 net/core/dev.c:1585<br /> __dev_close net/core/dev.c:1597 [inline]<br /> __dev_change_flags+0x2bb/0x740 net/core/dev.c:8649<br /> dev_change_fl<br /> ---truncated---

*** Pendiente de traducción *** immich is a high performance self-hosted photo and video management solution. Prior to version 2.6.0, the Immich application is vulnerable to credential disclosure when a user authenticates to a shared album. During the authentication process, the application transmits the album password within the URL query parameters in a GET request to /api/shared-links/me. This exposes the password in browser history, proxy and server logs, and referrer headers, allowing unintended disclosure of authentication credentials. The impact of this vulnerability is the potential compromise of shared album access and unauthorized exposure of sensitive user data. This issue has been patched in version 2.6.0.

*** Pendiente de traducción *** FastMCP is the standard framework for building MCP applications. Prior to version 3.2.0, while testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user&amp;#39;s consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability. This issue has been patched in version 3.2.0.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fix use-after-free on controller registration failure<br /> <br /> Make sure to deregister from driver core also in the unlikely event that<br /> per-cpu statistics allocation fails during controller registration to<br /> avoid use-after-free (of driver resources) and unclocked register<br /> accesses.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix memory leak in xe_vm_madvise_ioctl<br /> <br /> When check_bo_args_are_sane() validation fails, jump to the new<br /> free_vmas cleanup label to properly free the allocated resources.<br /> This ensures proper cleanup in this error path.<br /> <br /> (cherry picked from commit 29bd06faf727a4b76663e4be0f7d770e2d2a7965)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/poll: fix multishot recv missing EOF on wakeup race<br /> <br /> When a socket send and shutdown() happen back-to-back, both fire<br /> wake-ups before the receiver&amp;#39;s task_work has a chance to run. The first<br /> wake gets poll ownership (poll_refs=1), and the second bumps it to 2.<br /> When io_poll_check_events() runs, it calls io_poll_issue() which does a<br /> recv that reads the data and returns IOU_RETRY. The loop then drains all<br /> accumulated refs (atomic_sub_return(2) -&gt; 0) and exits, even though only<br /> the first event was consumed. Since the shutdown is a persistent state<br /> change, no further wakeups will happen, and the multishot recv can hang<br /> forever.<br /> <br /> Check specifically for HUP in the poll loop, and ensure that another<br /> loop is done to check for status if more than a single poll activation<br /> is pending. This ensures we don&amp;#39;t lose the shutdown event.