Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: ets: Remove drr class from the active list if it changes to strict<br /> <br /> Whenever a user issues an ets qdisc change command, transforming a<br /> drr class into a strict one, the ets code isn&amp;#39;t checking whether that<br /> class was in the active list and removing it. This means that, if a<br /> user changes a strict class (which was in the active list) back to a drr<br /> one, that class will be added twice to the active list [1].<br /> <br /> Doing so with the following commands:<br /> <br /> tc qdisc add dev lo root handle 1: ets bands 2 strict 1<br /> tc qdisc add dev lo parent 1:2 handle 20: \<br /> tbf rate 8bit burst 100b latency 1s<br /> tc filter add dev lo parent 1: basic classid 1:2<br /> ping -c1 -W0.01 -s 56 127.0.0.1<br /> tc qdisc change dev lo root handle 1: ets bands 2 strict 2<br /> tc qdisc change dev lo root handle 1: ets bands 2 strict 1<br /> ping -c1 -W0.01 -s 56 127.0.0.1<br /> <br /> Will trigger the following splat with list debug turned on:<br /> <br /> [ 59.279014][ T365] ------------[ cut here ]------------<br /> [ 59.279452][ T365] list_add double add: new=ffff88801d60e350, prev=ffff88801d60e350, next=ffff88801d60e2c0.<br /> [ 59.280153][ T365] WARNING: CPU: 3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220<br /> [ 59.280860][ T365] Modules linked in:<br /> [ 59.281165][ T365] CPU: 3 UID: 0 PID: 365 Comm: tc Not tainted 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(voluntary)<br /> [ 59.281977][ T365] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> [ 59.282391][ T365] RIP: 0010:__list_add_valid_or_report+0x17f/0x220<br /> [ 59.282842][ T365] Code: 89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44<br /> ...<br /> [ 59.288812][ T365] Call Trace:<br /> [ 59.289056][ T365] <br /> [ 59.289224][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.289546][ T365] ets_qdisc_change+0xd2b/0x1e80<br /> [ 59.289891][ T365] ? __lock_acquire+0x7e7/0x1be0<br /> [ 59.290223][ T365] ? __pfx_ets_qdisc_change+0x10/0x10<br /> [ 59.290546][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.290898][ T365] ? __mutex_trylock_common+0xda/0x240<br /> [ 59.291228][ T365] ? __pfx___mutex_trylock_common+0x10/0x10<br /> [ 59.291655][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.291993][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.292313][ T365] ? trace_contention_end+0xc8/0x110<br /> [ 59.292656][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.293022][ T365] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 59.293351][ T365] tc_modify_qdisc+0x63a/0x1cf0<br /> <br /> Fix this by always checking and removing an ets class from the active list<br /> when changing it to strict.<br /> <br /> [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_ets.c?id=ce052b9402e461a9aded599f5b47e76bc727f7de#n663

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: fw_tracer, Validate format string parameters<br /> <br /> Add validation for format string parameters in the firmware tracer to<br /> prevent potential security vulnerabilities and crashes from malformed<br /> format strings received from firmware.<br /> <br /> The firmware tracer receives format strings from the device firmware and<br /> uses them to format trace messages. Without proper validation, bad<br /> firmware could provide format strings with invalid format specifiers<br /> (e.g., %s, %p, %n) that could lead to crashes, or other undefined<br /> behavior.<br /> <br /> Add mlx5_tracer_validate_params() to validate that all format specifiers<br /> in trace strings are limited to safe integer/hex formats (%x, %d, %i,<br /> %u, %llx, %lx, etc.). Reject strings containing other format types that<br /> could be used to access arbitrary memory or cause crashes.<br /> Invalid format strings are added to the trace output for visibility with<br /> "BAD_FORMAT: " prefix.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency<br /> <br /> Under high concurrency, A tree-connection object (tcon) is freed on<br /> a disconnect path while another path still holds a reference and later<br /> executes *_put()/write on it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Limit num_syncs to prevent oversized allocations<br /> <br /> The exec and vm_bind ioctl allow userspace to specify an arbitrary<br /> num_syncs value. Without bounds checking, a very large num_syncs<br /> can force an excessively large allocation, leading to kernel warnings<br /> from the page allocator as below.<br /> <br /> Introduce DRM_XE_MAX_SYNCS (set to 1024) and reject any request<br /> exceeding this limit.<br /> <br /> "<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 1217 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0x2f8/0x2180 mm/page_alloc.c:5124<br /> ...<br /> Call Trace:<br /> <br /> alloc_pages_mpol+0xe4/0x330 mm/mempolicy.c:2416<br /> ___kmalloc_large_node+0xd8/0x110 mm/slub.c:4317<br /> __kmalloc_large_node_noprof+0x18/0xe0 mm/slub.c:4348<br /> __do_kmalloc_node mm/slub.c:4364 [inline]<br /> __kmalloc_noprof+0x3d4/0x4b0 mm/slub.c:4388<br /> kmalloc_noprof include/linux/slab.h:909 [inline]<br /> kmalloc_array_noprof include/linux/slab.h:948 [inline]<br /> xe_exec_ioctl+0xa47/0x1e70 drivers/gpu/drm/xe/xe_exec.c:158<br /> drm_ioctl_kernel+0x1f1/0x3e0 drivers/gpu/drm/drm_ioctl.c:797<br /> drm_ioctl+0x5e7/0xc50 drivers/gpu/drm/drm_ioctl.c:894<br /> xe_drm_ioctl+0x10b/0x170 drivers/gpu/drm/xe/xe_device.c:224<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:598 [inline]<br /> __se_sys_ioctl fs/ioctl.c:584 [inline]<br /> __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xbb/0x380 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> ...<br /> "<br /> <br /> v2: Add "Reported-by" and Cc stable kernels.<br /> v3: Change XE_MAX_SYNCS from 64 to 1024. (Matt &amp; Ashutosh)<br /> v4: s/XE_MAX_SYNCS/DRM_XE_MAX_SYNCS/ (Matt)<br /> v5: Do the check at the top of the exec func. (Matt)<br /> <br /> (cherry picked from commit b07bac9bd708ec468cd1b8a5fe70ae2ac9b0a11c)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: fix io-uring list corruption for terminated non-committed requests<br /> <br /> When a request is terminated before it has been committed, the request<br /> is not removed from the queue&amp;#39;s list. This leaves a dangling list entry<br /> that leads to list corruption and use-after-free issues.<br /> <br /> Remove the request from the queue&amp;#39;s list for terminated non-committed<br /> requests.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix buffer validation by including null terminator size in EA length<br /> <br /> The smb2_set_ea function, which handles Extended Attributes (EA),<br /> was performing buffer validation checks that incorrectly omitted the size<br /> of the null terminating character (+1 byte) for EA Name.<br /> This patch fixes the issue by explicitly adding &amp;#39;+ 1&amp;#39; to EaNameLength where<br /> the null terminator is expected to be present in the buffer, ensuring<br /> the validation accurately reflects the total required buffer size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix race between wbt_enable_default and IO submission<br /> <br /> When wbt_enable_default() is moved out of queue freezing in elevator_change(),<br /> it can cause the wbt inflight counter to become negative (-1), leading to hung<br /> tasks in the writeback path. Tasks get stuck in wbt_wait() because the counter<br /> is in an inconsistent state.<br /> <br /> The issue occurs because wbt_enable_default() could race with IO submission,<br /> allowing the counter to be decremented before proper initialization. This manifests<br /> as:<br /> <br /> rq_wait[0]:<br /> inflight: -1<br /> has_waiters: True<br /> <br /> rwb_enabled() checks the state, which can be updated exactly between wbt_wait()<br /> (rq_qos_throttle()) and wbt_track()(rq_qos_track()), then the inflight counter<br /> will become negative.<br /> <br /> And results in hung task warnings like:<br /> task:kworker/u24:39 state:D stack:0 pid:14767<br /> Call Trace:<br /> rq_qos_wait+0xb4/0x150<br /> wbt_wait+0xa9/0x100<br /> __rq_qos_throttle+0x24/0x40<br /> blk_mq_submit_bio+0x672/0x7b0<br /> ...<br /> <br /> Fix this by:<br /> <br /> 1. Splitting wbt_enable_default() into:<br /> - __wbt_enable_default(): Returns true if wbt_init() should be called<br /> - wbt_enable_default(): Wrapper for existing callers (no init)<br /> - wbt_init_enable_default(): New function that checks and inits WBT<br /> <br /> 2. Using wbt_init_enable_default() in blk_register_queue() to ensure<br /> proper initialization during queue registration<br /> <br /> 3. Move wbt_init() out of wbt_enable_default() which is only for enabling<br /> disabled wbt from bfq and iocost, and wbt_init() isn&amp;#39;t needed. Then the<br /> original lock warning can be avoided.<br /> <br /> 4. Removing the ELEVATOR_FLAG_ENABLE_WBT_ON_EXIT flag and its handling<br /> code since it&amp;#39;s no longer needed<br /> <br /> This ensures WBT is properly initialized before any IO can be submitted,<br /> preventing the counter from going negative.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats<br /> <br /> Cited commit added a dedicated mutex (instead of RTNL) to protect the<br /> multicast route list, so that it will not change while the driver<br /> periodically traverses it in order to update the kernel about multicast<br /> route stats that were queried from the device.<br /> <br /> One instance of list entry deletion (during route replace) was missed<br /> and it can result in a use-after-free [1].<br /> <br /> Fix by acquiring the mutex before deleting the entry from the list and<br /> releasing it afterwards.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]<br /> Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043<br /> <br /> CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)<br /> Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017<br /> Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xba/0x110<br /> print_report+0x174/0x4f5<br /> kasan_report+0xdf/0x110<br /> mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]<br /> process_one_work+0x9cc/0x18e0<br /> worker_thread+0x5df/0xe40<br /> kthread+0x3b8/0x730<br /> ret_from_fork+0x3e9/0x560<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 29933:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum]<br /> mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]<br /> process_one_work+0x9cc/0x18e0<br /> worker_thread+0x5df/0xe40<br /> kthread+0x3b8/0x730<br /> ret_from_fork+0x3e9/0x560<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Freed by task 29933:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_save_free_info+0x3b/0x70<br /> __kasan_slab_free+0x43/0x70<br /> kfree+0x14e/0x700<br /> mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum]<br /> mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]<br /> process_one_work+0x9cc/0x18e0<br /> worker_thread+0x5df/0xe40<br /> kthread+0x3b8/0x730<br /> ret_from_fork+0x3e9/0x560<br /> ret_from_fork_asm+0x1a/0x30

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_router: Fix neighbour use-after-free<br /> <br /> We sometimes observe use-after-free when dereferencing a neighbour [1].<br /> The problem seems to be that the driver stores a pointer to the<br /> neighbour, but without holding a reference on it. A reference is only<br /> taken when the neighbour is used by a nexthop.<br /> <br /> Fix by simplifying the reference counting scheme. Always take a<br /> reference when storing a neighbour pointer in a neighbour entry. Avoid<br /> taking a referencing when the neighbour is used by a nexthop as the<br /> neighbour entry associated with the nexthop already holds a reference.<br /> <br /> Tested by running the test that uncovered the problem over 300 times.<br /> Without this patch the problem was reproduced after a handful of<br /> iterations.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310<br /> Read of size 8 at addr ffff88817f8e3420 by task ip/3929<br /> <br /> CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)<br /> Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6f/0xa0<br /> print_address_description.constprop.0+0x6e/0x300<br /> print_report+0xfc/0x1fb<br /> kasan_report+0xe4/0x110<br /> mlxsw_sp_neigh_entry_update+0x2d4/0x310<br /> mlxsw_sp_router_rif_gone_sync+0x35f/0x510<br /> mlxsw_sp_rif_destroy+0x1ea/0x730<br /> mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0<br /> __mlxsw_sp_inetaddr_lag_event+0xcc/0x130<br /> __mlxsw_sp_inetaddr_event+0xf5/0x3c0<br /> mlxsw_sp_router_netdevice_event+0x1015/0x1580<br /> notifier_call_chain+0xcc/0x150<br /> call_netdevice_notifiers_info+0x7e/0x100<br /> __netdev_upper_dev_unlink+0x10b/0x210<br /> netdev_upper_dev_unlink+0x79/0xa0<br /> vrf_del_slave+0x18/0x50<br /> do_set_master+0x146/0x7d0<br /> do_setlink.isra.0+0x9a0/0x2880<br /> rtnl_newlink+0x637/0xb20<br /> rtnetlink_rcv_msg+0x6fe/0xb90<br /> netlink_rcv_skb+0x123/0x380<br /> netlink_unicast+0x4a3/0x770<br /> netlink_sendmsg+0x75b/0xc90<br /> __sock_sendmsg+0xbe/0x160<br /> ____sys_sendmsg+0x5b2/0x7d0<br /> ___sys_sendmsg+0xfd/0x180<br /> __sys_sendmsg+0x124/0x1c0<br /> do_syscall_64+0xbb/0xfd0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> [...]<br /> <br /> Allocated by task 109:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x7b/0x90<br /> __kmalloc_noprof+0x2c1/0x790<br /> neigh_alloc+0x6af/0x8f0<br /> ___neigh_create+0x63/0xe90<br /> mlxsw_sp_nexthop_neigh_init+0x430/0x7e0<br /> mlxsw_sp_nexthop_type_init+0x212/0x960<br /> mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280<br /> mlxsw_sp_nexthop6_group_get+0x392/0x6a0<br /> mlxsw_sp_fib6_entry_create+0x46a/0xfd0<br /> mlxsw_sp_router_fib6_replace+0x1ed/0x5f0<br /> mlxsw_sp_router_fib6_event_work+0x10a/0x2a0<br /> process_one_work+0xd57/0x1390<br /> worker_thread+0x4d6/0xd40<br /> kthread+0x355/0x5b0<br /> ret_from_fork+0x1d4/0x270<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Freed by task 154:<br /> kasan_save_stack+0x30/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x43/0x70<br /> kmem_cache_free_bulk.part.0+0x1eb/0x5e0<br /> kvfree_rcu_bulk+0x1f2/0x260<br /> kfree_rcu_work+0x130/0x1b0<br /> process_one_work+0xd57/0x1390<br /> worker_thread+0x4d6/0xd40<br /> kthread+0x355/0x5b0<br /> ret_from_fork+0x1d4/0x270<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x30/0x50<br /> kasan_record_aux_stack+0x8c/0xa0<br /> kvfree_call_rcu+0x93/0x5b0<br /> mlxsw_sp_router_neigh_event_work+0x67d/0x860<br /> process_one_work+0xd57/0x1390<br /> worker_thread+0x4d6/0xd40<br /> kthread+0x355/0x5b0<br /> ret_from_fork+0x1d4/0x270<br /> ret_from_fork_asm+0x11/0x20

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: NFSv4 file creation neglects setting ACL<br /> <br /> An NFSv4 client that sets an ACL with a named principal during file<br /> creation retrieves the ACL afterwards, and finds that it is only a<br /> default ACL (based on the mode bits) and not the ACL that was<br /> requested during file creation. This violates RFC 8881 section<br /> 6.4.1.3: "the ACL attribute is set as given".<br /> <br /> The issue occurs in nfsd_create_setattr(), which calls<br /> nfsd_attrs_valid() to determine whether to call nfsd_setattr().<br /> However, nfsd_attrs_valid() checks only for iattr changes and<br /> security labels, but not POSIX ACLs. When only an ACL is present,<br /> the function returns false, nfsd_setattr() is skipped, and the<br /> POSIX ACL is never applied to the inode.<br /> <br /> Subsequently, when the client retrieves the ACL, the server finds<br /> no POSIX ACL on the inode and returns one generated from the file&amp;#39;s<br /> mode bits rather than returning the originally-specified ACL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/chrome: cros_ec_ishtp: Fix UAF after unbinding driver<br /> <br /> After unbinding the driver, another kthread `cros_ec_console_log_work`<br /> is still accessing the device, resulting an UAF and crash.<br /> <br /> The driver doesn&amp;#39;t unregister the EC device in .remove() which should<br /> shutdown sub-devices synchronously. Fix it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: initialize local pointers upon transfer of memory ownership<br /> <br /> vidtv_channel_si_init() creates a temporary list (program, service, event)<br /> and ownership of the memory itself is transferred to the PAT/SDT/EIT<br /> tables through vidtv_psi_pat_program_assign(),<br /> vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().<br /> <br /> The problem here is that the local pointer where the memory ownership<br /> transfer was completed is not initialized to NULL. This causes the<br /> vidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, and<br /> in the flow that jumps to free_eit, the memory that was freed by<br /> vidtv_psi_*_table_destroy() can be accessed again by<br /> vidtv_psi_*_event_destroy() due to the uninitialized local pointer, so it<br /> is freed once again.<br /> <br /> Therefore, to prevent use-after-free and double-free vulnerability,<br /> local pointers must be initialized to NULL when transferring memory<br /> ownership.