Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find()<br /> <br /> nf_osf_find() incorrectly returns true on mismatch, this leads to<br /> copying uninitialized memory area in nft_osf which can be used to leak<br /> stale kernel stack data to userspace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scmi: Harden accesses to the reset domains<br /> <br /> Accessing reset domains descriptors by the index upon the SCMI drivers<br /> requests through the SCMI reset operations interface can potentially<br /> lead to out-of-bound violations if the SCMI driver misbehave.<br /> <br /> Add an internal consistency check before any such domains descriptors<br /> accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get()<br /> <br /> We should call of_node_put() for the reference returned by<br /> of_parse_phandle() in fail path or when it is not used anymore.<br /> Here we only need to move the of_node_put() before the check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: topology: fix possible overflow in amu_fie_setup()<br /> <br /> cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*,<br /> while freq_inv_set_max_ratio() gets passed this frequency in Hz as &amp;#39;u64&amp;#39;.<br /> Multiplying max frequency by 1000 can potentially result in overflow --<br /> multiplying by 1000ULL instead should avoid that...<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with the SVACE static<br /> analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context.<br /> <br /> Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations<br /> __free_slab() invocations out of IRQ context") moved all flush_cpu_slab()<br /> invocations to the global workqueue to avoid a problem related<br /> with deactivate_slab()/__free_slab() being called from an IRQ context<br /> on PREEMPT_RT kernels.<br /> <br /> When the flush_all_cpu_locked() function is called from a task context<br /> it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up<br /> flushing the global workqueue, this will cause a dependency issue.<br /> <br /> workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core]<br /> is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab<br /> WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637<br /> check_flush_dependency+0x10a/0x120<br /> Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core]<br /> RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace:<br /> __flush_work.isra.0+0xbf/0x220<br /> ? __queue_work+0x1dc/0x420<br /> flush_all_cpus_locked+0xfb/0x120<br /> __kmem_cache_shutdown+0x2b/0x320<br /> kmem_cache_destroy+0x49/0x100<br /> bioset_exit+0x143/0x190<br /> blk_release_queue+0xb9/0x100<br /> kobject_cleanup+0x37/0x130<br /> nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc]<br /> nvme_free_ctrl+0x1ac/0x2b0 [nvme_core]<br /> <br /> Fix this bug by creating a workqueue for the flush operation with<br /> the WQ_MEM_RECLAIM bit set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slub: fix to return errno if kmalloc() fails<br /> <br /> In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to<br /> out-of-memory, if it fails, return errno correctly rather than<br /> triggering panic via BUG_ON();<br /> <br /> kernel BUG at mm/slub.c:5893!<br /> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> <br /> Call trace:<br /> sysfs_slab_add+0x258/0x260 mm/slub.c:5973<br /> __kmem_cache_create+0x60/0x118 mm/slub.c:4899<br /> create_cache mm/slab_common.c:229 [inline]<br /> kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335<br /> kmem_cache_create+0x1c/0x28 mm/slab_common.c:390<br /> f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]<br /> f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808<br /> f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149<br /> mount_bdev+0x1b8/0x210 fs/super.c:1400<br /> f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512<br /> legacy_get_tree+0x30/0x74 fs/fs_context.c:610<br /> vfs_get_tree+0x40/0x140 fs/super.c:1530<br /> do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040<br /> path_mount+0x358/0x914 fs/namespace.c:3370<br /> do_mount fs/namespace.c:3383 [inline]<br /> __do_sys_mount fs/namespace.c:3591 [inline]<br /> __se_sys_mount fs/namespace.c:3568 [inline]<br /> __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully<br /> <br /> When running gpio test on nxp-ls1028 platform with below command<br /> gpiomon --num-events=3 --rising-edge gpiochip1 25<br /> There will be a warning trace as below:<br /> Call trace:<br /> free_irq+0x204/0x360<br /> lineevent_free+0x64/0x70<br /> gpio_ioctl+0x598/0x6a0<br /> __arm64_sys_ioctl+0xb4/0x100<br /> invoke_syscall+0x5c/0x130<br /> ......<br /> el0t_64_sync+0x1a0/0x1a4<br /> The reason of this issue is that calling request_threaded_irq()<br /> function failed, and then lineevent_free() is invoked to release<br /> the resource. Since the lineevent_state::irq was already set, so<br /> the subsequent invocation of free_irq() would trigger the above<br /> warning call trace. To fix this issue, set the lineevent_state::irq<br /> after the IRQ register successfully.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: mockup: Fix potential resource leakage when register a chip<br /> <br /> If creation of software node fails, the locally allocated string<br /> array is left unfreed. Free it on error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gem: Really move i915_gem_context.link under ref protection<br /> <br /> i915_perf assumes that it can use the i915_gem_context reference to<br /> protect its i915-&gt;gem.contexts.list iteration. However, this requires<br /> that we do not remove the context from the list until after we drop the<br /> final reference and release the struct. If, as currently, we remove the<br /> context from the list during context_close(), the link.next pointer may<br /> be poisoned while we are holding the context reference and cause a GPF:<br /> <br /> [ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff<br /> [ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP<br /> [ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G E 5.17.9 #180<br /> [ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017<br /> [ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915]<br /> [ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff<br /> [ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202<br /> [ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000<br /> [ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68<br /> [ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc<br /> [ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860<br /> [ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc<br /> [ 4070.575016] FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000<br /> [ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0<br /> [ 4070.575029] Call Trace:<br /> [ 4070.575033] <br /> [ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915]<br /> [ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915]<br /> [ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915]<br /> [ 4070.575224] ? asm_common_interrupt+0x1e/0x40<br /> [ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915]<br /> [ 4070.575290] drm_ioctl_kernel+0x85/0x110<br /> [ 4070.575296] ? update_load_avg+0x5f/0x5e0<br /> [ 4070.575302] drm_ioctl+0x1d3/0x370<br /> [ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915]<br /> [ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915]<br /> [ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0<br /> [ 4070.575451] ? __do_softirq+0xaa/0x1d2<br /> [ 4070.575456] do_syscall_64+0x35/0x80<br /> [ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 4070.575467] RIP: 0033:0x7f1ed5c10397<br /> [ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48<br /> [ 4070.575478] RSP: 002b:00007ffd65c8d7a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> [ 4070.575484] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f1ed5c10397<br /> [ 4070.575488] RDX: 00007ffd65c8d7c0 RSI: 0000000040106476 RDI: 0000000000000006<br /> [ 4070.575492] RBP: 00005620972f9c60 R08: 000000000000000a R09: 0000000000000005<br /> [ 4070.575496] R10: 000000000000000d R11: 0000000000000246 R12: 000000000000000a<br /> [ 4070.575500] R13: 000000000000000d R14: 0000000000000000 R15: 00007ffd65c8d7c0<br /> [ 4070.575505] <br /> [ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) i2c_smbus<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: mockup: fix NULL pointer dereference when removing debugfs<br /> <br /> We now remove the device&amp;#39;s debugfs entries when unbinding the driver.<br /> This now causes a NULL-pointer dereference on module exit because the<br /> platform devices are unregistered *after* the global debugfs directory<br /> has been recursively removed. Fix it by unregistering the devices first.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsdax: Fix infinite loop in dax_iomap_rw()<br /> <br /> I got an infinite loop and a WARNING report when executing a tail command<br /> in virtiofs.<br /> <br /> WARNING: CPU: 10 PID: 964 at fs/iomap/iter.c:34 iomap_iter+0x3a2/0x3d0<br /> Modules linked in:<br /> CPU: 10 PID: 964 Comm: tail Not tainted 5.19.0-rc7<br /> Call Trace:<br /> <br /> dax_iomap_rw+0xea/0x620<br /> ? __this_cpu_preempt_check+0x13/0x20<br /> fuse_dax_read_iter+0x47/0x80<br /> fuse_file_read_iter+0xae/0xd0<br /> new_sync_read+0xfe/0x180<br /> ? 0xffffffff81000000<br /> vfs_read+0x14d/0x1a0<br /> ksys_read+0x6d/0xf0<br /> __x64_sys_read+0x1a/0x20<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The tail command will call read() with a count of 0. In this case,<br /> iomap_iter() will report this WARNING, and always return 1 which casuing<br /> the infinite loop in dax_iomap_rw().<br /> <br /> Fixing by checking count whether is 0 in dax_iomap_rw().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth &gt; 0<br /> <br /> When walking through an inode extents, the ext4_ext_binsearch_idx() function<br /> assumes that the extent header has been previously validated. However, there<br /> are no checks that verify that the number of entries (eh-&gt;eh_entries) is<br /> non-zero when depth is &gt; 0. And this will lead to problems because the<br /> EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this:<br /> <br /> [ 135.245946] ------------[ cut here ]------------<br /> [ 135.247579] kernel BUG at fs/ext4/extents.c:2258!<br /> [ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP<br /> [ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4<br /> [ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014<br /> [ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0<br /> [ 135.256475] Code:<br /> [ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246<br /> [ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023<br /> [ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c<br /> [ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c<br /> [ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024<br /> [ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000<br /> [ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000<br /> [ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0<br /> [ 135.277952] Call Trace:<br /> [ 135.278635] <br /> [ 135.279247] ? preempt_count_add+0x6d/0xa0<br /> [ 135.280358] ? percpu_counter_add_batch+0x55/0xb0<br /> [ 135.281612] ? _raw_read_unlock+0x18/0x30<br /> [ 135.282704] ext4_map_blocks+0x294/0x5a0<br /> [ 135.283745] ? xa_load+0x6f/0xa0<br /> [ 135.284562] ext4_mpage_readpages+0x3d6/0x770<br /> [ 135.285646] read_pages+0x67/0x1d0<br /> [ 135.286492] ? folio_add_lru+0x51/0x80<br /> [ 135.287441] page_cache_ra_unbounded+0x124/0x170<br /> [ 135.288510] filemap_get_pages+0x23d/0x5a0<br /> [ 135.289457] ? path_openat+0xa72/0xdd0<br /> [ 135.290332] filemap_read+0xbf/0x300<br /> [ 135.291158] ? _raw_spin_lock_irqsave+0x17/0x40<br /> [ 135.292192] new_sync_read+0x103/0x170<br /> [ 135.293014] vfs_read+0x15d/0x180<br /> [ 135.293745] ksys_read+0xa1/0xe0<br /> [ 135.294461] do_syscall_64+0x3c/0x80<br /> [ 135.295284] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> This patch simply adds an extra check in __ext4_ext_check(), verifying that<br /> eh_entries is not 0 when eh_depth is &gt; 0.