Vulnerabilities

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)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: imx: scu: use _safe list iterator to avoid a use after free<br /> <br /> This loop is freeing "clk" so it needs to use list_for_each_entry_safe().<br /> Otherwise it dereferences a freed variable to get the next item on the<br /> loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: rs9: Fix suspend/resume<br /> <br /> Disabling the cache in commit 2ff4ba9e3702 ("clk: rs9: Fix I2C accessors")<br /> without removing cache synchronization in resume path results in a<br /> kernel panic as map-&gt;cache_ops is unset, due to REGCACHE_NONE.<br /> Enable flat cache again to support resume again. num_reg_defaults_raw<br /> is necessary to read the cache defaults from hardware. Some registers<br /> are strapped in hardware and cannot be provided in software.