Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imx-jpeg: Disable useless interrupt to avoid kernel panic<br /> <br /> There is a hardware bug that the interrupt STMBUF_HALF may be triggered<br /> after or when disable interrupt.<br /> It may led to unexpected kernel panic.<br /> And interrupt STMBUF_HALF and STMBUF_RTND have no other effect.<br /> So disable them and the unused interrupts.<br /> <br /> meanwhile clear the interrupt status when disable interrupt.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: ocxl: fix possible refcount leak in afu_ioctl()<br /> <br /> eventfd_ctx_put need to be called to put the refcount that gotten by<br /> eventfd_ctx_fdget when ocxl_irq_set_handler fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: core: fix resource leak in regulator_register()<br /> <br /> I got some resource leak reports while doing fault injection test:<br /> <br /> OF: ERROR: memory leak, expected refcount 1 instead of 100,<br /> of_node_get()/of_node_put() unbalanced - destroy cset entry:<br /> attach overlay node /i2c/pmic@64/regulators/buck1<br /> <br /> unreferenced object 0xffff88810deea000 (size 512):<br /> comm "490-i2c-rt5190a", pid 253, jiffies 4294859840 (age 5061.046s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........<br /> ff ff ff ff ff ff ff ff a0 1e 00 a1 ff ff ff ff ................<br /> backtrace:<br /> [] kmalloc_trace+0x21/0x110<br /> [] device_private_init+0x32/0xd0<br /> [] device_add+0xb2d/0x1030<br /> [] regulator_register+0xaf2/0x12a0<br /> [] devm_regulator_register+0x57/0xb0<br /> [] rt5190a_probe+0x52a/0x861 [rt5190a_regulator]<br /> <br /> unreferenced object 0xffff88810b617b80 (size 32):<br /> comm "490-i2c-rt5190a", pid 253, jiffies 4294859904 (age 5060.983s)<br /> hex dump (first 32 bytes):<br /> 72 65 67 75 6c 61 74 6f 72 2e 32 38 36 38 2d 53 regulator.2868-S<br /> 55 50 50 4c 59 00 ff ff 29 00 00 00 2b 00 00 00 UPPLY...)...+...<br /> backtrace:<br /> [] __kmalloc_node_track_caller+0x44/0x1b0<br /> [] kstrdup+0x3a/0x70<br /> [] create_regulator+0xc0/0x4e0<br /> [] regulator_resolve_supply+0x2d4/0x440<br /> [] regulator_register+0x10b3/0x12a0<br /> [] devm_regulator_register+0x57/0xb0<br /> [] rt5190a_probe+0x52a/0x861 [rt5190a_regulator]<br /> <br /> After calling regulator_resolve_supply(), the &amp;#39;rdev-&gt;supply&amp;#39; is set<br /> by set_supply(), after this set, in the error path, the resources<br /> need be released, so call regulator_put() to avoid the leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vidtv: Fix use-after-free in vidtv_bridge_dvb_init()<br /> <br /> KASAN reports a use-after-free:<br /> BUG: KASAN: use-after-free in dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]<br /> Call Trace:<br /> ...<br /> dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]<br /> vidtv_bridge_probe+0x7bf/0xa40 [dvb_vidtv_bridge]<br /> platform_probe+0xb6/0x170<br /> ...<br /> Allocated by task 1238:<br /> ...<br /> dvb_register_device+0x1a7/0xa70 [dvb_core]<br /> dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]<br /> vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]<br /> ...<br /> Freed by task 1238:<br /> dvb_register_device+0x6d2/0xa70 [dvb_core]<br /> dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]<br /> vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]<br /> ...<br /> <br /> It is because the error handling in vidtv_bridge_dvb_init() is wrong.<br /> <br /> First, vidtv_bridge_dmx(dev)_init() will clean themselves when fail, but<br /> goto fail_dmx(_dev): calls release functions again, which causes<br /> use-after-free.<br /> <br /> Also, in fail_fe, fail_tuner_probe and fail_demod_probe, j = i will cause<br /> out-of-bound when i finished its loop (i == NUM_FE). And the loop<br /> releasing is wrong, although now NUM_FE is 1 so it won&amp;#39;t cause problem.<br /> <br /> Fix this by correctly releasing everything.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix possible use-after-free in async command interface<br /> <br /> mlx5_cmd_cleanup_async_ctx should return only after all its callback<br /> handlers were completed. Before this patch, the below race between<br /> mlx5_cmd_cleanup_async_ctx and mlx5_cmd_exec_cb_handler was possible and<br /> lead to a use-after-free:<br /> <br /> 1. mlx5_cmd_cleanup_async_ctx is called while num_inflight is 2 (i.e.<br /> elevated by 1, a single inflight callback).<br /> 2. mlx5_cmd_cleanup_async_ctx decreases num_inflight to 1.<br /> 3. mlx5_cmd_exec_cb_handler is called, decreases num_inflight to 0 and<br /> is about to call wake_up().<br /> 4. mlx5_cmd_cleanup_async_ctx calls wait_event, which returns<br /> immediately as the condition (num_inflight == 0) holds.<br /> 5. mlx5_cmd_cleanup_async_ctx returns.<br /> 6. The caller of mlx5_cmd_cleanup_async_ctx frees the mlx5_async_ctx<br /> object.<br /> 7. mlx5_cmd_exec_cb_handler goes on and calls wake_up() on the freed<br /> object.<br /> <br /> Fix it by syncing using a completion object. Mark it completed when<br /> num_inflight reaches 0.<br /> <br /> Trace:<br /> <br /> BUG: KASAN: use-after-free in do_raw_spin_lock+0x23d/0x270<br /> Read of size 4 at addr ffff888139cd12f4 by task swapper/5/0<br /> <br /> CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.0.0-rc3_for_upstream_debug_2022_08_30_13_10 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x57/0x7d<br /> print_report.cold+0x2d5/0x684<br /> ? do_raw_spin_lock+0x23d/0x270<br /> kasan_report+0xb1/0x1a0<br /> ? do_raw_spin_lock+0x23d/0x270<br /> do_raw_spin_lock+0x23d/0x270<br /> ? rwlock_bug.part.0+0x90/0x90<br /> ? __delete_object+0xb8/0x100<br /> ? lock_downgrade+0x6e0/0x6e0<br /> _raw_spin_lock_irqsave+0x43/0x60<br /> ? __wake_up_common_lock+0xb9/0x140<br /> __wake_up_common_lock+0xb9/0x140<br /> ? __wake_up_common+0x650/0x650<br /> ? destroy_tis_callback+0x53/0x70 [mlx5_core]<br /> ? kasan_set_track+0x21/0x30<br /> ? destroy_tis_callback+0x53/0x70 [mlx5_core]<br /> ? kfree+0x1ba/0x520<br /> ? do_raw_spin_unlock+0x54/0x220<br /> mlx5_cmd_exec_cb_handler+0x136/0x1a0 [mlx5_core]<br /> ? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core]<br /> ? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core]<br /> mlx5_cmd_comp_handler+0x65a/0x12b0 [mlx5_core]<br /> ? dump_command+0xcc0/0xcc0 [mlx5_core]<br /> ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> ? cmd_comp_notifier+0x7e/0xb0 [mlx5_core]<br /> cmd_comp_notifier+0x7e/0xb0 [mlx5_core]<br /> atomic_notifier_call_chain+0xd7/0x1d0<br /> mlx5_eq_async_int+0x3ce/0xa20 [mlx5_core]<br /> atomic_notifier_call_chain+0xd7/0x1d0<br /> ? irq_release+0x140/0x140 [mlx5_core]<br /> irq_int_handler+0x19/0x30 [mlx5_core]<br /> __handle_irq_event_percpu+0x1f2/0x620<br /> handle_irq_event+0xb2/0x1d0<br /> handle_edge_irq+0x21e/0xb00<br /> __common_interrupt+0x79/0x1a0<br /> common_interrupt+0x78/0xa0<br /> <br /> <br /> asm_common_interrupt+0x22/0x40<br /> RIP: 0010:default_idle+0x42/0x60<br /> Code: c1 83 e0 07 48 c1 e9 03 83 c0 03 0f b6 14 11 38 d0 7c 04 84 d2 75 14 8b 05 eb 47 22 02 85 c0 7e 07 0f 00 2d e0 9f 48 00 fb f4 48 c7 c7 80 08 7f 85 e8 d1 d3 3e fe eb de 66 66 2e 0f 1f 84 00<br /> RSP: 0018:ffff888100dbfdf0 EFLAGS: 00000242<br /> RAX: 0000000000000001 RBX: ffffffff84ecbd48 RCX: 1ffffffff0afe110<br /> RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffff835cc9bc<br /> RBP: 0000000000000005 R08: 0000000000000001 R09: ffff88881dec4ac3<br /> R10: ffffed1103bd8958 R11: 0000017d0ca571c9 R12: 0000000000000005<br /> R13: ffffffff84f024e0 R14: 0000000000000000 R15: dffffc0000000000<br /> ? default_idle_call+0xcc/0x450<br /> default_idle_call+0xec/0x450<br /> do_idle+0x394/0x450<br /> ? arch_cpu_idle_exit+0x40/0x40<br /> ? do_idle+0x17/0x450<br /> cpu_startup_entry+0x19/0x20<br /> start_secondary+0x221/0x2b0<br /> ? set_cpu_sibling_map+0x2070/0x2070<br /> secondary_startup_64_no_verify+0xcd/0xdb<br /> <br /> <br /> Allocated by task 49502:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_kmalloc+0x81/0xa0<br /> kvmalloc_node+0x48/0xe0<br /> mlx5e_bulk_async_init+0x35/0x110 [mlx5_core]<br /> mlx5e_tls_priv_tx_list_cleanup+0x84/0x3e0 [mlx5_core]<br /> mlx5e_ktls_cleanup_tx+0x38f/0x760 [mlx5_core]<br /> mlx5e_cleanup_nic_tx+0xa7/0x100 [mlx5_core]<br /> mlx5e_detach_netdev+0x1c<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: efct: Fix possible memleak in efct_device_init()<br /> <br /> In efct_device_init(), when efct_scsi_reg_fc_transport() fails,<br /> efct_scsi_tgt_driver_exit() is not called to release memory for<br /> efct_scsi_tgt_driver_init() and causes memleak:<br /> <br /> unreferenced object 0xffff8881020ce000 (size 2048):<br /> comm "modprobe", pid 465, jiffies 4294928222 (age 55.872s)<br /> backtrace:<br /> [] kmalloc_trace+0x27/0x110<br /> [] target_register_template+0x4fd/0x7b0 [target_core_mod]<br /> [] efct_scsi_tgt_driver_init+0x18/0x50 [efct]<br /> [] 0xffffffffc0d90011<br /> [] do_one_initcall+0xd0/0x4e0<br /> [] do_init_module+0x1cc/0x6a0<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/lcs: Fix return type of lcs_start_xmit()<br /> <br /> With clang&amp;#39;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),<br /> indirect call targets are validated against the expected function<br /> pointer prototype to make sure the call target is valid to help mitigate<br /> ROP attacks. If they are not identical, there is a failure at run time,<br /> which manifests as either a kernel panic or thread getting killed. A<br /> proposed warning in clang aims to catch these at compile time, which<br /> reveals:<br /> <br /> drivers/s390/net/lcs.c:2090:21: error: incompatible function pointer types initializing &amp;#39;netdev_tx_t (*)(struct sk_buff *, struct net_device *)&amp;#39; (aka &amp;#39;enum netdev_tx (*)(struct sk_buff *, struct net_device *)&amp;#39;) with an expression of type &amp;#39;int (struct sk_buff *, struct net_device *)&amp;#39; [-Werror,-Wincompatible-function-pointer-types-strict]<br /> .ndo_start_xmit = lcs_start_xmit,<br /> ^~~~~~~~~~~~~~<br /> drivers/s390/net/lcs.c:2097:21: error: incompatible function pointer types initializing &amp;#39;netdev_tx_t (*)(struct sk_buff *, struct net_device *)&amp;#39; (aka &amp;#39;enum netdev_tx (*)(struct sk_buff *, struct net_device *)&amp;#39;) with an expression of type &amp;#39;int (struct sk_buff *, struct net_device *)&amp;#39; [-Werror,-Wincompatible-function-pointer-types-strict]<br /> .ndo_start_xmit = lcs_start_xmit,<br /> ^~~~~~~~~~~~~~<br /> <br /> -&gt;ndo_start_xmit() in &amp;#39;struct net_device_ops&amp;#39; expects a return type of<br /> &amp;#39;netdev_tx_t&amp;#39;, not &amp;#39;int&amp;#39;. Adjust the return type of lcs_start_xmit() to<br /> match the prototype&amp;#39;s to resolve the warning and potential CFI failure,<br /> should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: Fix resource leak in ksmbd_session_rpc_open()<br /> <br /> When ksmbd_rpc_open() fails then it must call ksmbd_rpc_id_free() to<br /> undo the result of ksmbd_ipc_id_alloc().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: silence the warning when evicting inode with dioread_nolock<br /> <br /> When evicting an inode with default dioread_nolock, it could be raced by<br /> the unwritten extents converting kworker after writeback some new<br /> allocated dirty blocks. It convert unwritten extents to written, the<br /> extents could be merged to upper level and free extent blocks, so it<br /> could mark the inode dirty again even this inode has been marked<br /> I_FREEING. But the inode-&gt;i_io_list check and warning in<br /> ext4_evict_inode() missing this corner case. Fortunately,<br /> ext4_evict_inode() will wait all extents converting finished before this<br /> check, so it will not lead to inode use-after-free problem, every thing<br /> is OK besides this warning. The WARN_ON_ONCE was originally designed<br /> for finding inode use-after-free issues in advance, but if we add<br /> current dioread_nolock case in, it will become not quite useful, so fix<br /> this warning by just remove this check.<br /> <br /> ======<br /> WARNING: CPU: 7 PID: 1092 at fs/ext4/inode.c:227<br /> ext4_evict_inode+0x875/0xc60<br /> ...<br /> RIP: 0010:ext4_evict_inode+0x875/0xc60<br /> ...<br /> Call Trace:<br /> <br /> evict+0x11c/0x2b0<br /> iput+0x236/0x3a0<br /> do_unlinkat+0x1b4/0x490<br /> __x64_sys_unlinkat+0x4c/0xb0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7fa933c1115b<br /> ======<br /> <br /> rm kworker<br /> ext4_end_io_end()<br /> vfs_unlink()<br /> ext4_unlink()<br /> ext4_convert_unwritten_io_end_vec()<br /> ext4_convert_unwritten_extents()<br /> ext4_map_blocks()<br /> ext4_ext_map_blocks()<br /> ext4_ext_try_to_merge_up()<br /> __mark_inode_dirty()<br /> check !I_FREEING<br /> locked_inode_to_wb_and_lock_list()<br /> iput()<br /> iput_final()<br /> evict()<br /> ext4_evict_inode()<br /> truncate_inode_pages_final() //wait release io_end<br /> inode_io_list_move_locked()<br /> ext4_release_io_end()<br /> trigger WARN_ON_ONCE()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: akcipher - default implementation for setting a private key<br /> <br /> Changes from v1:<br /> * removed the default implementation from set_pub_key: it is assumed that<br /> an implementation must always have this callback defined as there are<br /> no use case for an algorithm, which doesn&amp;#39;t need a public key<br /> <br /> Many akcipher implementations (like ECDSA) support only signature<br /> verifications, so they don&amp;#39;t have all callbacks defined.<br /> <br /> Commit 78a0324f4a53 ("crypto: akcipher - default implementations for<br /> request callbacks") introduced default callbacks for sign/verify<br /> operations, which just return an error code.<br /> <br /> However, these are not enough, because before calling sign the caller would<br /> likely call set_priv_key first on the instantiated transform (as the<br /> in-kernel testmgr does). This function does not have a default stub, so the<br /> kernel crashes, when trying to set a private key on an akcipher, which<br /> doesn&amp;#39;t support signature generation.<br /> <br /> I&amp;#39;ve noticed this, when trying to add a KAT vector for ECDSA signature to<br /> the testmgr.<br /> <br /> With this patch the testmgr returns an error in dmesg (as it should)<br /> instead of crashing the kernel NULL ptr dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8192u: Fix use after free in ieee80211_rx()<br /> <br /> We cannot dereference the "skb" pointer after calling<br /> ieee80211_monitor_rx(), because it is a use after free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: idmouse: fix an uninit-value in idmouse_open<br /> <br /> In idmouse_create_image, if any ftip_command fails, it will<br /> go to the reset label. However, this leads to the data in<br /> bulk_in_buffer[HEADER..IMGSIZE] uninitialized. And the check<br /> for valid image incurs an uninitialized dereference.<br /> <br /> Fix this by moving the check before reset label since this<br /> check only be valid if the data after bulk_in_buffer[HEADER]<br /> has concrete data.<br /> <br /> Note that this is found by KMSAN, so only kernel compilation<br /> is tested.