Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/9p: fix NULL pointer dereference on mkdir<br /> <br /> When a 9p tree was mounted with option &amp;#39;posixacl&amp;#39;, parent directory had a<br /> default ACL set for its subdirectories, e.g.:<br /> <br /> setfacl -m default:group:simpsons:rwx parentdir<br /> <br /> then creating a subdirectory crashed 9p client, as v9fs_fid_add() call in<br /> function v9fs_vfs_mkdir_dotl() sets the passed &amp;#39;fid&amp;#39; pointer to NULL<br /> (since dafbe689736) even though the subsequent v9fs_set_create_acl() call<br /> expects a valid non-NULL &amp;#39;fid&amp;#39; pointer:<br /> <br /> [ 37.273191] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> [ 37.322338] Call Trace:<br /> [ 37.323043] <br /> [ 37.323621] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)<br /> [ 37.324448] ? page_fault_oops (arch/x86/mm/fault.c:714)<br /> [ 37.325532] ? search_module_extables (kernel/module/main.c:3733)<br /> [ 37.326742] ? p9_client_walk (net/9p/client.c:1165) 9pnet<br /> [ 37.328006] ? search_bpf_extables (kernel/bpf/core.c:804)<br /> [ 37.329142] ? exc_page_fault (./arch/x86/include/asm/paravirt.h:686 arch/x86/mm/fault.c:1488 arch/x86/mm/fault.c:1538)<br /> [ 37.330196] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:574)<br /> [ 37.331330] ? p9_client_walk (net/9p/client.c:1165) 9pnet<br /> [ 37.332562] ? v9fs_fid_xattr_get (fs/9p/xattr.c:30) 9p<br /> [ 37.333824] v9fs_fid_xattr_set (fs/9p/fid.h:23 fs/9p/xattr.c:121) 9p<br /> [ 37.335077] v9fs_set_acl (fs/9p/acl.c:276) 9p<br /> [ 37.336112] v9fs_set_create_acl (fs/9p/acl.c:307) 9p<br /> [ 37.337326] v9fs_vfs_mkdir_dotl (fs/9p/vfs_inode_dotl.c:411) 9p<br /> [ 37.338590] vfs_mkdir (fs/namei.c:4313)<br /> [ 37.339535] do_mkdirat (fs/namei.c:4336)<br /> [ 37.340465] __x64_sys_mkdir (fs/namei.c:4354)<br /> [ 37.341455] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)<br /> [ 37.342447] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> Fix this by simply swapping the sequence of these two calls in<br /> v9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() before<br /> v9fs_fid_add().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix r_count dec/increment mismatch<br /> <br /> r_count is only increased when there is an oplock break wait,<br /> so r_count inc/decrement are not paired. This can cause r_count<br /> to become negative, which can lead to a problem where the ksmbd<br /> thread does not terminate.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spufs: fix a leak in spufs_create_context()<br /> <br /> Leak fixes back in 2008 missed one case - if we are trying to set affinity<br /> and spufs_mkdir() fails, we need to drop the reference to neighbor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spufs: fix gang directory lifetimes<br /> <br /> prior to "[POWERPC] spufs: Fix gang destroy leaks" we used to have<br /> a problem with gang lifetimes - creation of a gang returns opened<br /> gang directory, which normally gets removed when that gets closed,<br /> but if somebody has created a context belonging to that gang and<br /> kept it alive until the gang got closed, removal failed and we<br /> ended up with a leak.<br /> <br /> Unfortunately, it had been fixed the wrong way. Dentry of gang<br /> directory was no longer pinned, and rmdir on close was gone.<br /> One problem was that failure of open kept calling simple_rmdir()<br /> as cleanup, which meant an unbalanced dput(). Another bug was<br /> in the success case - gang creation incremented link count on<br /> root directory, but that was no longer undone when gang got<br /> destroyed.<br /> <br /> Fix consists of<br /> * reverting the commit in question<br /> * adding a counter to gang, protected by -&gt;i_rwsem<br /> of gang directory inode.<br /> * having it set to 1 at creation time, dropped<br /> in both spufs_dir_close() and spufs_gang_close() and bumped<br /> in spufs_create_context(), provided that it&amp;#39;s not 0.<br /> * using simple_recursive_removal() to take the gang<br /> directory out when counter reaches zero.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spufs: fix a leak on spufs_new_file() failure<br /> <br /> It&amp;#39;s called from spufs_fill_dir(), and caller of that will do<br /> spufs_rmdir() in case of failure. That does remove everything<br /> we&amp;#39;d managed to create, but... the problem dentry is still<br /> negative. IOW, it needs to be explicitly dropped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtnetlink: Allocate vfinfo size for VF GUIDs when supported<br /> <br /> Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs")<br /> added support for getting VF port and node GUIDs in netlink ifinfo<br /> messages, but their size was not taken into consideration in the<br /> function that allocates the netlink message, causing the following<br /> warning when a netlink message is filled with many VF port and node<br /> GUIDs:<br /> # echo 64 &gt; /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs<br /> # ip link show dev ib0<br /> RTNETLINK answers: Message too long<br /> Cannot send link get request: Message too long<br /> <br /> Kernel warning:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0<br /> Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core<br /> CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:rtnl_getlink+0x586/0x5a0<br /> Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00<br /> RSP: 0018:ffff888113557348 EFLAGS: 00010246<br /> RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000<br /> RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8<br /> RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000<br /> R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00<br /> R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff<br /> FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __warn+0xa5/0x230<br /> ? rtnl_getlink+0x586/0x5a0<br /> ? report_bug+0x22d/0x240<br /> ? handle_bug+0x53/0xa0<br /> ? exc_invalid_op+0x14/0x50<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? skb_trim+0x6a/0x80<br /> ? rtnl_getlink+0x586/0x5a0<br /> ? __pfx_rtnl_getlink+0x10/0x10<br /> ? rtnetlink_rcv_msg+0x1e5/0x860<br /> ? __pfx___mutex_lock+0x10/0x10<br /> ? rcu_is_watching+0x34/0x60<br /> ? __pfx_lock_acquire+0x10/0x10<br /> ? stack_trace_save+0x90/0xd0<br /> ? filter_irq_stacks+0x1d/0x70<br /> ? kasan_save_stack+0x30/0x40<br /> ? kasan_save_stack+0x20/0x40<br /> ? kasan_save_track+0x10/0x30<br /> rtnetlink_rcv_msg+0x21c/0x860<br /> ? entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ? __pfx_rtnetlink_rcv_msg+0x10/0x10<br /> ? arch_stack_walk+0x9e/0xf0<br /> ? rcu_is_watching+0x34/0x60<br /> ? lock_acquire+0xd5/0x410<br /> ? rcu_is_watching+0x34/0x60<br /> netlink_rcv_skb+0xe0/0x210<br /> ? __pfx_rtnetlink_rcv_msg+0x10/0x10<br /> ? __pfx_netlink_rcv_skb+0x10/0x10<br /> ? rcu_is_watching+0x34/0x60<br /> ? __pfx___netlink_lookup+0x10/0x10<br /> ? lock_release+0x62/0x200<br /> ? netlink_deliver_tap+0xfd/0x290<br /> ? rcu_is_watching+0x34/0x60<br /> ? lock_release+0x62/0x200<br /> ? netlink_deliver_tap+0x95/0x290<br /> netlink_unicast+0x31f/0x480<br /> ? __pfx_netlink_unicast+0x10/0x10<br /> ? rcu_is_watching+0x34/0x60<br /> ? lock_acquire+0xd5/0x410<br /> netlink_sendmsg+0x369/0x660<br /> ? lock_release+0x62/0x200<br /> ? __pfx_netlink_sendmsg+0x10/0x10<br /> ? import_ubuf+0xb9/0xf0<br /> ? __import_iovec+0x254/0x2b0<br /> ? lock_release+0x62/0x200<br /> ? __pfx_netlink_sendmsg+0x10/0x10<br /> ____sys_sendmsg+0x559/0x5a0<br /> ? __pfx_____sys_sendmsg+0x10/0x10<br /> ? __pfx_copy_msghdr_from_user+0x10/0x10<br /> ? rcu_is_watching+0x34/0x60<br /> ? do_read_fault+0x213/0x4a0<br /> ? rcu_is_watching+0x34/0x60<br /> ___sys_sendmsg+0xe4/0x150<br /> ? __pfx____sys_sendmsg+0x10/0x10<br /> ? do_fault+0x2cc/0x6f0<br /> ? handle_pte_fault+0x2e3/0x3d0<br /> ? __pfx_handle_pte_fault+0x10/0x10<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler<br /> <br /> Naresh Kamboju reported a "Bad frame pointer" kernel warning while<br /> running LTP trace ftrace_stress_test.sh in riscv. We can reproduce the<br /> same issue with the following command:<br /> <br /> ```<br /> $ cd /sys/kernel/debug/tracing<br /> $ echo &amp;#39;f:myprobe do_nanosleep%return args1=$retval&amp;#39; &gt; dynamic_events<br /> $ echo 1 &gt; events/fprobes/enable<br /> $ echo 1 &gt; tracing_on<br /> $ sleep 1<br /> ```<br /> <br /> And we can get the following kernel warning:<br /> <br /> [ 127.692888] ------------[ cut here ]------------<br /> [ 127.693755] Bad frame pointer: expected ff2000000065be50, received ba34c141e9594000<br /> [ 127.693755] from func do_nanosleep return to ffffffff800ccb16<br /> [ 127.698699] WARNING: CPU: 1 PID: 129 at kernel/trace/fgraph.c:755 ftrace_return_to_handler+0x1b2/0x1be<br /> [ 127.699894] Modules linked in:<br /> [ 127.700908] CPU: 1 UID: 0 PID: 129 Comm: sleep Not tainted 6.14.0-rc3-g0ab191c74642 #32<br /> [ 127.701453] Hardware name: riscv-virtio,qemu (DT)<br /> [ 127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be<br /> [ 127.702032] ra : ftrace_return_to_handler+0x1b2/0x1be<br /> [ 127.702151] epc : ffffffff8013b5e0 ra : ffffffff8013b5e0 sp : ff2000000065bd10<br /> [ 127.702221] gp : ffffffff819c12f8 tp : ff60000080853100 t0 : 6e00000000000000<br /> [ 127.702284] t1 : 0000000000000020 t2 : 6e7566206d6f7266 s0 : ff2000000065bd80<br /> [ 127.702346] s1 : ff60000081262000 a0 : 000000000000007b a1 : ffffffff81894f20<br /> [ 127.702408] a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000<br /> [ 127.702470] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038<br /> [ 127.702530] s2 : ba34c141e9594000 s3 : 0000000000000000 s4 : ff2000000065bdd0<br /> [ 127.702591] s5 : 00007fff8adcf400 s6 : 000055556dc1d8c0 s7 : 0000000000000068<br /> [ 127.702651] s8 : 00007fff8adf5d10 s9 : 000000000000006d s10: 0000000000000001<br /> [ 127.702710] s11: 00005555737377c8 t3 : ffffffff819d899e t4 : ffffffff819d899e<br /> [ 127.702769] t5 : ffffffff819d89a0 t6 : ff2000000065bb18<br /> [ 127.702826] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003<br /> [ 127.703292] [] ftrace_return_to_handler+0x1b2/0x1be<br /> [ 127.703760] [] return_to_handler+0x16/0x26<br /> [ 127.704009] [] return_to_handler+0x0/0x26<br /> [ 127.704057] [] common_nsleep+0x42/0x54<br /> [ 127.704117] [] __riscv_sys_clock_nanosleep+0xba/0x10a<br /> [ 127.704176] [] do_trap_ecall_u+0x188/0x218<br /> [ 127.704295] [] handle_exception+0x14a/0x156<br /> [ 127.705436] ---[ end trace 0000000000000000 ]---<br /> <br /> The reason is that the stack layout for constructing argument for the<br /> ftrace_return_to_handler in the return_to_handler does not match the<br /> __arch_ftrace_regs structure of riscv, leading to unexpected results.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: don&amp;#39;t unregister hook when table is dormant<br /> <br /> When nf_tables_updchain encounters an error, hook registration needs to<br /> be rolled back.<br /> <br /> This should only be done if the hook has been registered, which won&amp;#39;t<br /> happen when the table is flagged as dormant (inactive).<br /> <br /> Just move the assignment into the registration block.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix adapter NULL pointer dereference on reboot<br /> <br /> With SRIOV enabled, idpf ends up calling into idpf_remove() twice.<br /> First via idpf_shutdown() and then again when idpf_remove() calls into<br /> sriov_disable(), because the VF devices use the idpf driver, hence the<br /> same remove routine. When that happens, it is possible for the adapter<br /> to be NULL from the first call to idpf_remove(), leading to a NULL<br /> pointer dereference.<br /> <br /> echo 1 &gt; /sys/class/net//device/sriov_numvfs<br /> reboot<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> ...<br /> RIP: 0010:idpf_remove+0x22/0x1f0 [idpf]<br /> ...<br /> ? idpf_remove+0x22/0x1f0 [idpf]<br /> ? idpf_remove+0x1e4/0x1f0 [idpf]<br /> pci_device_remove+0x3f/0xb0<br /> device_release_driver_internal+0x19f/0x200<br /> pci_stop_bus_device+0x6d/0x90<br /> pci_stop_and_remove_bus_device+0x12/0x20<br /> pci_iov_remove_virtfn+0xbe/0x120<br /> sriov_disable+0x34/0xe0<br /> idpf_sriov_configure+0x58/0x140 [idpf]<br /> idpf_remove+0x1b9/0x1f0 [idpf]<br /> idpf_shutdown+0x12/0x30 [idpf]<br /> pci_device_shutdown+0x35/0x60<br /> device_shutdown+0x156/0x200<br /> ...<br /> <br /> Replace the direct idpf_remove() call in idpf_shutdown() with<br /> idpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which perform<br /> the bulk of the cleanup, such as stopping the init task, freeing IRQs,<br /> destroying the vports and freeing the mailbox. This avoids the calls to<br /> sriov_disable() in addition to a small netdev cleanup, and destroying<br /> workqueues, which don&amp;#39;t seem to be required on shutdown.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: cadence: Fix out-of-bounds array access in cdns_mrvl_xspi_setup_clock()<br /> <br /> If requested_clk &gt; 128, cdns_mrvl_xspi_setup_clock() iterates over the<br /> entire cdns_mrvl_xspi_clk_div_list array without breaking out early,<br /> causing &amp;#39;i&amp;#39; to go beyond the array bounds.<br /> <br /> Fix that by stopping the loop when it gets to the last entry, clamping<br /> the clock to the minimum 6.25 MHz.<br /> <br /> Fixes the following warning with an UBSAN kernel:<br /> <br /> vmlinux.o: warning: objtool: cdns_mrvl_xspi_setup_clock: unexpected end of section .text.cdns_mrvl_xspi_setup_clock

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: imx-card: Add NULL check in imx_card_probe()<br /> <br /> devm_kasprintf() returns NULL when memory allocation fails. Currently,<br /> imx_card_probe() does not check for this case, which results in a NULL<br /> pointer dereference.<br /> <br /> Add NULL check after devm_kasprintf() to prevent this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: decrease cached dst counters in dst_release<br /> <br /> Upstream fix ac888d58869b ("net: do not delay dst_entries_add() in<br /> dst_release()") moved decrementing the dst count from dst_destroy to<br /> dst_release to avoid accessing already freed data in case of netns<br /> dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels<br /> are used, this fix is incomplete as the same issue will be seen for<br /> cached dsts:<br /> <br /> Unable to handle kernel paging request at virtual address ffff5aabf6b5c000<br /> Call trace:<br /> percpu_counter_add_batch+0x3c/0x160 (P)<br /> dst_release+0xec/0x108<br /> dst_cache_destroy+0x68/0xd8<br /> dst_destroy+0x13c/0x168<br /> dst_destroy_rcu+0x1c/0xb0<br /> rcu_do_batch+0x18c/0x7d0<br /> rcu_core+0x174/0x378<br /> rcu_core_si+0x18/0x30<br /> <br /> Fix this by invalidating the cache, and thus decrementing cached dst<br /> counters, in dst_release too.