Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fec: remove .ndo_poll_controller to avoid deadlocks<br /> <br /> There is a deadlock issue found in sungem driver, please refer to the<br /> commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid<br /> deadlocks"). The root cause of the issue is that netpoll is in atomic<br /> context and disable_irq() is called by .ndo_poll_controller interface<br /> of sungem driver, however, disable_irq() might sleep. After analyzing<br /> the implementation of fec_poll_controller(), the fec driver should have<br /> the same issue. Due to the fec driver uses NAPI for TX completions, the<br /> .ndo_poll_controller is unnecessary to be implemented in the fec driver,<br /> so fec_poll_controller() can be safely removed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Add 0 size check to mtk_drm_gem_obj<br /> <br /> Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object<br /> of 0 bytes. Currently, no such check exists and the kernel will panic if<br /> a userspace application attempts to allocate a 0x0 GBM buffer.<br /> <br /> Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and<br /> verifying that we now return EINVAL.

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: 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 /> 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 /> 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.

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/rxe: Fix seg fault in rxe_comp_queue_pkt<br /> <br /> In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the<br /> resp_pkts queue and then a decision is made whether to run the completer<br /> task inline or schedule it. Finally the skb is dereferenced to bump a &amp;#39;hw&amp;#39;<br /> performance counter. This is wrong because if the completer task is<br /> already running in a separate thread it may have already processed the skb<br /> and freed it which can cause a seg fault. This has been observed<br /> infrequently in testing at high scale.<br /> <br /> This patch fixes this by changing the order of enqueuing the packet until<br /> after the counter is accessed.

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