Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix potential index out of bounds in color transformation function<br /> <br /> Fixes index out of bounds issue in the color transformation function.<br /> The issue could occur when the index &amp;#39;i&amp;#39; exceeds the number of transfer<br /> function points (TRANSFER_FUNC_POINTS).<br /> <br /> The fix adds a check to ensure &amp;#39;i&amp;#39; is within bounds before accessing the<br /> transfer function points. If &amp;#39;i&amp;#39; is out of bounds, an error message is<br /> logged and the function returns false to indicate an error.<br /> <br /> Reported by smatch:<br /> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow &amp;#39;output_tf-&gt;tf_pts.red&amp;#39; 1025 tf_pts.green&amp;#39; 1025 tf_pts.blue&amp;#39; 1025

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Discard command completions in internal error<br /> <br /> Fix use after free when FW completion arrives while device is in<br /> internal error state. Avoid calling completion handler in this case,<br /> since the device will flush the command interface and trigger all<br /> completions manually.<br /> <br /> Kernel log:<br /> ------------[ cut here ]------------<br /> refcount_t: underflow; use-after-free.<br /> ...<br /> RIP: 0010:refcount_warn_saturate+0xd8/0xe0<br /> ...<br /> Call Trace:<br /> <br /> ? __warn+0x79/0x120<br /> ? refcount_warn_saturate+0xd8/0xe0<br /> ? report_bug+0x17c/0x190<br /> ? handle_bug+0x3c/0x60<br /> ? exc_invalid_op+0x14/0x70<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? refcount_warn_saturate+0xd8/0xe0<br /> cmd_ent_put+0x13b/0x160 [mlx5_core]<br /> mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]<br /> cmd_comp_notifier+0x1f/0x30 [mlx5_core]<br /> notifier_call_chain+0x35/0xb0<br /> atomic_notifier_call_chain+0x16/0x20<br /> mlx5_eq_async_int+0xf6/0x290 [mlx5_core]<br /> notifier_call_chain+0x35/0xb0<br /> atomic_notifier_call_chain+0x16/0x20<br /> irq_int_handler+0x19/0x30 [mlx5_core]<br /> __handle_irq_event_percpu+0x4b/0x160<br /> handle_irq_event+0x2e/0x80<br /> handle_edge_irq+0x98/0x230<br /> __common_interrupt+0x3b/0xa0<br /> common_interrupt+0x7b/0xa0<br /> <br /> <br /> asm_common_interrupt+0x22/0x40

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Add a timeout to acquire the command queue semaphore<br /> <br /> Prevent forced completion handling on an entry that has not yet been<br /> assigned an index, causing an out of bounds access on idx = -22.<br /> Instead of waiting indefinitely for the sem, blocking flow now waits for<br /> index to be allocated or a sem acquisition timeout before beginning the<br /> timer for FW completion.<br /> <br /> Kernel log example:<br /> mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix overwriting ct original tuple for ICMPv6<br /> <br /> OVS_PACKET_CMD_EXECUTE has 3 main attributes:<br /> - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.<br /> - OVS_PACKET_ATTR_PACKET - Binary packet content.<br /> - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.<br /> <br /> OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure<br /> with the metadata like conntrack state, input port, recirculation id,<br /> etc. Then the packet itself gets parsed to populate the rest of the<br /> keys from the packet headers.<br /> <br /> Whenever the packet parsing code starts parsing the ICMPv6 header, it<br /> first zeroes out fields in the key corresponding to Neighbor Discovery<br /> information even if it is not an ND packet.<br /> <br /> It is an &amp;#39;ipv6.nd&amp;#39; field. However, the &amp;#39;ipv6&amp;#39; is a union that shares<br /> the space between &amp;#39;nd&amp;#39; and &amp;#39;ct_orig&amp;#39; that holds the original tuple<br /> conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.<br /> <br /> ND packets should not normally have conntrack state, so it&amp;#39;s fine to<br /> share the space, but normal ICMPv6 Echo packets or maybe other types of<br /> ICMPv6 can have the state attached and it should not be overwritten.<br /> <br /> The issue results in all but the last 4 bytes of the destination<br /> address being wiped from the original conntrack tuple leading to<br /> incorrect packet matching and potentially executing wrong actions<br /> in case this packet recirculates within the datapath or goes back<br /> to userspace.<br /> <br /> ND fields should not be accessed in non-ND packets, so not clearing<br /> them should be fine. Executing memset() only for actual ND packets to<br /> avoid the issue.<br /> <br /> Initializing the whole thing before parsing is needed because ND packet<br /> may not contain all the options.<br /> <br /> The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn&amp;#39;t<br /> affect packets entering OVS datapath from network interfaces, because<br /> in this case CT metadata is populated from skb after the packet is<br /> already parsed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq<br /> <br /> Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called<br /> with hwq_attr-&gt;aux_depth != 0 and hwq_attr-&gt;aux_stride == 0.<br /> In that case, "roundup_pow_of_two(hwq_attr-&gt;aux_stride)" gets called.<br /> roundup_pow_of_two is documented as undefined for 0.<br /> <br /> Fix it in the one caller that had this combination.<br /> <br /> The undefined behavior was detected by UBSAN:<br /> UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13<br /> shift exponent 64 is too large for 64-bit type &amp;#39;long unsigned int&amp;#39;<br /> CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4<br /> Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5d/0x80<br /> ubsan_epilogue+0x5/0x30<br /> __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec<br /> __roundup_pow_of_two+0x25/0x35 [bnxt_re]<br /> bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]<br /> bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]<br /> bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __kmalloc+0x1b6/0x4f0<br /> ? create_qp.part.0+0x128/0x1c0 [ib_core]<br /> ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]<br /> create_qp.part.0+0x128/0x1c0 [ib_core]<br /> ib_create_qp_kernel+0x50/0xd0 [ib_core]<br /> create_mad_qp+0x8e/0xe0 [ib_core]<br /> ? __pfx_qp_event_handler+0x10/0x10 [ib_core]<br /> ib_mad_init_device+0x2be/0x680 [ib_core]<br /> add_client_context+0x10d/0x1a0 [ib_core]<br /> enable_device_and_get+0xe0/0x1d0 [ib_core]<br /> ib_register_device+0x53c/0x630 [ib_core]<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> bnxt_re_probe+0xbd8/0xe50 [bnxt_re]<br /> ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]<br /> auxiliary_bus_probe+0x49/0x80<br /> ? driver_sysfs_add+0x57/0xc0<br /> really_probe+0xde/0x340<br /> ? pm_runtime_barrier+0x54/0x90<br /> ? __pfx___driver_attach+0x10/0x10<br /> __driver_probe_device+0x78/0x110<br /> driver_probe_device+0x1f/0xa0<br /> __driver_attach+0xba/0x1c0<br /> bus_for_each_dev+0x8f/0xe0<br /> bus_add_driver+0x146/0x220<br /> driver_register+0x72/0xd0<br /> __auxiliary_driver_register+0x6e/0xd0<br /> ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]<br /> bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]<br /> ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]<br /> do_one_initcall+0x5b/0x310<br /> do_init_module+0x90/0x250<br /> init_module_from_file+0x86/0xc0<br /> idempotent_init_module+0x121/0x2b0<br /> __x64_sys_finit_module+0x5e/0xb0<br /> do_syscall_64+0x82/0x160<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? syscall_exit_to_user_mode_prepare+0x149/0x170<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? syscall_exit_to_user_mode+0x75/0x230<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? do_syscall_64+0x8e/0x160<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __count_memcg_events+0x69/0x100<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? count_memcg_events.constprop.0+0x1a/0x30<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? handle_mm_fault+0x1f0/0x300<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? do_user_addr_fault+0x34e/0x640<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f4e5132821d<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139<br /> RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d<br /> RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b<br /> RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0<br /> R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d<br /> R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60<br /> <br /> ---[ end trace ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/test_hmm.c: handle src_pfns and dst_pfns allocation failure<br /> <br /> The kcalloc() in dmirror_device_evict_chunk() will return null if the<br /> physical memory has run out. As a result, if src_pfns or dst_pfns is<br /> dereferenced, the null pointer dereference bug will happen.<br /> <br /> Moreover, the device is going away. If the kcalloc() fails, the pages<br /> mapping a chunk could not be evicted. So add a __GFP_NOFAIL flag in<br /> kcalloc().<br /> <br /> Finally, as there is no need to have physically contiguous memory, Switch<br /> kcalloc() to kvcalloc() in order to avoid failing allocations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: vc4: Fix possible null pointer dereference<br /> <br /> In vc4_hdmi_audio_init() of_get_address() may return<br /> NULL which is later dereferenced. Fix this bug by adding NULL check.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries<br /> <br /> The allocation failure of mycs-&gt;yuv_scaler_binary in load_video_binaries()<br /> is followed with a dereference of mycs-&gt;yuv_scaler_binary after the<br /> following call chain:<br /> <br /> sh_css_pipe_load_binaries()<br /> |-&gt; load_video_binaries(mycs-&gt;yuv_scaler_binary == NULL)<br /> |<br /> |-&gt; sh_css_pipe_unload_binaries()<br /> |-&gt; unload_video_binaries()<br /> <br /> In unload_video_binaries(), it calls to ia_css_binary_unload with argument<br /> &amp;pipe-&gt;pipe_settings.video.yuv_scaler_binary[i], which refers to the<br /> same memory slot as mycs-&gt;yuv_scaler_binary. Thus, a null-pointer<br /> dereference is triggered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: xmit: make sure we have at least eth header len bytes<br /> <br /> syzbot triggered an uninit value[1] error in bridge device&amp;#39;s xmit path<br /> by sending a short (less than ETH_HLEN bytes) skb. To fix it check if<br /> we can actually pull that amount instead of assuming.<br /> <br /> Tested with dropwatch:<br /> drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)<br /> origin: software<br /> timestamp: Mon May 13 11:31:53 2024 778214037 nsec<br /> protocol: 0x88a8<br /> length: 2<br /> original length: 2<br /> drop reason: PKT_TOO_SMALL<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65<br /> br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65<br /> __netdev_start_xmit include/linux/netdevice.h:4903 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4917 [inline]<br /> xmit_one net/core/dev.c:3531 [inline]<br /> dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547<br /> __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341<br /> dev_queue_xmit include/linux/netdevice.h:3091 [inline]<br /> __bpf_tx_skb net/core/filter.c:2136 [inline]<br /> __bpf_redirect_common net/core/filter.c:2180 [inline]<br /> __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187<br /> ____bpf_clone_redirect net/core/filter.c:2460 [inline]<br /> bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432<br /> ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997<br /> __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238<br /> bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]<br /> __bpf_prog_run include/linux/filter.h:657 [inline]<br /> bpf_prog_run include/linux/filter.h:664 [inline]<br /> bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425<br /> bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058<br /> bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269<br /> __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678<br /> __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]<br /> __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765<br /> x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw<br /> <br /> When running blktests nvme/rdma, the following kmemleak issue will appear.<br /> <br /> kmemleak: Kernel memory leak detector initialized (mempool available:36041)<br /> kmemleak: Automatic memory scanning thread started<br /> kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> kmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> kmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> <br /> unreferenced object 0xffff88855da53400 (size 192):<br /> comm "rdma", pid 10630, jiffies 4296575922<br /> hex dump (first 32 bytes):<br /> 37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00 7...............<br /> 10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff .4.].....4.]....<br /> backtrace (crc 47f66721):<br /> [] kmalloc_trace+0x30d/0x3b0<br /> [] alloc_gid_entry+0x47/0x380 [ib_core]<br /> [] add_modify_gid+0x166/0x930 [ib_core]<br /> [] ib_cache_update.part.0+0x6d8/0x910 [ib_core]<br /> [] ib_cache_setup_one+0x24a/0x350 [ib_core]<br /> [] ib_register_device+0x9e/0x3a0 [ib_core]<br /> [] 0xffffffffc2a3d389<br /> [] nldev_newlink+0x2b8/0x520 [ib_core]<br /> [] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core]<br /> []<br /> rdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core]<br /> [] netlink_unicast+0x445/0x710<br /> [] netlink_sendmsg+0x761/0xc40<br /> [] __sys_sendto+0x3a9/0x420<br /> [] __x64_sys_sendto+0xdc/0x1b0<br /> [] do_syscall_64+0x93/0x180<br /> [] entry_SYSCALL_64_after_hwframe+0x71/0x79<br /> <br /> The root cause: rdma_put_gid_attr is not called when sgid_attr is set<br /> to ERR_PTR(-ENODEV).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: module: add buffer overflow check in of_modalias()<br /> <br /> In of_modalias(), if the buffer happens to be too small even for the 1st<br /> snprintf() call, the len parameter will become negative and str parameter<br /> (if not NULL initially) will point beyond the buffer&amp;#39;s end. Add the buffer<br /> overflow check after the 1st snprintf() call and fix such check after the<br /> strlen() call (accounting for the terminating NUL char).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mana_ib: boundary check before installing cq callbacks<br /> <br /> Add a boundary check inside mana_ib_install_cq_cb to prevent index overflow.