Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, cpumap: Make sure kthread is running before map update returns<br /> <br /> The following warning was reported when running stress-mode enabled<br /> xdp_redirect_cpu with some RT threads:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135<br /> CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Workqueue: events cpu_map_kthread_stop<br /> RIP: 0010:put_cpu_map_entry+0xda/0x220<br /> ......<br /> Call Trace:<br /> <br /> ? show_regs+0x65/0x70<br /> ? __warn+0xa5/0x240<br /> ......<br /> ? put_cpu_map_entry+0xda/0x220<br /> cpu_map_kthread_stop+0x41/0x60<br /> process_one_work+0x6b0/0xb80<br /> worker_thread+0x96/0x720<br /> kthread+0x1a5/0x1f0<br /> ret_from_fork+0x3a/0x70<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memory<br /> leak in cpu_map_update_elem"). The kthread is stopped prematurely by<br /> kthread_stop() in cpu_map_kthread_stop(), and kthread() doesn&amp;#39;t call<br /> cpu_map_kthread_run() at all but XDP program has already queued some<br /> frames or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks<br /> the ptr_ring, it will find it was not emptied and report a warning.<br /> <br /> An alternative fix is to use __cpu_map_ring_cleanup() to drop these<br /> pending frames or skbs when kthread_stop() returns -EINTR, but it may<br /> confuse the user, because these frames or skbs have been handled<br /> correctly by XDP program. So instead of dropping these frames or skbs,<br /> just make sure the per-cpu kthread is running before<br /> __cpu_map_entry_alloc() returns.<br /> <br /> After apply the fix, the error handle for kthread_stop() will be<br /> unnecessary because it will always return 0, so just remove it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume()<br /> <br /> Syzbot reported a bug as following:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230<br /> qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230<br /> qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519<br /> qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108<br /> call_write_iter include/linux/fs.h:2189 [inline]<br /> aio_write+0x63a/0x950 fs/aio.c:1600<br /> io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019<br /> __do_sys_io_submit fs/aio.c:2078 [inline]<br /> __se_sys_io_submit+0x293/0x770 fs/aio.c:2048<br /> __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:766 [inline]<br /> slab_alloc_node mm/slub.c:3452 [inline]<br /> __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491<br /> __do_kmalloc_node mm/slab_common.c:967 [inline]<br /> __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988<br /> kmalloc_reserve net/core/skbuff.c:492 [inline]<br /> __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565<br /> __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630<br /> qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446<br /> qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108<br /> call_write_iter include/linux/fs.h:2189 [inline]<br /> aio_write+0x63a/0x950 fs/aio.c:1600<br /> io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019<br /> __do_sys_io_submit fs/aio.c:2078 [inline]<br /> __se_sys_io_submit+0x293/0x770 fs/aio.c:2048<br /> __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> It is because that skb-&gt;len requires at least sizeof(struct qrtr_ctrl_pkt)<br /> in qrtr_tx_resume(). And skb-&gt;len equals to size in qrtr_endpoint_post().<br /> But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb-&gt;type<br /> equals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbot<br /> scenario. This triggers the uninit variable access bug.<br /> <br /> Add size check when qrtr_cb-&gt;type equals to QRTR_TYPE_RESUME_TX in<br /> qrtr_endpoint_post() to fix the bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: mvebu: fix irq domain leak<br /> <br /> Uwe Kleine-König pointed out we still have one resource leak in the mvebu<br /> driver triggered on driver detach. Let&amp;#39;s address it with a custom devm<br /> action.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: Gadget: core: Help prevent panic during UVC unconfigure<br /> <br /> Avichal Rakesh reported a kernel panic that occurred when the UVC<br /> gadget driver was removed from a gadget&amp;#39;s configuration. The panic<br /> involves a somewhat complicated interaction between the kernel driver<br /> and a userspace component (as described in the Link tag below), but<br /> the analysis did make one thing clear: The Gadget core should<br /> accomodate gadget drivers calling usb_gadget_deactivate() as part of<br /> their unbind procedure.<br /> <br /> Currently this doesn&amp;#39;t work. gadget_unbind_driver() calls<br /> driver-&gt;unbind() while holding the udc-&gt;connect_lock mutex, and<br /> usb_gadget_deactivate() attempts to acquire that mutex, which will<br /> result in a deadlock.<br /> <br /> The simple fix is for gadget_unbind_driver() to release the mutex when<br /> invoking the -&gt;unbind() callback. There is no particular reason for<br /> it to be holding the mutex at that time, and the mutex isn&amp;#39;t held<br /> while the -&gt;bind() callback is invoked. So we&amp;#39;ll drop the mutex<br /> before performing the unbind callback and reacquire it afterward.<br /> <br /> We&amp;#39;ll also add a couple of comments to usb_gadget_activate() and<br /> usb_gadget_deactivate(). Because they run in process context they<br /> must not be called from a gadget driver&amp;#39;s -&gt;disconnect() callback,<br /> which (according to the kerneldoc for struct usb_gadget_driver in<br /> include/linux/usb/gadget.h) may run in interrupt context. This may<br /> help prevent similar bugs from arising in the future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Check for NOT_READY flag state after locking<br /> <br /> Currently the check for NOT_READY flag is performed before obtaining the<br /> necessary lock. This opens a possibility for race condition when the flow<br /> is concurrently removed from unready_flows list by the workqueue task,<br /> which causes a double-removal from the list and a crash[0]. Fix the issue<br /> by moving the flag check inside the section protected by<br /> uplink_priv-&gt;unready_flows_lock mutex.<br /> <br /> [0]:<br /> [44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP<br /> [44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1<br /> [44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]<br /> [44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06<br /> [44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246<br /> [44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00<br /> [44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0<br /> [44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001<br /> [44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000<br /> [44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000<br /> [44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000<br /> [44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0<br /> [44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [44376.406339] Call Trace:<br /> [44376.406651] <br /> [44376.406939] ? die_addr+0x33/0x90<br /> [44376.407311] ? exc_general_protection+0x192/0x390<br /> [44376.407795] ? asm_exc_general_protection+0x22/0x30<br /> [44376.408292] ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]<br /> [44376.408876] __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core]<br /> [44376.409482] mlx5e_tc_del_flow+0x42/0x210 [mlx5_core]<br /> [44376.410055] mlx5e_flow_put+0x25/0x50 [mlx5_core]<br /> [44376.410529] mlx5e_delete_flower+0x24b/0x350 [mlx5_core]<br /> [44376.411043] tc_setup_cb_reoffload+0x22/0x80<br /> [44376.411462] fl_reoffload+0x261/0x2f0 [cls_flower]<br /> [44376.411907] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]<br /> [44376.412481] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]<br /> [44376.413044] tcf_block_playback_offloads+0x76/0x170<br /> [44376.413497] tcf_block_unbind+0x7b/0xd0<br /> [44376.413881] tcf_block_setup+0x17d/0x1c0<br /> [44376.414269] tcf_block_offload_cmd.isra.0+0xf1/0x130<br /> [44376.414725] tcf_block_offload_unbind+0x43/0x70<br /> [44376.415153] __tcf_block_put+0x82/0x150<br /> [44376.415532] ingress_destroy+0x22/0x30 [sch_ingress]<br /> [44376.415986] qdisc_destroy+0x3b/0xd0<br /> [44376.416343] qdisc_graft+0x4d0/0x620<br /> [44376.416706] tc_get_qdisc+0x1c9/0x3b0<br /> [44376.417074] rtnetlink_rcv_msg+0x29c/0x390<br /> [44376.419978] ? rep_movs_alternative+0x3a/0xa0<br /> [44376.420399] ? rtnl_calcit.isra.0+0x120/0x120<br /> [44376.420813] netlink_rcv_skb+0x54/0x100<br /> [44376.421192] netlink_unicast+0x1f6/0x2c0<br /> [44376.421573] netlink_sendmsg+0x232/0x4a0<br /> [44376.421980] sock_sendmsg+0x38/0x60<br /> [44376.422328] ____sys_sendmsg+0x1d0/0x1e0<br /> [44376.422709] ? copy_msghdr_from_user+0x6d/0xa0<br /> [44376.423127] ___sys_sendmsg+0x80/0xc0<br /> [44376.423495] ? ___sys_recvmsg+0x8b/0xc0<br /> [44376.423869] __sys_sendmsg+0x51/0x90<br /> [44376.424226] do_syscall_64+0x3d/0x90<br /> [44376.424587] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [44376.425046] RIP: 0033:0x7f045134f887<br /> [44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds<br /> <br /> Fix a stack-out-of-bounds read in brcmfmac that occurs<br /> when &amp;#39;buf&amp;#39; that is not null-terminated is passed as an argument of<br /> strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with<br /> a CLM version string by memcpy() in brcmf_fil_iovar_data_get().<br /> Ensure buf is null-terminated.<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> [ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br /> [ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22<br /> [ 33.021554][ T1896] ==================================================================<br /> [ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110<br /> [ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896<br /> [ 33.023852][ T1896]<br /> [ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132<br /> [ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014<br /> [ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event<br /> [ 33.026581][ T1896] Call Trace:<br /> [ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d<br /> [ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334<br /> [ 33.028037][ T1896] ? strreplace+0xf2/0x110<br /> [ 33.028403][ T1896] ? strreplace+0xf2/0x110<br /> [ 33.028807][ T1896] kasan_report.cold+0x83/0xdf<br /> [ 33.029283][ T1896] ? strreplace+0xf2/0x110<br /> [ 33.029666][ T1896] strreplace+0xf2/0x110<br /> [ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40<br /> [ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100<br /> [ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0<br /> [ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0<br /> [ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0<br /> [ 33.032091][ T1896] ? find_held_lock+0x2d/0x110<br /> [ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260<br /> [ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0<br /> [ 33.033582][ T1896] brcmf_attach+0x246/0xd40<br /> [ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50<br /> [ 33.034383][ T1896] ? kmemdup+0x30/0x40<br /> [ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690<br /> [ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470<br /> [ 33.035833][ T1896] usb_probe_interface+0x25f/0x710<br /> [ 33.036315][ T1896] really_probe+0x1be/0xa90<br /> [ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460<br /> [ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0<br /> [ 33.037383][ T1896] driver_probe_device+0x49/0x120<br /> [ 33.037790][ T1896] __device_attach_driver+0x18a/0x250<br /> [ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120<br /> [ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0<br /> [ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20<br /> [ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0<br /> [ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120<br /> [ 33.042330][ T1896] __device_attach+0x207/0x330<br /> [ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0<br /> [ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0<br /> [ 33.043515][ T1896] bus_probe_device+0x1a2/0x260<br /> [ 33.043914][ T1896] device_add+0xa61/0x1ce0<br /> [ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660<br /> [ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550<br /> [ 33.045531][ T1896] usb_set_configuration+0x984/0x1770<br /> [ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230<br /> [ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90<br /> [ 33.046931][ T1896] usb_probe_device+0x9c/0x220<br /> [ 33.047434][ T1896] really_probe+0x1be/0xa90<br /> [ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460<br /> [ 33.048134][ T1896] driver_probe_device+0x49/0x120<br /> [ 33.048516][ T1896] __device_attach_driver+0x18a/0x250<br /> [ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_rbtree: fix null deref on element insertion<br /> <br /> There is no guarantee that rb_prev() will not return NULL in nft_rbtree_gc_elem():<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]<br /> nft_add_set_elem+0x14b0/0x2990<br /> nf_tables_newsetelem+0x528/0xb30<br /> <br /> Furthermore, there is a possible use-after-free while iterating,<br /> &amp;#39;node&amp;#39; can be free&amp;#39;d so we need to cache the next value to use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: qup: Don&amp;#39;t skip cleanup in remove&amp;#39;s error path<br /> <br /> Returning early in a platform driver&amp;#39;s remove callback is wrong. In this<br /> case the dma resources are not released in the error path. this is never<br /> retried later and so this is a permanent leak. To fix this, only skip<br /> hardware disabling if waking the device fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: don&amp;#39;t leak memory if dev_set_name() fails<br /> <br /> When dev_set_name() fails, zcdn_create() doesn&amp;#39;t free the newly<br /> allocated resources. Do it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext2: Check block size validity during mount<br /> <br /> Check that log of block size stored in the superblock has sensible<br /> value. Otherwise the shift computing the block size can overflow leading<br /> to undefined behavior.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: fix integer overflow in nl80211_parse_mbssid_elems()<br /> <br /> nl80211_parse_mbssid_elems() uses a u8 variable num_elems to count the<br /> number of MBSSID elements in the nested netlink attribute attrs, which can<br /> lead to an integer overflow if a user of the nl80211 interface specifies<br /> 256 or more elements in the corresponding attribute in userspace. The<br /> integer overflow can lead to a heap buffer overflow as num_elems determines<br /> the size of the trailing array in elems, and this array is thereafter<br /> written to for each element in attrs.<br /> <br /> Note that this vulnerability only affects devices with the<br /> wiphy-&gt;mbssid_max_interfaces member set for the wireless physical device<br /> struct in the device driver, and can only be triggered by a process with<br /> CAP_NET_ADMIN capabilities.<br /> <br /> Fix this by checking for a maximum of 255 elements in attrs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Make intel_get_crtc_new_encoder() less oopsy<br /> <br /> The point of the WARN was to print something, not oops<br /> straight up. Currently that is precisely what happens<br /> if we can&amp;#39;t find the connector for the crtc in the atomic<br /> state. Get the dev pointer from the atomic state instead<br /> of the potentially NULL encoder to avoid that.<br /> <br /> (cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c)