Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: Fix possible null-ptr-deref in ubi_free_volume()<br /> <br /> It willl cause null-ptr-deref in the following case:<br /> <br /> uif_init()<br /> ubi_add_volume()<br /> cdev_add() -&gt; if it fails, call kill_volumes()<br /> device_register()<br /> <br /> kill_volumes() -&gt; if ubi_add_volume() fails call this function<br /> ubi_free_volume()<br /> cdev_del()<br /> device_unregister() -&gt; trying to delete a not added device,<br /> it causes null-ptr-deref<br /> <br /> So in ubi_free_volume(), it delete devices whether they are added<br /> or not, it will causes null-ptr-deref.<br /> <br /> Handle the error case whlie calling ubi_add_volume() to fix this<br /> problem. If add volume fails, set the corresponding vol to null,<br /> so it can not be accessed in kill_volumes() and release the<br /> resource in ubi_add_volume() error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: hold queue_lock when removing blkg-&gt;q_node<br /> <br /> When blkg is removed from q-&gt;blkg_list from blkg_free_workfn(), queue_lock<br /> has to be held, otherwise, all kinds of bugs(list corruption, hard lockup,<br /> ..) can be triggered from blkg_destroy_all().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_pmem: add the missing REQ_OP_WRITE for flush bio<br /> <br /> When doing mkfs.xfs on a pmem device, the following warning was<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct<br /> Modules linked in:<br /> CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ #154<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> RIP: 0010:submit_bio_noacct+0x340/0x520<br /> ......<br /> Call Trace:<br /> <br /> ? submit_bio_noacct+0xd5/0x520<br /> submit_bio+0x37/0x60<br /> async_pmem_flush+0x79/0xa0<br /> nvdimm_flush+0x17/0x40<br /> pmem_submit_bio+0x370/0x390<br /> __submit_bio+0xbc/0x190<br /> submit_bio_noacct_nocheck+0x14d/0x370<br /> submit_bio_noacct+0x1ef/0x520<br /> submit_bio+0x55/0x60<br /> submit_bio_wait+0x5a/0xc0<br /> blkdev_issue_flush+0x44/0x60<br /> <br /> The root cause is that submit_bio_noacct() needs bio_op() is either<br /> WRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn&amp;#39;t assign<br /> REQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just fail<br /> the flush bio.<br /> <br /> Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And we<br /> could fix the flush order issue and do flush optimization later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbe: Fix panic during XDP_TX with &gt; 64 CPUs<br /> <br /> Commit 4fe815850bdc ("ixgbe: let the xdpdrv work with more than 64 cpus")<br /> adds support to allow XDP programs to run on systems with more than<br /> 64 CPUs by locking the XDP TX rings and indexing them using cpu % 64<br /> (IXGBE_MAX_XDP_QS).<br /> <br /> Upon trying this out patch on a system with more than 64 cores,<br /> the kernel paniced with an array-index-out-of-bounds at the return in<br /> ixgbe_determine_xdp_ring in ixgbe.h, which means ixgbe_determine_xdp_q_idx<br /> was just returning the cpu instead of cpu % IXGBE_MAX_XDP_QS. An example<br /> splat:<br /> <br /> ==========================================================================<br /> UBSAN: array-index-out-of-bounds in<br /> /var/lib/dkms/ixgbe/5.18.6+focal-1/build/src/ixgbe.h:1147:26<br /> index 65 is out of range for type &amp;#39;ixgbe_ring *[64]&amp;#39;<br /> ==========================================================================<br /> BUG: kernel NULL pointer dereference, address: 0000000000000058<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP NOPTI<br /> CPU: 65 PID: 408 Comm: ksoftirqd/65<br /> Tainted: G IOE 5.15.0-48-generic #54~20.04.1-Ubuntu<br /> Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.5.4 01/13/2020<br /> RIP: 0010:ixgbe_xmit_xdp_ring+0x1b/0x1c0 [ixgbe]<br /> Code: 3b 52 d4 cf e9 42 f2 ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 b9<br /> 00 00 00 00 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 0f b7<br /> 47 58 0f b7 47 5a 0f b7 57 54 44 0f b7 76 08 66 41 39 c0<br /> RSP: 0018:ffffbc3fcd88fcb0 EFLAGS: 00010282<br /> RAX: ffff92a253260980 RBX: ffffbc3fe68b00a0 RCX: 0000000000000000<br /> RDX: ffff928b5f659000 RSI: ffff928b5f659000 RDI: 0000000000000000<br /> RBP: ffffbc3fcd88fce0 R08: ffff92b9dfc20580 R09: 0000000000000001<br /> R10: 3d3d3d3d3d3d3d3d R11: 3d3d3d3d3d3d3d3d R12: 0000000000000000<br /> R13: ffff928b2f0fa8c0 R14: ffff928b9be20050 R15: 000000000000003c<br /> FS: 0000000000000000(0000) GS:ffff92b9dfc00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000058 CR3: 000000011dd6a002 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ixgbe_poll+0x103e/0x1280 [ixgbe]<br /> ? sched_clock_cpu+0x12/0xe0<br /> __napi_poll+0x30/0x160<br /> net_rx_action+0x11c/0x270<br /> __do_softirq+0xda/0x2ee<br /> run_ksoftirqd+0x2f/0x50<br /> smpboot_thread_fn+0xb7/0x150<br /> ? sort_range+0x30/0x30<br /> kthread+0x127/0x150<br /> ? set_kthread_struct+0x50/0x50<br /> ret_from_fork+0x1f/0x30<br /> <br /> <br /> I think this is how it happens:<br /> <br /> Upon loading the first XDP program on a system with more than 64 CPUs,<br /> ixgbe_xdp_locking_key is incremented in ixgbe_xdp_setup. However,<br /> immediately after this, the rings are reconfigured by ixgbe_setup_tc.<br /> ixgbe_setup_tc calls ixgbe_clear_interrupt_scheme which calls<br /> ixgbe_free_q_vectors which calls ixgbe_free_q_vector in a loop.<br /> ixgbe_free_q_vector decrements ixgbe_xdp_locking_key once per call if<br /> it is non-zero. Commenting out the decrement in ixgbe_free_q_vector<br /> stopped my system from panicing.<br /> <br /> I suspect to make the original patch work, I would need to load an XDP<br /> program and then replace it in order to get ixgbe_xdp_locking_key back<br /> above 0 since ixgbe_setup_tc is only called when transitioning between<br /> XDP and non-XDP ring configurations, while ixgbe_xdp_locking_key is<br /> incremented every time ixgbe_xdp_setup is called.<br /> <br /> Also, ixgbe_setup_tc can be called via ethtool --set-channels, so this<br /> becomes another path to decrement ixgbe_xdp_locking_key to 0 on systems<br /> with more than 64 CPUs.<br /> <br /> Since ixgbe_xdp_locking_key only protects the XDP_TX path and is tied<br /> to the number of CPUs present, there is no reason to disable it upon<br /> unloading an XDP program. To avoid confusion, I have moved enabling<br /> ixgbe_xdp_locking_key into ixgbe_sw_init, which is part of the probe path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/client: Fix memory leak in drm_client_target_cloned<br /> <br /> dmt_mode is allocated and never freed in this function.<br /> It was found with the ast driver, but most drivers using generic fbdev<br /> setup are probably affected.<br /> <br /> This fixes the following kmemleak report:<br /> backtrace:<br /> [] drm_mode_duplicate+0x45/0x220 [drm]<br /> [] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm]<br /> [] drm_client_modeset_probe+0x6bd/0xf50 [drm]<br /> [] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]<br /> [] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]<br /> [] drm_client_register+0x169/0x240 [drm]<br /> [] ast_pci_probe+0x142/0x190 [ast]<br /> [] local_pci_probe+0xdc/0x180<br /> [] work_for_cpu_fn+0x4e/0xa0<br /> [] process_one_work+0x8b7/0x1540<br /> [] worker_thread+0x70a/0xed0<br /> [] kthread+0x29f/0x340<br /> [] ret_from_fork+0x1f/0x30<br /> unreferenced object 0xff11000333089a00 (size 128):

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Fix potential data race at PCM memory allocation helpers<br /> <br /> The PCM memory allocation helpers have a sanity check against too many<br /> buffer allocations. However, the check is performed without a proper<br /> lock and the allocation isn&amp;#39;t serialized; this allows user to allocate<br /> more memories than predefined max size.<br /> <br /> Practically seen, this isn&amp;#39;t really a big problem, as it&amp;#39;s more or<br /> less some "soft limit" as a sanity check, and it&amp;#39;s not possible to<br /> allocate unlimitedly. But it&amp;#39;s still better to address this for more<br /> consistent behavior.<br /> <br /> The patch covers the size check in do_alloc_pages() with the<br /> card-&gt;memory_mutex, and increases the allocated size there for<br /> preventing the further overflow. When the actual allocation fails,<br /> the size is decreased accordingly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: Add !tpm_amd_is_rng_defective() to the hwrng_unregister() call site<br /> <br /> The following crash was reported:<br /> <br /> [ 1950.279393] list_del corruption, ffff99560d485790-&gt;next is NULL<br /> [ 1950.279400] ------------[ cut here ]------------<br /> [ 1950.279401] kernel BUG at lib/list_debug.c:49!<br /> [ 1950.279405] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 1950.279407] CPU: 11 PID: 5886 Comm: modprobe Tainted: G O 6.2.8_1 #1<br /> [ 1950.279409] Hardware name: Gigabyte Technology Co., Ltd. B550M AORUS PRO-P/B550M AORUS PRO-P,<br /> BIOS F15c 05/11/2022<br /> [ 1950.279410] RIP: 0010:__list_del_entry_valid+0x59/0xc0<br /> [ 1950.279415] Code: 48 8b 01 48 39 f8 75 5a 48 8b 72 08 48 39 c6 75 65 b8 01 00 00 00 c3 cc cc cc<br /> cc 48 89 fe 48 c7 c7 08 a8 13 9e e8 b7 0a bc ff 0b 48 89 fe 48 c7 c7 38 a8 13 9e e8 a6 0a bc<br /> ff 0f 0b 48 89 fe<br /> [ 1950.279416] RSP: 0018:ffffa96d05647e08 EFLAGS: 00010246<br /> [ 1950.279418] RAX: 0000000000000033 RBX: ffff99560d485750 RCX: 0000000000000000<br /> [ 1950.279419] RDX: 0000000000000000 RSI: ffffffff9e107c59 RDI: 00000000ffffffff<br /> [ 1950.279420] RBP: ffffffffc19c5168 R08: 0000000000000000 R09: ffffa96d05647cc8<br /> [ 1950.279421] R10: 0000000000000003 R11: ffffffff9ea2a568 R12: 0000000000000000<br /> [ 1950.279422] R13: ffff99560140a2e0 R14: ffff99560127d2e0 R15: 0000000000000000<br /> [ 1950.279422] FS: 00007f67da795380(0000) GS:ffff995d1f0c0000(0000) knlGS:0000000000000000<br /> [ 1950.279424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1950.279424] CR2: 00007f67da7e65c0 CR3: 00000001feed2000 CR4: 0000000000750ee0<br /> [ 1950.279426] PKRU: 55555554<br /> [ 1950.279426] Call Trace:<br /> [ 1950.279428] <br /> [ 1950.279430] hwrng_unregister+0x28/0xe0 [rng_core]<br /> [ 1950.279436] tpm_chip_unregister+0xd5/0xf0 [tpm]<br /> <br /> Add the forgotten !tpm_amd_is_rng_defective() invariant to the<br /> hwrng_unregister() call site inside tpm_chip_unregister().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Use correct encap attribute during invalidation<br /> <br /> With introduction of post action infrastructure most of the users of encap<br /> attribute had been modified in order to obtain the correct attribute by<br /> calling mlx5e_tc_get_encap_attr() helper instead of assuming encap action<br /> is always on default attribute. However, the cited commit didn&amp;#39;t modify<br /> mlx5e_invalidate_encap() which prevents it from destroying correct modify<br /> header action which leads to a warning [0]. Fix the issue by using correct<br /> attribute.<br /> <br /> [0]:<br /> <br /> Feb 21 09:47:35 c-237-177-40-045 kernel: WARNING: CPU: 17 PID: 654 at drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:684 mlx5e_tc_attach_mod_hdr+0x1cc/0x230 [mlx5_core]<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: RIP: 0010:mlx5e_tc_attach_mod_hdr+0x1cc/0x230 [mlx5_core]<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: Call Trace:<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: <br /> Feb 21 09:47:35 c-237-177-40-045 kernel: mlx5e_tc_fib_event_work+0x8e3/0x1f60 [mlx5_core]<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? mlx5e_take_all_encap_flows+0xe0/0xe0 [mlx5_core]<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? lock_downgrade+0x6d0/0x6d0<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? lockdep_hardirqs_on_prepare+0x273/0x3f0<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? lockdep_hardirqs_on_prepare+0x273/0x3f0<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: process_one_work+0x7c2/0x1310<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? lockdep_hardirqs_on_prepare+0x3f0/0x3f0<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? pwq_dec_nr_in_flight+0x230/0x230<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? rwlock_bug.part.0+0x90/0x90<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: worker_thread+0x59d/0xec0<br /> Feb 21 09:47:35 c-237-177-40-045 kernel: ? __kthread_parkme+0xd9/0x1d0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: common: Fix refcount leak in parse_dai_link_info<br /> <br /> Add missing of_node_put()s before the returns to balance<br /> of_node_get()s and of_node_put()s, which may get unbalanced<br /> in case the for loop &amp;#39;for_each_available_child_of_node&amp;#39; returns<br /> early.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix missed ses refcounting<br /> <br /> Use new cifs_smb_ses_inc_refcount() helper to get an active reference<br /> of @ses and @ses-&gt;dfs_root_ses (if set). This will prevent<br /> @ses-&gt;dfs_root_ses of being put in the next call to cifs_put_smb_ses()<br /> and thus potentially causing an use-after-free bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix memory leak if ntfs_read_mft failed<br /> <br /> Label ATTR_ROOT in ntfs_read_mft() sets is_root = true and<br /> ni-&gt;ni_flags |= NI_FLAG_DIR, then next attr will goto label ATTR_ALLOC<br /> and alloc ni-&gt;dir.alloc_run. However two states are not always<br /> consistent and can make memory leak.<br /> <br /> 1) attr_name in ATTR_ROOT does not fit the condition it will set<br /> is_root = true but NI_FLAG_DIR is not set.<br /> 2) next attr_name in ATTR_ALLOC fits the condition and alloc<br /> ni-&gt;dir.alloc_run<br /> 3) in cleanup function ni_clear(), when NI_FLAG_DIR is set, it frees<br /> ni-&gt;dir.alloc_run, otherwise it frees ni-&gt;file.run<br /> 4) because NI_FLAG_DIR is not set in this case, ni-&gt;dir.alloc_run is<br /> leaked as kmemleak reported:<br /> <br /> unreferenced object 0xffff888003bc5480 (size 64):<br /> backtrace:<br /> [] __kmalloc_node+0x4e/0x1c0<br /> [] kvmalloc_node+0x39/0x1f0<br /> [] run_add_entry+0x18a/0xa40 [ntfs3]<br /> [] run_unpack+0x75d/0x8e0 [ntfs3]<br /> [] run_unpack_ex+0xbc/0x500 [ntfs3]<br /> [] ntfs_iget5+0xb25/0x2dd0 [ntfs3]<br /> [] ntfs_fill_super+0x218d/0x3580 [ntfs3]<br /> [] get_tree_bdev+0x3fb/0x710<br /> [] vfs_get_tree+0x8e/0x280<br /> [] path_mount+0xf3c/0x1930<br /> [] do_mount+0xf3/0x110<br /> ...<br /> <br /> Fix this by always setting is_root and NI_FLAG_DIR together.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: max9286: Free control handler<br /> <br /> The control handler is leaked in some probe-time error paths, as well as<br /> in the remove path. Fix it.