Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: Fix oops when HEVC init fails<br /> <br /> The stateless HEVC decoder saves the instance pointer in the context<br /> regardless if the initialization worked or not. This caused a use after<br /> free, when the pointer is freed in case of a failure in the deinit<br /> function.<br /> Only store the instance pointer when the initialization was successful,<br /> to solve this issue.<br /> <br /> Hardware name: Acer Tomato (rev3 - 4) board (DT)<br /> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]<br /> lr : vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]<br /> sp : ffff80008750bc20<br /> x29: ffff80008750bc20 x28: ffff1299f6d70000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffff80008750bc98 x22: 000000000000a003 x21: ffffd45c4cfae000<br /> x20: 0000000000000010 x19: ffff1299fd668310 x18: 000000000000001a<br /> x17: 000000040044ffff x16: ffffd45cb15dc648 x15: 0000000000000000<br /> x14: ffff1299c08da1c0 x13: ffffd45cb1f87a10 x12: ffffd45cb2f5fe80<br /> x11: 0000000000000001 x10: 0000000000001b30 x9 : ffffd45c4d12b488<br /> x8 : 1fffe25339380d81 x7 : 0000000000000001 x6 : ffff1299c9c06c00<br /> x5 : 0000000000000132 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000010 x1 : ffff80008750bc98 x0 : 0000000000000000<br /> Call trace:<br /> vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]<br /> vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]<br /> vpu_dec_deinit+0x1c/0x30 [mtk_vcodec_dec]<br /> vdec_hevc_slice_deinit+0x30/0x98 [mtk_vcodec_dec]<br /> vdec_if_deinit+0x38/0x68 [mtk_vcodec_dec]<br /> mtk_vcodec_dec_release+0x20/0x40 [mtk_vcodec_dec]<br /> fops_vcodec_release+0x64/0x118 [mtk_vcodec_dec]<br /> v4l2_release+0x7c/0x100<br /> __fput+0x80/0x2d8<br /> __fput_sync+0x58/0x70<br /> __arm64_sys_close+0x40/0x90<br /> invoke_syscall+0x50/0x128<br /> el0_svc_common.constprop.0+0x48/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x38/0xd8<br /> el0t_64_sync_handler+0xc0/0xc8<br /> el0t_64_sync+0x1a8/0x1b0<br /> Code: d503201f f9401660 b900127f b900227f (f9400400)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbmon: prevent division by zero in fb_videomode_from_videomode()<br /> <br /> The expression htotal * vtotal can have a zero value on<br /> overflow. It is necessary to prevent division by zero like in<br /> fb_var_to_videomode().<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Svace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: clear opcode specific data for an early failure<br /> <br /> If failure happens before the opcode prep handler is called, ensure that<br /> we clear the opcode specific area of the request, which holds data<br /> specific to that request type. This prevents errors where opcode<br /> handlers either don&amp;#39;t get to clear per-request private data since prep<br /> isn&amp;#39;t even called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: Limit read size on v1.2<br /> <br /> Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was<br /> increased from 16 to 256. In order to avoid overflowing reads for older<br /> systems, add a mechanism to use the read UCSI version to truncate read<br /> sizes on UCSI v1.2.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: prevent division by zero in blk_rq_stat_sum()<br /> <br /> The expression dst-&gt;nr_samples + src-&gt;nr_samples may<br /> have zero value on overflow. It is necessary to add<br /> a check to avoid division by zero.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Svace.

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.

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---

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

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.

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).

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.

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/