Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: Fix dereference of null pointer flow<br /> <br /> In the case where chain-&gt;flags &amp; NFT_CHAIN_HW_OFFLOAD is false then<br /> nft_flow_rule_create is not called and flow is NULL. The subsequent<br /> error handling execution via label err_destroy_flow_rule will lead<br /> to a null pointer dereference on flow when calling nft_flow_rule_destroy.<br /> Since the error path to err_destroy_flow_rule has to cater for null<br /> and non-null flows, only call nft_flow_rule_destroy if flow is non-null<br /> to fix this issue.<br /> <br /> Addresses-Coverity: ("Explicity null dereference")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init<br /> <br /> It&amp;#39;s a classic example of memleak, we allocate something, we fail and<br /> never free the resources.<br /> <br /> Make sure we free all resources on policy -&gt;init() failures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: fsl_ifc: fix leak of private memory on probe failure<br /> <br /> On probe error the driver should free the memory allocated for private<br /> structure. Fix this by using resource-managed allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: fsl_ifc: fix leak of IO mapping on probe failure<br /> <br /> On probe error the driver should unmap the IO memory. Smatch reports:<br /> <br /> drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: &amp;#39;fsl_ifc_ctrl_dev-&gt;gregs&amp;#39; not released on lines: 298.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix NULL dereference in nfs3svc_encode_getaclres<br /> <br /> In error cases the dentry may be NULL.<br /> <br /> Before 20798dfe249a, the encoder also checked dentry and<br /> d_really_is_positive(dentry), but that looks like overkill to me--zero<br /> status should be enough to guarantee a positive dentry.<br /> <br /> This isn&amp;#39;t the first time we&amp;#39;ve seen an error-case NULL dereference<br /> hidden in the initialization of a local variable in an xdr encoder. But<br /> I went back through the other recent rewrites and didn&amp;#39;t spot any<br /> similar bugs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: Fix NULL dereference on XCOPY completion<br /> <br /> CPU affinity control added with commit 39ae3edda325 ("scsi: target: core:<br /> Make completion affinity configurable") makes target_complete_cmd() queue<br /> work on a CPU based on se_tpg-&gt;se_tpg_wwn-&gt;cmd_compl_affinity state.<br /> <br /> LIO&amp;#39;s EXTENDED COPY worker is a special case in that read/write cmds are<br /> dispatched using the global xcopy_pt_tpg, which carries a NULL se_tpg_wwn<br /> pointer following initialization in target_xcopy_setup_pt().<br /> <br /> The NULL xcopy_pt_tpg-&gt;se_tpg_wwn pointer is dereferenced on completion of<br /> any EXTENDED COPY initiated read/write cmds. E.g using the libiscsi<br /> SCSI.ExtendedCopy.Simple test:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000001a8<br /> RIP: 0010:target_complete_cmd+0x9d/0x130 [target_core_mod]<br /> Call Trace:<br /> fd_execute_rw+0x148/0x42a [target_core_file]<br /> ? __dynamic_pr_debug+0xa7/0xe0<br /> ? target_check_reservation+0x5b/0x940 [target_core_mod]<br /> __target_execute_cmd+0x1e/0x90 [target_core_mod]<br /> transport_generic_new_cmd+0x17c/0x330 [target_core_mod]<br /> target_xcopy_issue_pt_cmd+0x9/0x60 [target_core_mod]<br /> target_xcopy_read_source.isra.7+0x10b/0x1b0 [target_core_mod]<br /> ? target_check_fua+0x40/0x40 [target_core_mod]<br /> ? transport_complete_task_attr+0x130/0x130 [target_core_mod]<br /> target_xcopy_do_work+0x61f/0xc00 [target_core_mod]<br /> <br /> This fix makes target_complete_cmd() queue work on se_cmd-&gt;cpuid if<br /> se_tpg_wwn is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix another slab-out-of-bounds in fib6_nh_flush_exceptions<br /> <br /> While running the self-tests on a KASAN enabled kernel, I observed a<br /> slab-out-of-bounds splat very similar to the one reported in<br /> commit 821bbf79fe46 ("ipv6: Fix KASAN: slab-out-of-bounds Read in<br /> fib6_nh_flush_exceptions").<br /> <br /> We additionally need to take care of fib6_metrics initialization<br /> failure when the caller provides an nh.<br /> <br /> The fix is similar, explicitly free the route instead of calling<br /> fib6_info_release on a half-initialized object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix memleak in io_init_wq_offload()<br /> <br /> I got memory leak report when doing fuzz test:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888107310a80 (size 96):<br /> comm "syz-executor.6", pid 4610, jiffies 4295140240 (age 20.135s)<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........<br /> backtrace:<br /> [] kmalloc include/linux/slab.h:591 [inline]<br /> [] kzalloc include/linux/slab.h:721 [inline]<br /> [] io_init_wq_offload fs/io_uring.c:7920 [inline]<br /> [] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955<br /> [] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016<br /> [] io_uring_add_tctx_node fs/io_uring.c:9052 [inline]<br /> [] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline]<br /> [] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline]<br /> [] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> CPU0 CPU1<br /> io_uring_enter io_uring_enter<br /> io_uring_add_tctx_node io_uring_add_tctx_node<br /> __io_uring_add_tctx_node __io_uring_add_tctx_node<br /> io_uring_alloc_task_context io_uring_alloc_task_context<br /> io_init_wq_offload io_init_wq_offload<br /> hash = kzalloc hash = kzalloc<br /> ctx-&gt;hash_map = hash ctx-&gt;hash_map = hash

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_skbmod: Skip non-Ethernet packets<br /> <br /> Currently tcf_skbmod_act() assumes that packets use Ethernet as their L2<br /> protocol, which is not always the case. As an example, for CAN devices:<br /> <br /> $ ip link add dev vcan0 type vcan<br /> $ ip link set up vcan0<br /> $ tc qdisc add dev vcan0 root handle 1: htb<br /> $ tc filter add dev vcan0 parent 1: protocol ip prio 10 \<br /> matchall action skbmod swap mac<br /> <br /> Doing the above silently corrupts all the packets. Do not perform skbmod<br /> actions for non-Ethernet packets.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netrom: Decrease sock refcount when sock timers expire<br /> <br /> Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use<br /> sock timer API. It replaces mod_timer() by sk_reset_timer(), and<br /> del_timer() by sk_stop_timer().<br /> <br /> Function sk_reset_timer() will increase the refcount of sock if it is<br /> called on an inactive timer, hence, in case the timer expires, we need to<br /> decrease the refcount ourselves in the handler, otherwise, the sock<br /> refcount will be unbalanced and the sock will never be freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak<br /> <br /> vcpu_put is not called if the user copy fails. This can result in preempt<br /> notifier corruption and crashes, among other issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix uninit-value in caif_seqpkt_sendmsg<br /> <br /> When nr_segs equal to zero in iovec_from_user, the object<br /> msg-&gt;msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg<br /> which is defined in ___sys_sendmsg. So we cann&amp;#39;t just judge<br /> msg-&gt;msg_iter.iov-&gt;base directlly. We can use nr_segs to judge<br /> msg in caif_seqpkt_sendmsg whether has data buffers.<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x1c9/0x220 lib/dump_stack.c:118<br /> kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118<br /> __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215<br /> caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542<br /> sock_sendmsg_nosec net/socket.c:652 [inline]<br /> sock_sendmsg net/socket.c:672 [inline]<br /> ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343<br /> ___sys_sendmsg net/socket.c:2397 [inline]<br /> __sys_sendmmsg+0x808/0xc90 net/socket.c:2480<br /> __compat_sys_sendmmsg net/compat.c:656 [inline]