Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference<br /> <br /> In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is<br /> assigned to mhdp_state-&gt;current_mode, and there is a dereference of it in<br /> drm_mode_set_name(), which will lead to a NULL pointer dereference on<br /> failure of drm_mode_duplicate().<br /> <br /> Fix this bug add a check of mhdp_state-&gt;current_mode.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: kirkwood: Fix potential NULL dereference<br /> <br /> In kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL if<br /> CONFIG_PLAT_ORION macro is not defined.<br /> 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 /> ASoC: mediatek: Assign dummy when codec not specified for a DAI link<br /> <br /> MediaTek sound card drivers are checking whether a DAI link is present<br /> and used on a board to assign the correct parameters and this is done<br /> by checking the codec DAI names at probe time.<br /> <br /> If no real codec is present, assign the dummy codec to the DAI link<br /> to avoid NULL pointer during string comparison.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ax25: Fix reference count leak issue of net_device<br /> <br /> There is a reference count leak issue of the object "net_device" in<br /> ax25_dev_device_down(). When the ax25 device is shutting down, the<br /> ax25_dev_device_down() drops the reference count of net_device one<br /> or zero times depending on if we goto unlock_put or not, which will<br /> cause memory leak.<br /> <br /> In order to solve the above issue, decrease the reference count of<br /> net_device after dev-&gt;ax25_ptr is set to null.

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/mlx5: Reload only IB representors upon lag disable/enable<br /> <br /> On lag disable, the bond IB device along with all of its<br /> representors are destroyed, and then the slaves&amp;#39; representors get reloaded.<br /> <br /> In case the slave IB representor load fails, the eswitch error flow<br /> unloads all representors, including ethernet representors, where the<br /> netdevs get detached and removed from lag bond. Such flow is inaccurate<br /> as the lag driver is not responsible for loading/unloading ethernet<br /> representors. Furthermore, the flow described above begins by holding<br /> lag lock to prevent bond changes during disable flow. However, when<br /> reaching the ethernet representors detachment from lag, the lag lock is<br /> required again, triggering the following deadlock:<br /> <br /> Call trace:<br /> __switch_to+0xf4/0x148<br /> __schedule+0x2c8/0x7d0<br /> schedule+0x50/0xe0<br /> schedule_preempt_disabled+0x18/0x28<br /> __mutex_lock.isra.13+0x2b8/0x570<br /> __mutex_lock_slowpath+0x1c/0x28<br /> mutex_lock+0x4c/0x68<br /> mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core]<br /> mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core]<br /> mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core]<br /> mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core]<br /> mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core]<br /> mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core]<br /> mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core]<br /> mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core]<br /> mlx5_disable_lag+0x130/0x138 [mlx5_core]<br /> mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev-&gt;lock<br /> mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core]<br /> devlink_nl_cmd_eswitch_set_doit+0xdc/0x180<br /> genl_family_rcv_msg_doit.isra.17+0xe8/0x138<br /> genl_rcv_msg+0xe4/0x220<br /> netlink_rcv_skb+0x44/0x108<br /> genl_rcv+0x40/0x58<br /> netlink_unicast+0x198/0x268<br /> netlink_sendmsg+0x1d4/0x418<br /> sock_sendmsg+0x54/0x60<br /> __sys_sendto+0xf4/0x120<br /> __arm64_sys_sendto+0x30/0x40<br /> el0_svc_common+0x8c/0x120<br /> do_el0_svc+0x30/0xa0<br /> el0_svc+0x20/0x30<br /> el0_sync_handler+0x90/0xb8<br /> el0_sync+0x160/0x180<br /> <br /> Thus, upon lag enable/disable, load and unload only the IB representors<br /> of the slaves preventing the deadlock mentioned above.<br /> <br /> While at it, refactor the mlx5_esw_offloads_rep_load() function to have<br /> a static helper method for its internal logic, in symmetry with the<br /> representor unload design.

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