Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: always release netdev hooks from notifier<br /> <br /> This reverts "netfilter: nf_tables: skip netdev events generated on netns removal".<br /> <br /> The problem is that when a veth device is released, the veth release<br /> callback will also queue the peer netns device for removal.<br /> <br /> Its possible that the peer netns is also slated for removal. In this<br /> case, the device memory is already released before the pre_exit hook of<br /> the peer netns runs:<br /> <br /> BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0<br /> Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45<br /> Workqueue: netns cleanup_net<br /> Call Trace:<br /> nf_hook_entry_head+0x1b8/0x1d0<br /> __nf_unregister_net_hook+0x76/0x510<br /> nft_netdev_unregister_hooks+0xa0/0x220<br /> __nft_release_hook+0x184/0x490<br /> nf_tables_pre_exit_net+0x12f/0x1b0<br /> ..<br /> <br /> Order is:<br /> 1. First netns is released, veth_dellink() queues peer netns device<br /> for removal<br /> 2. peer netns is queued for removal<br /> 3. peer netns device is released, unreg event is triggered<br /> 4. unreg event is ignored because netns is going down<br /> 5. pre_exit hook calls nft_netdev_unregister_hooks but device memory<br /> might be free&amp;#39;d already.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/efa: Fix wrong resources deallocation order<br /> <br /> When trying to destroy QP or CQ, we first decrease the refcount and<br /> potentially free memory regions allocated for the object and then<br /> request the device to destroy the object. If the device fails, the<br /> object isn&amp;#39;t fully destroyed so the user/IB core can try to destroy the<br /> object again which will lead to underflow when trying to decrease an<br /> already zeroed refcount.<br /> <br /> Deallocate resources in reverse order of allocating them to safely free<br /> them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: fix race condition UAF in i915_perf_add_config_ioctl<br /> <br /> Userspace can guess the id value and try to race oa_config object creation<br /> with config remove, resulting in a use-after-free if we dereference the<br /> object after unlocking the metrics_lock. For that reason, unlocking the<br /> metrics_lock must be done after we are done dereferencing the object.<br /> <br /> [tursulin: Manually added stable tag.]<br /> (cherry picked from commit 49f6f6483b652108bcb73accd0204a464b922395)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix slab-out-of-bounds in init_smb2_rsp_hdr<br /> <br /> When smb1 mount fails, KASAN detect slab-out-of-bounds in<br /> init_smb2_rsp_hdr like the following one.<br /> For smb1 negotiate(56bytes) , init_smb2_rsp_hdr() for smb2 is called.<br /> The issue occurs while handling smb1 negotiate as smb2 server operations.<br /> Add smb server operations for smb1 (get_cmd_val, init_rsp_hdr,<br /> allocate_rsp_buf, check_user_session) to handle smb1 negotiate so that<br /> smb2 server operation does not handle it.<br /> <br /> [ 411.400423] CIFS: VFS: Use of the less secure dialect vers=1.0 is<br /> not recommended unless required for access to very old servers<br /> [ 411.400452] CIFS: Attempting to mount \\192.168.45.139\homes<br /> [ 411.479312] ksmbd: init_smb2_rsp_hdr : 492<br /> [ 411.479323] ==================================================================<br /> [ 411.479327] BUG: KASAN: slab-out-of-bounds in<br /> init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]<br /> [ 411.479369] Read of size 16 at addr ffff888488ed0734 by task kworker/14:1/199<br /> <br /> [ 411.479379] CPU: 14 PID: 199 Comm: kworker/14:1 Tainted: G<br /> OE 6.1.21 #3<br /> [ 411.479386] Hardware name: ASUSTeK COMPUTER INC. Z10PA-D8<br /> Series/Z10PA-D8 Series, BIOS 3801 08/23/2019<br /> [ 411.479390] Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]<br /> [ 411.479425] Call Trace:<br /> [ 411.479428] <br /> [ 411.479432] dump_stack_lvl+0x49/0x63<br /> [ 411.479444] print_report+0x171/0x4a8<br /> [ 411.479452] ? kasan_complete_mode_report_info+0x3c/0x200<br /> [ 411.479463] ? init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]<br /> [ 411.479497] kasan_report+0xb4/0x130<br /> [ 411.479503] ? init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]<br /> [ 411.479537] kasan_check_range+0x149/0x1e0<br /> [ 411.479543] memcpy+0x24/0x70<br /> [ 411.479550] init_smb2_rsp_hdr+0x1e2/0x1f4 [ksmbd]<br /> [ 411.479585] handle_ksmbd_work+0x109/0x760 [ksmbd]<br /> [ 411.479616] ? _raw_spin_unlock_irqrestore+0x50/0x50<br /> [ 411.479624] ? smb3_encrypt_resp+0x340/0x340 [ksmbd]<br /> [ 411.479656] process_one_work+0x49c/0x790<br /> [ 411.479667] worker_thread+0x2b1/0x6e0<br /> [ 411.479674] ? process_one_work+0x790/0x790<br /> [ 411.479680] kthread+0x177/0x1b0<br /> [ 411.479686] ? kthread_complete_and_exit+0x30/0x30<br /> [ 411.479692] ret_from_fork+0x22/0x30<br /> [ 411.479702]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: sunplus: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value,<br /> 1. the memory allocated in mmc_alloc_host() will be leaked<br /> 2. null-ptr-deref will happen when calling mmc_remove_host()<br /> in remove function spmmc_drv_remove() because deleting not<br /> added device.<br /> <br /> Fix this by checking the return value of mmc_add_host(). Moreover,<br /> I fixed the error handling path of spmmc_drv_probe() to clean up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: stm32: Fix refcount leak in stm32_pctrl_get_irq_domain<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: flower: fix filter idr initialization<br /> <br /> The cited commit moved idr initialization too early in fl_change() which<br /> allows concurrent users to access the filter that is still being<br /> initialized and is in inconsistent state, which, in turn, can cause NULL<br /> pointer dereference [0]. Since there is no obvious way to fix the ordering<br /> without reverting the whole cited commit, alternative approach taken to<br /> first insert NULL pointer into idr in order to allocate the handle but<br /> still cause fl_get() to return NULL and prevent concurrent users from<br /> seeing the filter while providing miss-to-action infrastructure with valid<br /> handle id early in fl_change().<br /> <br /> [ 152.434728] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN<br /> [ 152.436163] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> [ 152.437269] CPU: 4 PID: 3877 Comm: tc Not tainted 6.3.0-rc4+ #5<br /> [ 152.438110] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 152.439644] RIP: 0010:fl_dump_key+0x8b/0x1d10 [cls_flower]<br /> [ 152.440461] Code: 01 f2 02 f2 c7 40 08 04 f2 04 f2 c7 40 0c 04 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 84 24 00 01 00 00 48 89 c8 48 c1 e8 03 b6 04 10 84 c0 74 08 3c 03 0f 8e 98 19 00 00 8b 13 85 d2 74 57<br /> [ 152.442885] RSP: 0018:ffff88817a28f158 EFLAGS: 00010246<br /> [ 152.443851] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 152.444826] RDX: dffffc0000000000 RSI: ffffffff8500ae80 RDI: ffff88810a987900<br /> [ 152.445791] RBP: ffff888179d88240 R08: ffff888179d8845c R09: ffff888179d88240<br /> [ 152.446780] R10: ffffed102f451e48 R11: 00000000fffffff2 R12: ffff88810a987900<br /> [ 152.447741] R13: ffffffff8500ae80 R14: ffff88810a987900 R15: ffff888149b3c738<br /> [ 152.448756] FS: 00007f5eb2a34800(0000) GS:ffff88881ec00000(0000) knlGS:0000000000000000<br /> [ 152.449888] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 152.450685] CR2: 000000000046ad19 CR3: 000000010b0bd006 CR4: 0000000000370ea0<br /> [ 152.451641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 152.452628] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 152.453588] Call Trace:<br /> [ 152.454032] <br /> [ 152.454447] ? netlink_sendmsg+0x7a1/0xcb0<br /> [ 152.455109] ? sock_sendmsg+0xc5/0x190<br /> [ 152.455689] ? ____sys_sendmsg+0x535/0x6b0<br /> [ 152.456320] ? ___sys_sendmsg+0xeb/0x170<br /> [ 152.456916] ? do_syscall_64+0x3d/0x90<br /> [ 152.457529] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 152.458321] ? ___sys_sendmsg+0xeb/0x170<br /> [ 152.458958] ? __sys_sendmsg+0xb5/0x140<br /> [ 152.459564] ? do_syscall_64+0x3d/0x90<br /> [ 152.460122] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 152.460852] ? fl_dump_key_options.part.0+0xea0/0xea0 [cls_flower]<br /> [ 152.461710] ? _raw_spin_lock+0x7a/0xd0<br /> [ 152.462299] ? _raw_read_lock_irq+0x30/0x30<br /> [ 152.462924] ? nla_put+0x15e/0x1c0<br /> [ 152.463480] fl_dump+0x228/0x650 [cls_flower]<br /> [ 152.464112] ? fl_tmplt_dump+0x210/0x210 [cls_flower]<br /> [ 152.464854] ? __kmem_cache_alloc_node+0x1a7/0x330<br /> [ 152.465592] ? nla_put+0x15e/0x1c0<br /> [ 152.466160] tcf_fill_node+0x515/0x9a0<br /> [ 152.466766] ? tc_setup_offload_action+0xf0/0xf0<br /> [ 152.467463] ? __alloc_skb+0x13c/0x2a0<br /> [ 152.468067] ? __build_skb_around+0x330/0x330<br /> [ 152.468814] ? fl_get+0x107/0x1a0 [cls_flower]<br /> [ 152.469503] tc_del_tfilter+0x718/0x1330<br /> [ 152.470115] ? is_bpf_text_address+0xa/0x20<br /> [ 152.470765] ? tc_ctl_chain+0xee0/0xee0<br /> [ 152.471335] ? __kernel_text_address+0xe/0x30<br /> [ 152.471948] ? unwind_get_return_address+0x56/0xa0<br /> [ 152.472639] ? __thaw_task+0x150/0x150<br /> [ 152.473218] ? arch_stack_walk+0x98/0xf0<br /> [ 152.473839] ? __stack_depot_save+0x35/0x4c0<br /> [ 152.474501] ? stack_trace_save+0x91/0xc0<br /> [ 152.475119] ? security_capable+0x51/0x90<br /> [ 152.475741] rtnetlink_rcv_msg+0x2c1/0x9d0<br /> [ 152.476387] ? rtnl_calcit.isra.0+0x2b0/0x2b0<br /> [ 152.477042]<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: uclogic: Correct devm device reference for hidinput input_dev name<br /> <br /> Reference the HID device rather than the input device for the devm<br /> allocation of the input_dev name. Referencing the input_dev would lead to a<br /> use-after-free when the input_dev was unregistered and subsequently fires a<br /> uevent that depends on the name. At the point of firing the uevent, the<br /> name would be freed by devres management.<br /> <br /> Use devm_kasprintf to simplify the logic for allocating memory and<br /> formatting the input_dev name string.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ov5675: Fix memleak in ov5675_init_controls()<br /> <br /> There is a kmemleak when testing the media/i2c/ov5675.c with bpf mock<br /> device:<br /> <br /> AssertionError: unreferenced object 0xffff888107362160 (size 16):<br /> comm "python3", pid 277, jiffies 4294832798 (age 20.722s)<br /> hex dump (first 16 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc_node+0x44/0x1b0<br /> [] kvmalloc_node+0x34/0x180<br /> [] v4l2_ctrl_handler_init_class+0x11d/0x180<br /> [videodev]<br /> [] ov5675_probe+0x38b/0x897 [ov5675]<br /> [] i2c_device_probe+0x28d/0x680<br /> [] really_probe+0x17c/0x3f0<br /> [] __driver_probe_device+0xe3/0x170<br /> [] driver_probe_device+0x49/0x120<br /> [] __device_attach_driver+0xf7/0x150<br /> [] bus_for_each_drv+0x114/0x180<br /> [] __device_attach+0x1e5/0x2d0<br /> [] bus_probe_device+0x126/0x140<br /> [] device_add+0x810/0x1130<br /> [] i2c_new_client_device+0x386/0x540<br /> [] of_i2c_register_device+0xf1/0x110<br /> [] of_i2c_notify+0xfc/0x1f0<br /> <br /> ov5675_init_controls() won&amp;#39;t clean all the allocated resources in fail<br /> path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to<br /> prevent memleak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: fix memory leak in mt7996_mcu_exit<br /> <br /> Always purge mcu skb queues in mt7996_mcu_exit routine even if<br /> mt7996_firmware_state fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix null pointer panic in tracepoint in __replace_atomic_write_block<br /> <br /> We got a kernel panic if old_addr is NULL.<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=217266<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> Call Trace:<br /> <br /> f2fs_commit_atomic_write+0x619/0x990 [f2fs a1b985b80f5babd6f3ea778384908880812bfa43]<br /> __f2fs_ioctl+0xd8e/0x4080 [f2fs a1b985b80f5babd6f3ea778384908880812bfa43]<br /> ? vfs_write+0x2ae/0x3f0<br /> ? vfs_write+0x2ae/0x3f0<br /> __x64_sys_ioctl+0x91/0xd0<br /> do_syscall_64+0x5c/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7f69095fe53f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_api: remove block_cb from driver_list before freeing<br /> <br /> Error handler of tcf_block_bind() frees the whole bo-&gt;cb_list on error.<br /> However, by that time the flow_block_cb instances are already in the driver<br /> list because driver ndo_setup_tc() callback is called before that up the<br /> call chain in tcf_block_offload_cmd(). This leaves dangling pointers to<br /> freed objects in the list and causes use-after-free[0]. Fix it by also<br /> removing flow_block_cb instances from driver_list before deallocating them.<br /> <br /> [0]:<br /> [ 279.868433] ==================================================================<br /> [ 279.869964] BUG: KASAN: slab-use-after-free in flow_block_cb_setup_simple+0x631/0x7c0<br /> [ 279.871527] Read of size 8 at addr ffff888147e2bf20 by task tc/2963<br /> <br /> [ 279.873151] CPU: 6 PID: 2963 Comm: tc Not tainted 6.3.0-rc6+ #4<br /> [ 279.874273] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 279.876295] Call Trace:<br /> [ 279.876882] <br /> [ 279.877413] dump_stack_lvl+0x33/0x50<br /> [ 279.878198] print_report+0xc2/0x610<br /> [ 279.878987] ? flow_block_cb_setup_simple+0x631/0x7c0<br /> [ 279.879994] kasan_report+0xae/0xe0<br /> [ 279.880750] ? flow_block_cb_setup_simple+0x631/0x7c0<br /> [ 279.881744] ? mlx5e_tc_reoffload_flows_work+0x240/0x240 [mlx5_core]<br /> [ 279.883047] flow_block_cb_setup_simple+0x631/0x7c0<br /> [ 279.884027] tcf_block_offload_cmd.isra.0+0x189/0x2d0<br /> [ 279.885037] ? tcf_block_setup+0x6b0/0x6b0<br /> [ 279.885901] ? mutex_lock+0x7d/0xd0<br /> [ 279.886669] ? __mutex_unlock_slowpath.constprop.0+0x2d0/0x2d0<br /> [ 279.887844] ? ingress_init+0x1c0/0x1c0 [sch_ingress]<br /> [ 279.888846] tcf_block_get_ext+0x61c/0x1200<br /> [ 279.889711] ingress_init+0x112/0x1c0 [sch_ingress]<br /> [ 279.890682] ? clsact_init+0x2b0/0x2b0 [sch_ingress]<br /> [ 279.891701] qdisc_create+0x401/0xea0<br /> [ 279.892485] ? qdisc_tree_reduce_backlog+0x470/0x470<br /> [ 279.893473] tc_modify_qdisc+0x6f7/0x16d0<br /> [ 279.894344] ? tc_get_qdisc+0xac0/0xac0<br /> [ 279.895213] ? mutex_lock+0x7d/0xd0<br /> [ 279.896005] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 279.896910] rtnetlink_rcv_msg+0x5fe/0x9d0<br /> [ 279.897770] ? rtnl_calcit.isra.0+0x2b0/0x2b0<br /> [ 279.898672] ? __sys_sendmsg+0xb5/0x140<br /> [ 279.899494] ? do_syscall_64+0x3d/0x90<br /> [ 279.900302] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 279.901337] ? kasan_save_stack+0x2e/0x40<br /> [ 279.902177] ? kasan_save_stack+0x1e/0x40<br /> [ 279.903058] ? kasan_set_track+0x21/0x30<br /> [ 279.903913] ? kasan_save_free_info+0x2a/0x40<br /> [ 279.904836] ? ____kasan_slab_free+0x11a/0x1b0<br /> [ 279.905741] ? kmem_cache_free+0x179/0x400<br /> [ 279.906599] netlink_rcv_skb+0x12c/0x360<br /> [ 279.907450] ? rtnl_calcit.isra.0+0x2b0/0x2b0<br /> [ 279.908360] ? netlink_ack+0x1550/0x1550<br /> [ 279.909192] ? rhashtable_walk_peek+0x170/0x170<br /> [ 279.910135] ? kmem_cache_alloc_node+0x1af/0x390<br /> [ 279.911086] ? _copy_from_iter+0x3d6/0xc70<br /> [ 279.912031] netlink_unicast+0x553/0x790<br /> [ 279.912864] ? netlink_attachskb+0x6a0/0x6a0<br /> [ 279.913763] ? netlink_recvmsg+0x416/0xb50<br /> [ 279.914627] netlink_sendmsg+0x7a1/0xcb0<br /> [ 279.915473] ? netlink_unicast+0x790/0x790<br /> [ 279.916334] ? iovec_from_user.part.0+0x4d/0x220<br /> [ 279.917293] ? netlink_unicast+0x790/0x790<br /> [ 279.918159] sock_sendmsg+0xc5/0x190<br /> [ 279.918938] ____sys_sendmsg+0x535/0x6b0<br /> [ 279.919813] ? import_iovec+0x7/0x10<br /> [ 279.920601] ? kernel_sendmsg+0x30/0x30<br /> [ 279.921423] ? __copy_msghdr+0x3c0/0x3c0<br /> [ 279.922254] ? import_iovec+0x7/0x10<br /> [ 279.923041] ___sys_sendmsg+0xeb/0x170<br /> [ 279.923854] ? copy_msghdr_from_user+0x110/0x110<br /> [ 279.924797] ? ___sys_recvmsg+0xd9/0x130<br /> [ 279.925630] ? __perf_event_task_sched_in+0x183/0x470<br /> [ 279.926656] ? ___sys_sendmsg+0x170/0x170<br /> [ 279.927529] ? ctx_sched_in+0x530/0x530<br /> [ 279.928369] ? update_curr+0x283/0x4f0<br /> [ 279.929185] ? perf_event_update_userpage+0x570/0x570<br /> [ 279.930201] ? __fget_light+0x57/0x520<br /> [ 279.931023] ? __switch_to+0x53d/0xe70<br /> [ 27<br /> ---truncated---