Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: iaa - Fix async_disable descriptor leak<br /> <br /> The disable_async paths of iaa_compress/decompress() don&amp;#39;t free idxd<br /> descriptors in the async_disable case. Currently this only happens in<br /> the testcases where req-&gt;dst is set to null. Add a test to free them<br /> in those paths.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Check output polling initialized before disabling<br /> <br /> In drm_kms_helper_poll_disable() check if output polling<br /> support is initialized before disabling polling. If not flag<br /> this as a warning.<br /> Additionally in drm_mode_config_helper_suspend() and<br /> drm_mode_config_helper_resume() calls, that re the callers of these<br /> functions, avoid invoking them if polling is not initialized.<br /> For drivers like hyperv-drm, that do not initialize connector<br /> polling, if suspend is called without this check, it leads to<br /> suspend failure with following stack<br /> [ 770.719392] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.<br /> [ 770.720592] printk: Suspending console(s) (use no_console_suspend to debug)<br /> [ 770.948823] ------------[ cut here ]------------<br /> [ 770.948824] WARNING: CPU: 1 PID: 17197 at kernel/workqueue.c:3162 __flush_work.isra.0+0x212/0x230<br /> [ 770.948831] Modules linked in: rfkill nft_counter xt_conntrack xt_owner udf nft_compat crc_itu_t nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink vfat fat mlx5_ib ib_uverbs ib_core mlx5_core intel_rapl_msr intel_rapl_common kvm_amd ccp mlxfw kvm psample hyperv_drm tls drm_shmem_helper drm_kms_helper irqbypass pcspkr syscopyarea sysfillrect sysimgblt hv_balloon hv_utils joydev drm fuse xfs libcrc32c pci_hyperv pci_hyperv_intf sr_mod sd_mod cdrom t10_pi sg hv_storvsc scsi_transport_fc hv_netvsc serio_raw hyperv_keyboard hid_hyperv crct10dif_pclmul crc32_pclmul crc32c_intel hv_vmbus ghash_clmulni_intel dm_mirror dm_region_hash dm_log dm_mod<br /> [ 770.948863] CPU: 1 PID: 17197 Comm: systemd-sleep Not tainted 5.14.0-362.2.1.el9_3.x86_64 #1<br /> [ 770.948865] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022<br /> [ 770.948866] RIP: 0010:__flush_work.isra.0+0x212/0x230<br /> [ 770.948869] Code: 8b 4d 00 4c 8b 45 08 89 ca 48 c1 e9 04 83 e2 08 83 e1 0f 83 ca 02 89 c8 48 0f ba 6d 00 03 e9 25 ff ff ff 0f 0b e9 4e ff ff ff 0b 45 31 ed e9 44 ff ff ff e8 8f 89 b2 00 66 66 2e 0f 1f 84 00<br /> [ 770.948870] RSP: 0018:ffffaf4ac213fb10 EFLAGS: 00010246<br /> [ 770.948871] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8c992857<br /> [ 770.948872] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff9aad82b00330<br /> [ 770.948873] RBP: ffff9aad82b00330 R08: 0000000000000000 R09: ffff9aad87ee3d10<br /> [ 770.948874] R10: 0000000000000200 R11: 0000000000000000 R12: ffff9aad82b00330<br /> [ 770.948874] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001<br /> [ 770.948875] FS: 00007ff1b2f6bb40(0000) GS:ffff9aaf37d00000(0000) knlGS:0000000000000000<br /> [ 770.948878] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 770.948878] CR2: 0000555f345cb666 CR3: 00000001462dc005 CR4: 0000000000370ee0<br /> [ 770.948879] Call Trace:<br /> [ 770.948880] <br /> [ 770.948881] ? show_trace_log_lvl+0x1c4/0x2df<br /> [ 770.948884] ? show_trace_log_lvl+0x1c4/0x2df<br /> [ 770.948886] ? __cancel_work_timer+0x103/0x190<br /> [ 770.948887] ? __flush_work.isra.0+0x212/0x230<br /> [ 770.948889] ? __warn+0x81/0x110<br /> [ 770.948891] ? __flush_work.isra.0+0x212/0x230<br /> [ 770.948892] ? report_bug+0x10a/0x140<br /> [ 770.948895] ? handle_bug+0x3c/0x70<br /> [ 770.948898] ? exc_invalid_op+0x14/0x70<br /> [ 770.948899] ? asm_exc_invalid_op+0x16/0x20<br /> [ 770.948903] ? __flush_work.isra.0+0x212/0x230<br /> [ 770.948905] __cancel_work_timer+0x103/0x190<br /> [ 770.948907] ? _raw_spin_unlock_irqrestore+0xa/0x30<br /> [ 770.948910] drm_kms_helper_poll_disable+0x1e/0x40 [drm_kms_helper]<br /> [ 770.948923] drm_mode_config_helper_suspend+0x1c/0x80 [drm_kms_helper]<br /> [ 770.948933] ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus]<br /> [ 770.948942] hyperv_vmbus_suspend+0x17/0x40 [hyperv_drm]<br /> [ 770.948944] ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus]<br /> [ 770.948951] dpm_run_callback+0x4c/0x140<br /> [ 770.948954] __device_suspend_noir<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/amdgpu: Fix potential ioremap() memory leaks in amdgpu_device_init()<br /> <br /> This ensures that the memory mapped by ioremap for adev-&gt;rmmio, is<br /> properly handled in amdgpu_device_init(). If the function exits early<br /> due to an error, the memory is unmapped. If the function completes<br /> successfully, the memory remains mapped.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4337 amdgpu_device_init() warn: &amp;#39;adev-&gt;rmmio&amp;#39; from ioremap() not released on lines: 4035,4045,4051,4058,4068,4337

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu/nocb: Fix WARN_ON_ONCE() in the rcu_nocb_bypass_lock()<br /> <br /> For the kernels built with CONFIG_RCU_NOCB_CPU_DEFAULT_ALL=y and<br /> CONFIG_RCU_LAZY=y, the following scenarios will trigger WARN_ON_ONCE()<br /> in the rcu_nocb_bypass_lock() and rcu_nocb_wait_contended() functions:<br /> <br /> CPU2 CPU11<br /> kthread<br /> rcu_nocb_cb_kthread ksys_write<br /> rcu_do_batch vfs_write<br /> rcu_torture_timer_cb proc_sys_write<br /> __kmem_cache_free proc_sys_call_handler<br /> kmemleak_free drop_caches_sysctl_handler<br /> delete_object_full drop_slab<br /> __delete_object shrink_slab<br /> put_object lazy_rcu_shrink_scan<br /> call_rcu rcu_nocb_flush_bypass<br /> __call_rcu_commn rcu_nocb_bypass_lock<br /> raw_spin_trylock(&amp;rdp-&gt;nocb_bypass_lock) fail<br /> atomic_inc(&amp;rdp-&gt;nocb_lock_contended);<br /> rcu_nocb_wait_contended WARN_ON_ONCE(smp_processor_id() != rdp-&gt;cpu);<br /> WARN_ON_ONCE(atomic_read(&amp;rdp-&gt;nocb_lock_contended)) |<br /> |_ _ _ _ _ _ _ _ _ _same rdp and rdp-&gt;cpu != 11_ _ _ _ _ _ _ _ _ __|<br /> <br /> Reproduce this bug with "echo 3 &gt; /proc/sys/vm/drop_caches".<br /> <br /> This commit therefore uses rcu_nocb_try_flush_bypass() instead of<br /> rcu_nocb_flush_bypass() in lazy_rcu_shrink_scan(). If the nocb_bypass<br /> queue is being flushed, then rcu_nocb_try_flush_bypass will return<br /> directly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sysv: don&amp;#39;t call sb_bread() with pointers_lock held<br /> <br /> syzbot is reporting sleep in atomic context in SysV filesystem [1], for<br /> sb_bread() is called with rw_spinlock held.<br /> <br /> A "write_lock(&amp;pointers_lock) =&gt; read_lock(&amp;pointers_lock) deadlock" bug<br /> and a "sb_bread() with write_lock(&amp;pointers_lock)" bug were introduced by<br /> "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.<br /> <br /> Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the<br /> former bug by moving pointers_lock lock to the callers, but instead<br /> introduced a "sb_bread() with read_lock(&amp;pointers_lock)" bug (which made<br /> this problem easier to hit).<br /> <br /> Al Viro suggested that why not to do like get_branch()/get_block()/<br /> find_shared() in Minix filesystem does. And doing like that is almost a<br /> revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()<br /> from with find_shared() is called without write_lock(&amp;pointers_lock).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-buf: Fix NULL pointer dereference in sanitycheck()<br /> <br /> If due to a memory allocation failure mock_chain() returns NULL, it is<br /> passed to dma_fence_enable_sw_signaling() resulting in NULL pointer<br /> dereference there.<br /> <br /> Call dma_fence_enable_sw_signaling() only if mock_chain() succeeds.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/bpf: Fix bpf_plt pointer arithmetic<br /> <br /> Kui-Feng Lee reported a crash on s390x triggered by the<br /> dummy_st_ops/dummy_init_ptr_arg test [1]:<br /> <br /> [] 0x2<br /> [] bpf_struct_ops_test_run+0x156/0x250<br /> [] __sys_bpf+0xa1a/0xd00<br /> [] __s390x_sys_bpf+0x44/0x50<br /> [] __do_syscall+0x244/0x300<br /> [] system_call+0x70/0x98<br /> <br /> This is caused by GCC moving memcpy() after assignments in<br /> bpf_jit_plt(), resulting in NULL pointers being written instead of<br /> the return and the target addresses.<br /> <br /> Looking at the GCC internals, the reordering is allowed because the<br /> alias analysis thinks that the memcpy() destination and the assignments&amp;#39;<br /> left-hand-sides are based on different objects: new_plt and<br /> bpf_plt_ret/bpf_plt_target respectively, and therefore they cannot<br /> alias.<br /> <br /> This is in turn due to a violation of the C standard:<br /> <br /> When two pointers are subtracted, both shall point to elements of the<br /> same array object, or one past the last element of the array object<br /> ...<br /> <br /> From the C&amp;#39;s perspective, bpf_plt_ret and bpf_plt are distinct objects<br /> and cannot be subtracted. In the practical terms, doing so confuses the<br /> GCC&amp;#39;s alias analysis.<br /> <br /> The code was written this way in order to let the C side know a few<br /> offsets defined in the assembly. While nice, this is by no means<br /> necessary. Fix the noncompliance by hardcoding these offsets.<br /> <br /> [1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: fix possible cp null dereference<br /> <br /> cp might be null, calling cp-&gt;cp_conn would produce null dereference<br /> <br /> [Simon Horman adds:]<br /> <br /> Analysis:<br /> <br /> * cp is a parameter of __rds_rdma_map and is not reassigned.<br /> <br /> * The following call-sites pass a NULL cp argument to __rds_rdma_map()<br /> <br /> - rds_get_mr()<br /> - rds_get_mr_for_dest<br /> <br /> * Prior to the code above, the following assumes that cp may be NULL<br /> (which is indicative, but could itself be unnecessary)<br /> <br /> trans_private = rs-&gt;rs_transport-&gt;get_mr(<br /> sg, nents, rs, &amp;mr-&gt;r_key, cp ? cp-&gt;cp_conn : NULL,<br /> args-&gt;vec.addr, args-&gt;vec.bytes,<br /> need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);<br /> <br /> * The code modified by this patch is guarded by IS_ERR(trans_private),<br /> where trans_private is assigned as per the previous point in this analysis.<br /> <br /> The only implementation of get_mr that I could locate is rds_ib_get_mr()<br /> which can return an ERR_PTR if the conn (4th) argument is NULL.<br /> <br /> * ret is set to PTR_ERR(trans_private).<br /> rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.<br /> Thus ret may be -ENODEV in which case the code in question will execute.<br /> <br /> Conclusion:<br /> * cp may be NULL at the point where this patch adds a check;<br /> this patch does seem to address a possible bug

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/bpf: Fix IP after emitting call depth accounting<br /> <br /> Adjust the IP passed to `emit_patch` so it calculates the correct offset<br /> for the CALL instruction if `x86_call_depth_emit_accounting` emits code.<br /> Otherwise we will skip some instructions and most likely crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux: avoid dereference of garbage after mount failure<br /> <br /> In case kern_mount() fails and returns an error pointer return in the<br /> error branch instead of continuing and dereferencing the error pointer.<br /> <br /> While on it drop the never read static variable selinuxfs_mount.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Protect against int overflow for stack access size<br /> <br /> This patch re-introduces protection against the size of access to stack<br /> memory being negative; the access size can appear negative as a result<br /> of overflowing its signed int representation. This should not actually<br /> happen, as there are other protections along the way, but we should<br /> protect against it anyway. One code path was missing such protections<br /> (fixed in the previous patch in the series), causing out-of-bounds array<br /> accesses in check_stack_range_initialized(). This patch causes the<br /> verification of a program with such a non-sensical access size to fail.<br /> <br /> This check used to exist in a more indirect way, but was inadvertendly<br /> removed in a833a17aeac7.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Send DTBCLK disable message on first commit<br /> <br /> [Why]<br /> Previous patch to allow DTBCLK disable didn&amp;#39;t address boot case. Driver<br /> thinks DTBCLK is disabled by default, so we don&amp;#39;t send disable message to<br /> PMFW. DTBCLK is then enabled at idle desktop on boot, burning power.<br /> <br /> [How]<br /> Set dtbclk_en to true on boot so that disable message is sent during first<br /> commit.