Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ar5523: enable proper endpoint verification<br /> <br /> Syzkaller reports [1] hitting a warning about an endpoint in use<br /> not having an expected type to it.<br /> <br /> Fix the issue by checking for the existence of all proper<br /> endpoints with their according types intact.<br /> <br /> Sadly, this patch has not been tested on real hardware.<br /> <br /> [1] Syzkaller report:<br /> ------------[ cut here ]------------<br /> usb 1-1: BOGUS urb xfer, pipe 3 != type 1<br /> WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504<br /> ...<br /> Call Trace:<br /> <br /> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275<br /> ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline]<br /> ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline]<br /> ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655<br /> usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396<br /> call_driver_probe drivers/base/dd.c:560 [inline]<br /> really_probe+0x249/0xb90 drivers/base/dd.c:639<br /> __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778<br /> driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808<br /> __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936<br /> bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427<br /> __device_attach+0x1e4/0x530 drivers/base/dd.c:1008<br /> bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487<br /> device_add+0xbd9/0x1e90 drivers/base/core.c:3517<br /> usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170<br /> usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238<br /> usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293<br /> call_driver_probe drivers/base/dd.c:560 [inline]<br /> really_probe+0x249/0xb90 drivers/base/dd.c:639<br /> __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778<br /> driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808<br /> __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936<br /> bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427<br /> __device_attach+0x1e4/0x530 drivers/base/dd.c:1008<br /> bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487<br /> device_add+0xbd9/0x1e90 drivers/base/core.c:3517<br /> usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573<br /> hub_port_connect drivers/usb/core/hub.c:5353 [inline]<br /> hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]<br /> port_event drivers/usb/core/hub.c:5653 [inline]<br /> hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735<br /> process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289<br /> worker_thread+0x669/0x1090 kernel/workqueue.c:2436<br /> kthread+0x2e8/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix verifier assumptions about socket-&gt;sk<br /> <br /> The verifier assumes that &amp;#39;sk&amp;#39; field in &amp;#39;struct socket&amp;#39; is valid<br /> and non-NULL when &amp;#39;socket&amp;#39; pointer itself is trusted and non-NULL.<br /> That may not be the case when socket was just created and<br /> passed to LSM socket_accept hook.<br /> Fix this verifier assumption and adjust tests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: carl9170: add a proper sanity check for endpoints<br /> <br /> Syzkaller reports [1] hitting a warning which is caused by presence<br /> of a wrong endpoint type at the URB sumbitting stage. While there<br /> was a check for a specific 4th endpoint, since it can switch types<br /> between bulk and interrupt, other endpoints are trusted implicitly.<br /> Similar warning is triggered in a couple of other syzbot issues [2].<br /> <br /> Fix the issue by doing a comprehensive check of all endpoints<br /> taking into account difference between high- and full-speed<br /> configuration.<br /> <br /> [1] Syzkaller report:<br /> ...<br /> WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504<br /> ...<br /> Call Trace:<br /> <br /> carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504<br /> carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]<br /> carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]<br /> carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028<br /> request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107<br /> process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289<br /> worker_thread+0x669/0x1090 kernel/workqueue.c:2436<br /> kthread+0x2e8/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308<br /> <br /> <br /> [2] Related syzkaller crashes:

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE<br /> <br /> bpf_prog_attach uses attach_type_to_prog_type to enforce proper<br /> attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses<br /> bpf_prog_get and relies on bpf_prog_attach_check_attach_type<br /> to properly verify prog_type attach_type association.<br /> <br /> Add missing attach_type enforcement for the link_create case.<br /> Otherwise, it&amp;#39;s currently possible to attach cgroup_skb prog<br /> types to other cgroup hooks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group<br /> <br /> The perf tool allows users to create event groups through following<br /> cmd [1], but the driver does not check whether the array index is out<br /> of bounds when writing data to the event_group array. If the number of<br /> events in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, the<br /> memory write overflow of event_group array occurs.<br /> <br /> Add array index check to fix the possible array out of bounds violation,<br /> and return directly when write new events are written to array bounds.<br /> <br /> There are 9 different events in an event_group.<br /> [1] perf stat -e &amp;#39;{pmu/event1/, ... ,pmu/event9/}

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