Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> BPF: Fix potential bad pointer dereference in bpf_sys_bpf()<br /> <br /> The bpf_sys_bpf() helper function allows an eBPF program to load another<br /> eBPF program from within the kernel. In this case the argument union<br /> bpf_attr pointer (as well as the insns and license pointers inside) is a<br /> kernel address instead of a userspace address (which is the case of a<br /> usual bpf() syscall). To make the memory copying process in the syscall<br /> work in both cases, bpfptr_t was introduced to wrap around the pointer<br /> and distinguish its origin. Specifically, when copying memory contents<br /> from a bpfptr_t, a copy_from_user() is performed in case of a userspace<br /> address and a memcpy() is performed for a kernel address.<br /> <br /> This can lead to problems because the in-kernel pointer is never checked<br /> for validity. The problem happens when an eBPF syscall program tries to<br /> call bpf_sys_bpf() to load a program but provides a bad insns pointer --<br /> say 0xdeadbeef -- in the bpf_attr union. The helper calls __sys_bpf()<br /> which would then call bpf_prog_load() to load the program.<br /> bpf_prog_load() is responsible for copying the eBPF instructions to the<br /> newly allocated memory for the program; it creates a kernel bpfptr_t for<br /> insns and invokes copy_from_bpfptr(). Internally, all bpfptr_t<br /> operations are backed by the corresponding sockptr_t operations, which<br /> performs direct memcpy() on kernel pointers for copy_from/strncpy_from<br /> operations. Therefore, the code is always happy to dereference the bad<br /> pointer to trigger a un-handle-able page fault and in turn an oops.<br /> However, this is not supposed to happen because at that point the eBPF<br /> program is already verified and should not cause a memory error.<br /> <br /> Sample KASAN trace:<br /> <br /> [ 25.685056][ T228] ==================================================================<br /> [ 25.685680][ T228] BUG: KASAN: user-memory-access in copy_from_bpfptr+0x21/0x30<br /> [ 25.686210][ T228] Read of size 80 at addr 00000000deadbeef by task poc/228<br /> [ 25.686732][ T228]<br /> [ 25.686893][ T228] CPU: 3 PID: 228 Comm: poc Not tainted 5.19.0-rc7 #7<br /> [ 25.687375][ T228] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014<br /> [ 25.687991][ T228] Call Trace:<br /> [ 25.688223][ T228] <br /> [ 25.688429][ T228] dump_stack_lvl+0x73/0x9e<br /> [ 25.688747][ T228] print_report+0xea/0x200<br /> [ 25.689061][ T228] ? copy_from_bpfptr+0x21/0x30<br /> [ 25.689401][ T228] ? _printk+0x54/0x6e<br /> [ 25.689693][ T228] ? _raw_spin_lock_irqsave+0x70/0xd0<br /> [ 25.690071][ T228] ? copy_from_bpfptr+0x21/0x30<br /> [ 25.690412][ T228] kasan_report+0xb5/0xe0<br /> [ 25.690716][ T228] ? copy_from_bpfptr+0x21/0x30<br /> [ 25.691059][ T228] kasan_check_range+0x2bd/0x2e0<br /> [ 25.691405][ T228] ? copy_from_bpfptr+0x21/0x30<br /> [ 25.691734][ T228] memcpy+0x25/0x60<br /> [ 25.692000][ T228] copy_from_bpfptr+0x21/0x30<br /> [ 25.692328][ T228] bpf_prog_load+0x604/0x9e0<br /> [ 25.692653][ T228] ? cap_capable+0xb4/0xe0<br /> [ 25.692956][ T228] ? security_capable+0x4f/0x70<br /> [ 25.693324][ T228] __sys_bpf+0x3af/0x580<br /> [ 25.693635][ T228] bpf_sys_bpf+0x45/0x240<br /> [ 25.693937][ T228] bpf_prog_f0ec79a5a3caca46_bpf_func1+0xa2/0xbd<br /> [ 25.694394][ T228] bpf_prog_run_pin_on_cpu+0x2f/0xb0<br /> [ 25.694756][ T228] bpf_prog_test_run_syscall+0x146/0x1c0<br /> [ 25.695144][ T228] bpf_prog_test_run+0x172/0x190<br /> [ 25.695487][ T228] __sys_bpf+0x2c5/0x580<br /> [ 25.695776][ T228] __x64_sys_bpf+0x3a/0x50<br /> [ 25.696084][ T228] do_syscall_64+0x60/0x90<br /> [ 25.696393][ T228] ? fpregs_assert_state_consistent+0x50/0x60<br /> [ 25.696815][ T228] ? exit_to_user_mode_prepare+0x36/0xa0<br /> [ 25.697202][ T228] ? syscall_exit_to_user_mode+0x20/0x40<br /> [ 25.697586][ T228] ? do_syscall_64+0x6e/0x90<br /> [ 25.697899][ T228] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 25.698312][ T228] RIP: 0033:0x7f6d543fb759<br /> [ 25.698624][ T228] Code: 08 5b 89 e8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: move subflow cleanup in mptcp_destroy_common()<br /> <br /> If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATE<br /> eBPF program, the MPTCP protocol ends-up leaking all the subflows:<br /> the related cleanup happens in __mptcp_destroy_sock() that is not<br /> invoked in such code path.<br /> <br /> Address the issue moving the subflow sockets cleanup in the<br /> mptcp_destroy_common() helper, which is invoked in every msk cleanup<br /> path.<br /> <br /> Additionally get rid of the intermediate list_splice_init step, which<br /> is an unneeded relic from the past.<br /> <br /> The issue is present since before the reported root cause commit, but<br /> any attempt to backport the fix before that hash will require a complete<br /> rewrite.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-blk: Avoid use-after-free on suspend/resume<br /> <br /> hctx-&gt;user_data is set to vq in virtblk_init_hctx(). However, vq is<br /> freed on suspend and reallocated on resume. So, hctx-&gt;user_data is<br /> invalid after resume, and it will cause use-after-free accessing which<br /> will result in the kernel crash something like below:<br /> <br /> [ 22.428391] Call Trace:<br /> [ 22.428899] <br /> [ 22.429339] virtqueue_add_split+0x3eb/0x620<br /> [ 22.430035] ? __blk_mq_alloc_requests+0x17f/0x2d0<br /> [ 22.430789] ? kvm_clock_get_cycles+0x14/0x30<br /> [ 22.431496] virtqueue_add_sgs+0xad/0xd0<br /> [ 22.432108] virtblk_add_req+0xe8/0x150<br /> [ 22.432692] virtio_queue_rqs+0xeb/0x210<br /> [ 22.433330] blk_mq_flush_plug_list+0x1b8/0x280<br /> [ 22.434059] __blk_flush_plug+0xe1/0x140<br /> [ 22.434853] blk_finish_plug+0x20/0x40<br /> [ 22.435512] read_pages+0x20a/0x2e0<br /> [ 22.436063] ? folio_add_lru+0x62/0xa0<br /> [ 22.436652] page_cache_ra_unbounded+0x112/0x160<br /> [ 22.437365] filemap_get_pages+0xe1/0x5b0<br /> [ 22.437964] ? context_to_sid+0x70/0x100<br /> [ 22.438580] ? sidtab_context_to_sid+0x32/0x400<br /> [ 22.439979] filemap_read+0xcd/0x3d0<br /> [ 22.440917] xfs_file_buffered_read+0x4a/0xc0<br /> [ 22.441984] xfs_file_read_iter+0x65/0xd0<br /> [ 22.442970] __kernel_read+0x160/0x2e0<br /> [ 22.443921] bprm_execve+0x21b/0x640<br /> [ 22.444809] do_execveat_common.isra.0+0x1a8/0x220<br /> [ 22.446008] __x64_sys_execve+0x2d/0x40<br /> [ 22.446920] do_syscall_64+0x37/0x90<br /> [ 22.447773] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> This patch fixes this issue by getting vq from vblk, and removes<br /> virtblk_init_hctx().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: do not queue data on closed subflows<br /> <br /> Dipanjan reported a syzbot splat at close time:<br /> <br /> WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153<br /> inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153<br /> Modules linked in: uio_ivshmem(OE) uio(E)<br /> CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G OE<br /> 5.19.0-rc6-g2eae0556bb9d #2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.13.0-1ubuntu1.1 04/01/2014<br /> Workqueue: events mptcp_worker<br /> RIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153<br /> Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91<br /> f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 0b<br /> e9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4d<br /> RSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00<br /> RDX: 0000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002<br /> RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000<br /> R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400<br /> R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258<br /> FS: 0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0<br /> Call Trace:<br /> <br /> __sk_destruct+0x4f/0x8e0 net/core/sock.c:2067<br /> sk_destruct+0xbd/0xe0 net/core/sock.c:2112<br /> __sk_free+0xef/0x3d0 net/core/sock.c:2123<br /> sk_free+0x78/0xa0 net/core/sock.c:2134<br /> sock_put include/net/sock.h:1927 [inline]<br /> __mptcp_close_ssk+0x50f/0x780 net/mptcp/protocol.c:2351<br /> __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828<br /> mptcp_worker+0x5d2/0xc90 net/mptcp/protocol.c:2586<br /> process_one_work+0x9cc/0x1650 kernel/workqueue.c:2289<br /> worker_thread+0x623/0x1070 kernel/workqueue.c:2436<br /> kthread+0x2e9/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302<br /> <br /> <br /> The root cause of the problem is that an mptcp-level (re)transmit can<br /> race with mptcp_close() and the packet scheduler checks the subflow<br /> state before acquiring the socket lock: we can try to (re)transmit on<br /> an already closed ssk.<br /> <br /> Fix the issue checking again the subflow socket status under the<br /> subflow socket lock protection. Additionally add the missing check<br /> for the fallback-to-tcp case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix NULL pointer dereference in iavf_get_link_ksettings<br /> <br /> Fix possible NULL pointer dereference, due to freeing of adapter-&gt;vf_res<br /> in iavf_init_get_resources. Previous commit introduced a regression,<br /> where receiving IAVF_ERR_ADMIN_QUEUE_NO_WORK from iavf_get_vf_config<br /> would free adapter-&gt;vf_res. However, netdev is still registered, so<br /> ethtool_ops can be called. Calling iavf_get_link_ksettings with no vf_res,<br /> will result with:<br /> [ 9385.242676] BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> [ 9385.242683] #PF: supervisor read access in kernel mode<br /> [ 9385.242686] #PF: error_code(0x0000) - not-present page<br /> [ 9385.242690] PGD 0 P4D 0<br /> [ 9385.242696] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI<br /> [ 9385.242701] CPU: 6 PID: 3217 Comm: pmdalinux Kdump: loaded Tainted: G S E 5.18.0-04958-ga54ce3703613-dirty #1<br /> [ 9385.242708] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019<br /> [ 9385.242710] RIP: 0010:iavf_get_link_ksettings+0x29/0xd0 [iavf]<br /> [ 9385.242745] Code: 00 0f 1f 44 00 00 b8 01 ef ff ff 48 c7 46 30 00 00 00 00 48 c7 46 38 00 00 00 00 c6 46 0b 00 66 89 46 08 48 8b 87 68 0e 00 00 40 08 80 75 50 8b 87 5c 0e 00 00 83 f8 08 74 7a 76 1d 83 f8 20<br /> [ 9385.242749] RSP: 0018:ffffc0560ec7fbd0 EFLAGS: 00010246<br /> [ 9385.242755] RAX: 0000000000000000 RBX: ffffc0560ec7fc08 RCX: 0000000000000000<br /> [ 9385.242759] RDX: ffffffffc0ad4550 RSI: ffffc0560ec7fc08 RDI: ffffa0fc66674000<br /> [ 9385.242762] RBP: 00007ffd1fb2bf50 R08: b6a2d54b892363ee R09: ffffa101dc14fb00<br /> [ 9385.242765] R10: 0000000000000000 R11: 0000000000000004 R12: ffffa0fc66674000<br /> [ 9385.242768] R13: 0000000000000000 R14: ffffa0fc66674000 R15: 00000000ffffffa1<br /> [ 9385.242771] FS: 00007f93711a2980(0000) GS:ffffa0fad72c0000(0000) knlGS:0000000000000000<br /> [ 9385.242775] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 9385.242778] CR2: 0000000000000008 CR3: 0000000a8e61c003 CR4: 00000000003706e0<br /> [ 9385.242781] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 9385.242784] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 9385.242787] Call Trace:<br /> [ 9385.242791] <br /> [ 9385.242793] ethtool_get_settings+0x71/0x1a0<br /> [ 9385.242814] __dev_ethtool+0x426/0x2f40<br /> [ 9385.242823] ? slab_post_alloc_hook+0x4f/0x280<br /> [ 9385.242836] ? kmem_cache_alloc_trace+0x15d/0x2f0<br /> [ 9385.242841] ? dev_ethtool+0x59/0x170<br /> [ 9385.242848] dev_ethtool+0xa7/0x170<br /> [ 9385.242856] dev_ioctl+0xc3/0x520<br /> [ 9385.242866] sock_do_ioctl+0xa0/0xe0<br /> [ 9385.242877] sock_ioctl+0x22f/0x320<br /> [ 9385.242885] __x64_sys_ioctl+0x84/0xc0<br /> [ 9385.242896] do_syscall_64+0x3a/0x80<br /> [ 9385.242904] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 9385.242918] RIP: 0033:0x7f93702396db<br /> [ 9385.242923] Code: 73 01 c3 48 8b 0d ad 57 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 57 38 00 f7 d8 64 89 01 48<br /> [ 9385.242927] RSP: 002b:00007ffd1fb2bf18 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> [ 9385.242932] RAX: ffffffffffffffda RBX: 000055671b1d2fe0 RCX: 00007f93702396db<br /> [ 9385.242935] RDX: 00007ffd1fb2bf20 RSI: 0000000000008946 RDI: 0000000000000007<br /> [ 9385.242937] RBP: 00007ffd1fb2bf20 R08: 0000000000000003 R09: 0030763066307330<br /> [ 9385.242940] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd1fb2bf80<br /> [ 9385.242942] R13: 0000000000000007 R14: 0000556719f6de90 R15: 00007ffd1fb2c1b0<br /> [ 9385.242948] <br /> [ 9385.242949] Modules linked in: iavf(E) xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nft_compat nf_nat_tftp nft_objref nf_conntrack_tftp bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink vfat fat irdma ib_uverbs ib_core intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretem<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix adminq error handling<br /> <br /> iavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherent<br /> memory for VF mailbox.<br /> Free DMA regions for both ASQ and ARQ in case error happens during<br /> configuration of ASQ/ARQ registers.<br /> Without this change it is possible to see when unloading interface:<br /> 74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32]<br /> One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix missing i_op in ntfs_read_mft<br /> <br /> There is null pointer dereference because i_op == NULL.<br /> The bug happens because we don&amp;#39;t initialize i_op for records in $Extend.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix NULL deref in ntfs_update_mftmirr<br /> <br /> If ntfs_fill_super() wasn&amp;#39;t called then sbi-&gt;sb will be equal to NULL.<br /> Code should check this ptr before dereferencing. Syzbot hit this issue<br /> via passing wrong mount param as can be seen from log below<br /> <br /> Fail log:<br /> ntfs3: Unknown parameter &amp;#39;iochvrset&amp;#39;<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 /> CPU: 1 PID: 3589 Comm: syz-executor210 Not tainted 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0<br /> ...<br /> Call Trace:<br /> <br /> put_ntfs+0x1ed/0x2a0 fs/ntfs3/super.c:463<br /> ntfs_fs_free+0x6a/0xe0 fs/ntfs3/super.c:1363<br /> put_fs_context+0x119/0x7a0 fs/fs_context.c:469<br /> do_new_mount+0x2b4/0xad0 fs/namespace.c:3044<br /> do_mount fs/namespace.c:3383 [inline]<br /> __do_sys_mount fs/namespace.c:3591 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa_sim_blk: set number of address spaces and virtqueue groups<br /> <br /> Commit bda324fd037a ("vdpasim: control virtqueue support") added two<br /> new fields (nas, ngroups) to vdpasim_dev_attr, but we forgot to<br /> initialize them for vdpa_sim_blk.<br /> <br /> When creating a new vdpa_sim_blk device this causes the kernel<br /> to panic in this way:<br />    $ vdpa dev add mgmtdev vdpasim_blk name blk0<br />    BUG: kernel NULL pointer dereference, address: 0000000000000030<br />    ...<br />    RIP: 0010:vhost_iotlb_add_range_ctx+0x41/0x220 [vhost_iotlb]<br />    ...<br />    Call Trace:<br />     <br />     vhost_iotlb_add_range+0x11/0x800 [vhost_iotlb]<br />     vdpasim_map_range+0x91/0xd0 [vdpa_sim]<br />     vdpasim_alloc_coherent+0x56/0x90 [vdpa_sim]<br />     ...<br /> <br /> This happens because vdpasim-&gt;iommu[0] is not initialized when<br /> dev_attr.nas is 0.<br /> <br /> Let&amp;#39;s fix this issue by initializing both (nas, ngroups) to 1 for<br /> vdpa_sim_blk.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: Fix mcam entry resource leak<br /> <br /> The teardown sequence in FLR handler returns if no NIX LF<br /> is attached to PF/VF because it indicates that graceful<br /> shutdown of resources already happened. But there is a<br /> chance of all allocated MCAM entries not being freed by<br /> PF/VF. Hence free mcam entries even in case of detached LF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: nomadik: Fix refcount leak in nmk_pinctrl_dt_subnode_to_map<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak."

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: don&amp;#39;t leak snap_rwsem in handle_cap_grant<br /> <br /> When handle_cap_grant is called on an IMPORT op, then the snap_rwsem is<br /> held and the function is expected to release it before returning. It<br /> currently fails to do that in all cases which could lead to a deadlock.