Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: platform: mtk-mdp3: Add missing check and free for ida_alloc<br /> <br /> Add the check for the return value of the ida_alloc in order to avoid<br /> NULL pointer dereference.<br /> Moreover, free allocated "ctx-&gt;id" if mdp_m2m_open fails later in order<br /> to avoid memory leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Move representor neigh cleanup to profile cleanup_tx<br /> <br /> For IP tunnel encapsulation in ECMP (Equal-Cost Multipath) mode, as<br /> the flow is duplicated to the peer eswitch, the related neighbour<br /> information on the peer uplink representor is created as well.<br /> <br /> In the cited commit, eswitch devcom unpair is moved to uplink unload<br /> API, specifically the profile-&gt;cleanup_tx. If there is a encap rule<br /> offloaded in ECMP mode, when one eswitch does unpair (because of<br /> unloading the driver, for instance), and the peer rule from the peer<br /> eswitch is going to be deleted, the use-after-free error is triggered<br /> while accessing neigh info, as it is already cleaned up in uplink&amp;#39;s<br /> profile-&gt;disable, which is before its profile-&gt;cleanup_tx.<br /> <br /> To fix this issue, move the neigh cleanup to profile&amp;#39;s cleanup_tx<br /> callback, and after mlx5e_cleanup_uplink_rep_tx is called. The neigh<br /> init is moved to init_tx for symmeter.<br /> <br /> [ 2453.376299] BUG: KASAN: slab-use-after-free in mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core]<br /> [ 2453.379125] Read of size 4 at addr ffff888127af9008 by task modprobe/2496<br /> <br /> [ 2453.381542] CPU: 7 PID: 2496 Comm: modprobe Tainted: G B 6.4.0-rc7+ #15<br /> [ 2453.383386] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 2453.384335] Call Trace:<br /> [ 2453.384625] <br /> [ 2453.384891] dump_stack_lvl+0x33/0x50<br /> [ 2453.385285] print_report+0xc2/0x610<br /> [ 2453.385667] ? __virt_addr_valid+0xb1/0x130<br /> [ 2453.386091] ? mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core]<br /> [ 2453.386757] kasan_report+0xae/0xe0<br /> [ 2453.387123] ? mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core]<br /> [ 2453.387798] mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core]<br /> [ 2453.388465] mlx5e_rep_encap_entry_detach+0xa6/0xe0 [mlx5_core]<br /> [ 2453.389111] mlx5e_encap_dealloc+0xa7/0x100 [mlx5_core]<br /> [ 2453.389706] mlx5e_tc_tun_encap_dests_unset+0x61/0xb0 [mlx5_core]<br /> [ 2453.390361] mlx5_free_flow_attr_actions+0x11e/0x340 [mlx5_core]<br /> [ 2453.391015] ? complete_all+0x43/0xd0<br /> [ 2453.391398] ? free_flow_post_acts+0x38/0x120 [mlx5_core]<br /> [ 2453.392004] mlx5e_tc_del_fdb_flow+0x4ae/0x690 [mlx5_core]<br /> [ 2453.392618] mlx5e_tc_del_fdb_peers_flow+0x308/0x370 [mlx5_core]<br /> [ 2453.393276] mlx5e_tc_clean_fdb_peer_flows+0xf5/0x140 [mlx5_core]<br /> [ 2453.393925] mlx5_esw_offloads_unpair+0x86/0x540 [mlx5_core]<br /> [ 2453.394546] ? mlx5_esw_offloads_set_ns_peer.isra.0+0x180/0x180 [mlx5_core]<br /> [ 2453.395268] ? down_write+0xaa/0x100<br /> [ 2453.395652] mlx5_esw_offloads_devcom_event+0x203/0x530 [mlx5_core]<br /> [ 2453.396317] mlx5_devcom_send_event+0xbb/0x190 [mlx5_core]<br /> [ 2453.396917] mlx5_esw_offloads_devcom_cleanup+0xb0/0xd0 [mlx5_core]<br /> [ 2453.397582] mlx5e_tc_esw_cleanup+0x42/0x120 [mlx5_core]<br /> [ 2453.398182] mlx5e_rep_tc_cleanup+0x15/0x30 [mlx5_core]<br /> [ 2453.398768] mlx5e_cleanup_rep_tx+0x6c/0x80 [mlx5_core]<br /> [ 2453.399367] mlx5e_detach_netdev+0xee/0x120 [mlx5_core]<br /> [ 2453.399957] mlx5e_netdev_change_profile+0x84/0x170 [mlx5_core]<br /> [ 2453.400598] mlx5e_vport_rep_unload+0xe0/0xf0 [mlx5_core]<br /> [ 2453.403781] mlx5_eswitch_unregister_vport_reps+0x15e/0x190 [mlx5_core]<br /> [ 2453.404479] ? mlx5_eswitch_register_vport_reps+0x200/0x200 [mlx5_core]<br /> [ 2453.405170] ? up_write+0x39/0x60<br /> [ 2453.405529] ? kernfs_remove_by_name_ns+0xb7/0xe0<br /> [ 2453.405985] auxiliary_bus_remove+0x2e/0x40<br /> [ 2453.406405] device_release_driver_internal+0x243/0x2d0<br /> [ 2453.406900] ? kobject_put+0x42/0x2d0<br /> [ 2453.407284] bus_remove_device+0x128/0x1d0<br /> [ 2453.407687] device_del+0x240/0x550<br /> [ 2453.408053] ? waiting_for_supplier_show+0xe0/0xe0<br /> [ 2453.408511] ? kobject_put+0xfa/0x2d0<br /> [ 2453.408889] ? __kmem_cache_free+0x14d/0x280<br /> [ 2453.409310] mlx5_rescan_drivers_locked.part.0+0xcd/0x2b0 [mlx5_core]<br /> [ 2453.409973] mlx5_unregister_device+0x40/0x50 [mlx5_core]<br /> [ 2453.410561] mlx5_uninit_one+0x3d/0x110 [mlx5_core]<br /> [ 2453.411111] remove_one+0x89/0x130 [mlx5_core]<br /> [ 24<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: avoid suspicious RCU usage for synced VLAN-aware MAC addresses<br /> <br /> When using the felix driver (the only one which supports UC filtering<br /> and MC filtering) as a DSA master for a random other DSA switch, one can<br /> see the following stack trace when the downstream switch ports join a<br /> VLAN-aware bridge:<br /> <br /> =============================<br /> WARNING: suspicious RCU usage<br /> -----------------------------<br /> net/8021q/vlan_core.c:238 suspicious rcu_dereference_protected() usage!<br /> <br /> stack backtrace:<br /> Workqueue: dsa_ordered dsa_slave_switchdev_event_work<br /> Call trace:<br /> lockdep_rcu_suspicious+0x170/0x210<br /> vlan_for_each+0x8c/0x188<br /> dsa_slave_sync_uc+0x128/0x178<br /> __hw_addr_sync_dev+0x138/0x158<br /> dsa_slave_set_rx_mode+0x58/0x70<br /> __dev_set_rx_mode+0x88/0xa8<br /> dev_uc_add+0x74/0xa0<br /> dsa_port_bridge_host_fdb_add+0xec/0x180<br /> dsa_slave_switchdev_event_work+0x7c/0x1c8<br /> process_one_work+0x290/0x568<br /> <br /> What it&amp;#39;s saying is that vlan_for_each() expects rtnl_lock() context and<br /> it&amp;#39;s not getting it, when it&amp;#39;s called from the DSA master&amp;#39;s ndo_set_rx_mode().<br /> <br /> The caller of that - dsa_slave_set_rx_mode() - is the slave DSA<br /> interface&amp;#39;s dsa_port_bridge_host_fdb_add() which comes from the deferred<br /> dsa_slave_switchdev_event_work().<br /> <br /> We went to great lengths to avoid the rtnl_lock() context in that call<br /> path in commit 0faf890fc519 ("net: dsa: drop rtnl_lock from<br /> dsa_slave_switchdev_event_work"), and calling rtnl_lock() is simply not<br /> an option due to the possibility of deadlocking when calling<br /> dsa_flush_workqueue() from the call paths that do hold rtnl_lock() -<br /> basically all of them.<br /> <br /> So, when the DSA master calls vlan_for_each() from its ndo_set_rx_mode(),<br /> the state of the 8021q driver on this device is really not protected<br /> from concurrent access by anything.<br /> <br /> Looking at net/8021q/, I don&amp;#39;t think that vlan_info-&gt;vid_list was<br /> particularly designed with RCU traversal in mind, so introducing an RCU<br /> read-side form of vlan_for_each() - vlan_for_each_rcu() - won&amp;#39;t be so<br /> easy, and it also wouldn&amp;#39;t be exactly what we need anyway.<br /> <br /> In general I believe that the solution isn&amp;#39;t in net/8021q/ anyway;<br /> vlan_for_each() is not cut out for this task. DSA doesn&amp;#39;t need rtnl_lock()<br /> to be held per se - since it&amp;#39;s not a netdev state change that we&amp;#39;re<br /> blocking, but rather, just concurrent additions/removals to a VLAN list.<br /> We don&amp;#39;t even need sleepable context - the callback of vlan_for_each()<br /> just schedules deferred work.<br /> <br /> The proposed escape is to remove the dependency on vlan_for_each() and<br /> to open-code a non-sleepable, rtnl-free alternative to that, based on<br /> copies of the VLAN list modified from .ndo_vlan_rx_add_vid() and<br /> .ndo_vlan_rx_kill_vid().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rt2x00: Fix memory leak when handling surveys<br /> <br /> When removing a rt2x00 device, its associated channel surveys<br /> are not freed, causing a memory leak observable with kmemleak:<br /> <br /> unreferenced object 0xffff9620f0881a00 (size 512):<br /> comm "systemd-udevd", pid 2290, jiffies 4294906974 (age 33.768s)<br /> hex dump (first 32 bytes):<br /> 70 44 12 00 00 00 00 00 92 8a 00 00 00 00 00 00 pD..............<br /> 00 00 00 00 00 00 00 00 ab 87 01 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc+0x4b/0x130<br /> [] rt2800_probe_hw+0xc2b/0x1380 [rt2800lib]<br /> [] rt2800usb_probe_hw+0xe/0x60 [rt2800usb]<br /> [] rt2x00lib_probe_dev+0x21a/0x7d0 [rt2x00lib]<br /> [] rt2x00usb_probe+0x1be/0x980 [rt2x00usb]<br /> [] usb_probe_interface+0xe2/0x310 [usbcore]<br /> [] really_probe+0x1a5/0x410<br /> [] __driver_probe_device+0x78/0x180<br /> [] driver_probe_device+0x1e/0x90<br /> [] __driver_attach+0xd2/0x1c0<br /> [] bus_for_each_dev+0x77/0xd0<br /> [] bus_add_driver+0x112/0x210<br /> [] driver_register+0x5c/0x120<br /> [] usb_register_driver+0x88/0x150 [usbcore]<br /> [] do_one_initcall+0x44/0x220<br /> [] do_init_module+0x4c/0x220<br /> <br /> Fix this by freeing the channel surveys on device removal.<br /> <br /> Tested with a RT3070 based USB wireless adapter.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: stop parsing non-compact HEAD index if clusterofs is invalid<br /> <br /> Syzbot generated a crafted image [1] with a non-compact HEAD index of<br /> clusterofs 33024 while valid numbers should be 0 ~ lclustersize-1,<br /> which causes the following unexpected behavior as below:<br /> <br /> BUG: unable to handle page fault for address: fffff52101a3fff9<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 23ffed067 P4D 23ffed067 PUD 0<br /> Oops: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 1 PID: 4398 Comm: kworker/u5:1 Not tainted 6.3.0-rc6-syzkaller-g09a9639e56c0 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023<br /> Workqueue: erofs_worker z_erofs_decompressqueue_work<br /> RIP: 0010:z_erofs_decompress_queue+0xb7e/0x2b40<br /> ...<br /> Call Trace:<br /> <br /> z_erofs_decompressqueue_work+0x99/0xe0<br /> process_one_work+0x8f6/0x1170<br /> worker_thread+0xa63/0x1210<br /> kthread+0x270/0x300<br /> ret_from_fork+0x1f/0x30<br /> <br /> Note that normal images or images using compact indexes are not<br /> impacted. Let&amp;#39;s fix this now.<br /> <br /> [1] https://lore.kernel.org/r/000000000000ec75b005ee97fbaa@google.com

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfp: clean mc addresses in application firmware when closing port<br /> <br /> When moving devices from one namespace to another, mc addresses are<br /> cleaned in software while not removed from application firmware. Thus<br /> the mc addresses are remained and will cause resource leak.<br /> <br /> Now use `__dev_mc_unsync` to clean mc addresses when closing port.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> autofs: fix memory leak of waitqueues in autofs_catatonic_mode<br /> <br /> Syzkaller reports a memory leak:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88810b279e00 (size 96):<br /> comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........&amp;#39;.....<br /> 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..&amp;#39;.............<br /> backtrace:<br /> [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046<br /> [] kmalloc include/linux/slab.h:576 [inline]<br /> [] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378<br /> [] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593<br /> [] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619<br /> [] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897<br /> [] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910<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+0xfc/0x140 fs/ioctl.c:856<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> autofs_wait_queue structs should be freed if their wait_ctr becomes zero.<br /> Otherwise they will be lost.<br /> <br /> In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a new<br /> waitqueue struct is allocated in autofs_wait(), its initial wait_ctr<br /> equals 2. After that wait_event_killable() is interrupted (it returns<br /> -ERESTARTSYS), so that &amp;#39;wq-&gt;name.name == NULL&amp;#39; condition may be not<br /> satisfied. Actually, this condition can be satisfied when<br /> autofs_wait_release() or autofs_catatonic_mode() is called and, what is<br /> also important, wait_ctr is decremented in those places. Upon the exit of<br /> autofs_wait(), wait_ctr is decremented to 1. Then the unmounting process<br /> begins: kill_sb calls autofs_catatonic_mode(), which should have freed the<br /> waitqueues, but it only decrements its usage counter to zero which is not<br /> a correct behaviour.<br /> <br /> edit:imk<br /> This description is of course not correct. The umount performed as a result<br /> of an expire is a umount of a mount that has been automounted, it&amp;#39;s not the<br /> autofs mount itself. They happen independently, usually after everything<br /> mounted within the autofs file system has been expired away. If everything<br /> hasn&amp;#39;t been expired away the automount daemon can still exit leaving mounts<br /> in place. But expires done in both cases will result in a notification that<br /> calls autofs_wait_release() with a result status. The problem case is the<br /> summary execution of of the automount daemon. In this case any waiting<br /> processes won&amp;#39;t be woken up until either they are terminated or the mount<br /> is umounted.<br /> end edit: imk<br /> <br /> So in catatonic mode we should free waitqueues which counter becomes zero.<br /> <br /> edit: imk<br /> Initially I was concerned that the calling of autofs_wait_release() and<br /> autofs_catatonic_mode() was not mutually exclusive but that can&amp;#39;t be the<br /> case (obviously) because the queue entry (or entries) is removed from the<br /> list when either of these two functions are called. Consequently the wait<br /> entry will be freed by only one of these functions or by the woken process<br /> in autofs_wait() depending on the order of the calls.<br /> end edit: imk

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> maple_tree: fix potential out-of-bounds access in mas_wr_end_piv()<br /> <br /> Check the write offset end bounds before using it as the offset into the<br /> pivot array. This avoids a possible out-of-bounds access on the pivot<br /> array if the write extends to the last slot in the node, in which case the<br /> node maximum should be used as the end pivot.<br /> <br /> akpm: this doesn&amp;#39;t affect any current callers, but new users of mapletree<br /> may encounter this problem if backported into earlier kernels, so let&amp;#39;s<br /> fix it in -stable kernels in case of this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: sprd: Fix DMA buffer leak issue<br /> <br /> Release DMA buffer when _probe() returns failure to avoid memory leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/type1: fix cap_migration information leak<br /> <br /> Fix an information leak where an uninitialized hole in struct<br /> vfio_iommu_type1_info_cap_migration on the stack is exposed to userspace.<br /> <br /> The definition of struct vfio_iommu_type1_info_cap_migration contains a hole as<br /> shown in this pahole(1) output:<br /> <br /> struct vfio_iommu_type1_info_cap_migration {<br /> struct vfio_info_cap_header header; /* 0 8 */<br /> __u32 flags; /* 8 4 */<br /> <br /> /* XXX 4 bytes hole, try to pack */<br /> <br /> __u64 pgsize_bitmap; /* 16 8 */<br /> __u64 max_dirty_bitmap_size; /* 24 8 */<br /> <br /> /* size: 32, cachelines: 1, members: 4 */<br /> /* sum members: 28, holes: 1, sum holes: 4 */<br /> /* last cacheline: 32 bytes */<br /> };<br /> <br /> The cap_mig variable is filled in without initializing the hole:<br /> <br /> static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu,<br /> struct vfio_info_cap *caps)<br /> {<br /> struct vfio_iommu_type1_info_cap_migration cap_mig;<br /> <br /> cap_mig.header.id = VFIO_IOMMU_TYPE1_INFO_CAP_MIGRATION;<br /> cap_mig.header.version = 1;<br /> <br /> cap_mig.flags = 0;<br /> /* support minimum pgsize */<br /> cap_mig.pgsize_bitmap = (size_t)1 id, cap-&gt;version);<br /> if (IS_ERR(header))<br /> return PTR_ERR(header);<br /> <br /> memcpy(header + 1, cap + 1, size - sizeof(*header));<br /> <br /> return 0;<br /> }<br /> <br /> This issue was found by code inspection.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: fix NULL-deref on irq uninstall<br /> <br /> In case of early initialisation errors and on platforms that do not use<br /> the DPU controller, the deinitilisation code can be called with the kms<br /> pointer set to NULL.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/525104/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/user_events: Ensure write index cannot be negative<br /> <br /> The write index indicates which event the data is for and accesses a<br /> per-file array. The index is passed by user processes during write()<br /> calls as the first 4 bytes. Ensure that it cannot be negative by<br /> returning -EINVAL to prevent out of bounds accesses.<br /> <br /> Update ftrace self-test to ensure this occurs properly.