Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create<br /> <br /> Commit b035f5a6d852 ("mm: slab: reduce the kmalloc() minimum alignment<br /> if DMA bouncing possible") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64.<br /> However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16.<br /> This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16],<br /> resulting in kmem_buckets_create() attempting to create a kmem_cache for<br /> size 16 twice. This duplication triggers warnings on boot:<br /> <br /> [ 2.325108] ------------[ cut here ]------------<br /> [ 2.325135] kmem_cache of name &amp;#39;memdup_user-16&amp;#39; already exists<br /> [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.327957] Modules linked in:<br /> [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12<br /> [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024<br /> [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.328942] sp : ffff800083d6fc50<br /> [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598<br /> [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000<br /> [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388<br /> [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030<br /> [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120<br /> [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000<br /> [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 2.329291] Call trace:<br /> [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.329499] kmem_buckets_create+0xfc/0x320<br /> [ 2.329526] init_user_buckets+0x34/0x78<br /> [ 2.329540] do_one_initcall+0x64/0x3c8<br /> [ 2.329550] kernel_init_freeable+0x26c/0x578<br /> [ 2.329562] kernel_init+0x3c/0x258<br /> [ 2.329574] ret_from_fork+0x10/0x20<br /> [ 2.329698] ---[ end trace 0000000000000000 ]---<br /> <br /> [ 2.403704] ------------[ cut here ]------------<br /> [ 2.404716] kmem_cache of name &amp;#39;msg_msg-16&amp;#39; already exists<br /> [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.404842] Modules linked in:<br /> [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12<br /> [ 2.405026] Tainted: [W]=WARN<br /> [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024<br /> [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0<br /> [ 2.405111] sp : ffff800083d6fc50<br /> [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598<br /> [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000<br /> [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388<br /> [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030<br /> [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120<br /> [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000<br /> [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 2.405287] Call trace:<br /> [ 2<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix idpf_vc_core_init error path<br /> <br /> In an event where the platform running the device control plane<br /> is rebooted, reset is detected on the driver. It releases<br /> all the resources and waits for the reset to complete. Once the<br /> reset is done, it tries to build the resources back. At this<br /> time if the device control plane is not yet started, then<br /> the driver timeouts on the virtchnl message and retries to<br /> establish the mailbox again.<br /> <br /> In the retry flow, mailbox is deinitialized but the mailbox<br /> workqueue is still alive and polling for the mailbox message.<br /> This results in accessing the released control queue leading to<br /> null-ptr-deref. Fix it by unrolling the work queue cancellation<br /> and mailbox deinitialization in the reverse order which they got<br /> initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvbdev: prevent the risk of out of memory access<br /> <br /> The dvbdev contains a static variable used to store dvb minors.<br /> <br /> The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set<br /> or not. When not set, dvb_register_device() won&amp;#39;t check for<br /> boundaries, as it will rely that a previous call to<br /> dvb_register_adapter() would already be enforcing it.<br /> <br /> On a similar way, dvb_device_open() uses the assumption<br /> that the register functions already did the needed checks.<br /> <br /> This can be fragile if some device ends using different<br /> calls. This also generate warnings on static check analysers<br /> like Coverity.<br /> <br /> So, add explicit guards to prevent potential risk of OOM issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Never decrement pending_async_copies on error<br /> <br /> The error flow in nfsd4_copy() calls cleanup_async_copy(), which<br /> already decrements nn-&gt;pending_async_copies.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Be stricter about IO mapping flags<br /> <br /> The current panthor_device_mmap_io() implementation has two issues:<br /> <br /> 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET,<br /> panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear<br /> VM_MAYWRITE. That means userspace can use mprotect() to make the mapping<br /> writable later on. This is a classic Linux driver gotcha.<br /> I don&amp;#39;t think this actually has any impact in practice:<br /> When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and<br /> when the GPU is not powered, the dummy_latest_flush page provided by the<br /> driver is deliberately designed to not do any flushes, so the only thing<br /> writing to the dummy_latest_flush could achieve would be to make *more*<br /> flushes happen.<br /> <br /> 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are<br /> mappings without the VM_SHARED flag).<br /> MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has<br /> copy-on-write semantics, which for VM_PFNMAP are semi-supported but<br /> fairly cursed.<br /> In particular, in such a mapping, the driver can only install PTEs<br /> during mmap() by calling remap_pfn_range() (because remap_pfn_range()<br /> wants to **store the physical address of the mapped physical memory into<br /> the vm_pgoff of the VMA**); installing PTEs later on with a fault<br /> handler (as panthor does) is not supported in private mappings, and so<br /> if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when<br /> it hits a BUG() check.<br /> <br /> Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID<br /> doesn&amp;#39;t make sense) and requiring VM_SHARED (copy-on-write semantics for<br /> the FLUSH_ID don&amp;#39;t make sense).<br /> <br /> Reproducers for both scenarios are in the notes of my patch on the mailing<br /> list; I tested that these bugs exist on a Rock 5B machine.<br /> <br /> Note that I only compile-tested the patch, I haven&amp;#39;t tested it; I don&amp;#39;t<br /> have a working kernel build setup for the test machine yet. Please test it<br /> before applying it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mgb4: protect driver against spectre<br /> <br /> Frequency range is set from sysfs via frequency_range_store(),<br /> being vulnerable to spectre, as reported by smatch:<br /> <br /> drivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue &amp;#39;cmt_vals_in&amp;#39; [r]<br /> drivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. &amp;#39;reg_set&amp;#39;<br /> <br /> Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: qcom: scm: fix a NULL-pointer dereference<br /> <br /> Some SCM calls can be invoked with __scm being NULL (the driver may not<br /> have been and will not be probed as there&amp;#39;s no SCM entry in device-tree).<br /> Make sure we don&amp;#39;t dereference a NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()<br /> <br /> The scmi_dev-&gt;name is released prematurely in __scmi_device_destroy(),<br /> which causes slab-use-after-free when accessing scmi_dev-&gt;name in<br /> scmi_bus_notifier(). So move the release of scmi_dev-&gt;name to<br /> scmi_device_release() to avoid slab-use-after-free.<br /> <br /> | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec<br /> | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1<br /> |<br /> | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1<br /> | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT)<br /> | Call trace:<br /> | dump_backtrace+0x94/0x114<br /> | show_stack+0x18/0x24<br /> | dump_stack_lvl+0x48/0x60<br /> | print_report+0xf4/0x5b0<br /> | kasan_report+0xa4/0xec<br /> | __asan_report_load1_noabort+0x20/0x2c<br /> | strncmp+0xe4/0xec<br /> | scmi_bus_notifier+0x5c/0x54c<br /> | notifier_call_chain+0xb4/0x31c<br /> | blocking_notifier_call_chain+0x68/0x9c<br /> | bus_notify+0x54/0x78<br /> | device_del+0x1bc/0x840<br /> | device_unregister+0x20/0xb4<br /> | __scmi_device_destroy+0xac/0x280<br /> | scmi_device_destroy+0x94/0xd0<br /> | scmi_chan_setup+0x524/0x750<br /> | scmi_probe+0x7fc/0x1508<br /> | platform_probe+0xc4/0x19c<br /> | really_probe+0x32c/0x99c<br /> | __driver_probe_device+0x15c/0x3c4<br /> | driver_probe_device+0x5c/0x170<br /> | __driver_attach+0x1c8/0x440<br /> | bus_for_each_dev+0xf4/0x178<br /> | driver_attach+0x3c/0x58<br /> | bus_add_driver+0x234/0x4d4<br /> | driver_register+0xf4/0x3c0<br /> | __platform_driver_register+0x60/0x88<br /> | scmi_driver_init+0xb0/0x104<br /> | do_one_initcall+0xb4/0x664<br /> | kernel_init_freeable+0x3c8/0x894<br /> | kernel_init+0x24/0x1e8<br /> | ret_from_fork+0x10/0x20<br /> |<br /> | Allocated by task 1:<br /> | kasan_save_stack+0x2c/0x54<br /> | kasan_set_track+0x2c/0x40<br /> | kasan_save_alloc_info+0x24/0x34<br /> | __kasan_kmalloc+0xa0/0xb8<br /> | __kmalloc_node_track_caller+0x6c/0x104<br /> | kstrdup+0x48/0x84<br /> | kstrdup_const+0x34/0x40<br /> | __scmi_device_create.part.0+0x8c/0x408<br /> | scmi_device_create+0x104/0x370<br /> | scmi_chan_setup+0x2a0/0x750<br /> | scmi_probe+0x7fc/0x1508<br /> | platform_probe+0xc4/0x19c<br /> | really_probe+0x32c/0x99c<br /> | __driver_probe_device+0x15c/0x3c4<br /> | driver_probe_device+0x5c/0x170<br /> | __driver_attach+0x1c8/0x440<br /> | bus_for_each_dev+0xf4/0x178<br /> | driver_attach+0x3c/0x58<br /> | bus_add_driver+0x234/0x4d4<br /> | driver_register+0xf4/0x3c0<br /> | __platform_driver_register+0x60/0x88<br /> | scmi_driver_init+0xb0/0x104<br /> | do_one_initcall+0xb4/0x664<br /> | kernel_init_freeable+0x3c8/0x894<br /> | kernel_init+0x24/0x1e8<br /> | ret_from_fork+0x10/0x20<br /> |<br /> | Freed by task 1:<br /> | kasan_save_stack+0x2c/0x54<br /> | kasan_set_track+0x2c/0x40<br /> | kasan_save_free_info+0x38/0x5c<br /> | __kasan_slab_free+0xe8/0x164<br /> | __kmem_cache_free+0x11c/0x230<br /> | kfree+0x70/0x130<br /> | kfree_const+0x20/0x40<br /> | __scmi_device_destroy+0x70/0x280<br /> | scmi_device_destroy+0x94/0xd0<br /> | scmi_chan_setup+0x524/0x750<br /> | scmi_probe+0x7fc/0x1508<br /> | platform_probe+0xc4/0x19c<br /> | really_probe+0x32c/0x99c<br /> | __driver_probe_device+0x15c/0x3c4<br /> | driver_probe_device+0x5c/0x170<br /> | __driver_attach+0x1c8/0x440<br /> | bus_for_each_dev+0xf4/0x178<br /> | driver_attach+0x3c/0x58<br /> | bus_add_driver+0x234/0x4d4<br /> | driver_register+0xf4/0x3c0<br /> | __platform_driver_register+0x60/0x88<br /> | scmi_driver_init+0xb0/0x104<br /> | do_one_initcall+0xb4/0x664<br /> | kernel_init_freeable+0x3c8/0x894<br /> | kernel_init+0x24/0x1e8<br /> | ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Start the RTC update work later<br /> <br /> The RTC update work involves runtime resuming the UFS controller. Hence,<br /> only start the RTC update work after runtime power management in the UFS<br /> driver has been fully initialized. This patch fixes the following kernel<br /> crash:<br /> <br /> Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP<br /> Workqueue: events ufshcd_rtc_work<br /> Call trace:<br /> _raw_spin_lock_irqsave+0x34/0x8c (P)<br /> pm_runtime_get_if_active+0x24/0x9c (L)<br /> pm_runtime_get_if_active+0x24/0x9c<br /> ufshcd_rtc_work+0x138/0x1b4<br /> process_one_work+0x148/0x288<br /> worker_thread+0x2cc/0x3d4<br /> kthread+0x110/0x114<br /> ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability<br /> <br /> Sometimes during hotplug scenario or suspend/resume scenario encoder is<br /> not always initialized when intel_hdcp_get_capability add<br /> a check to avoid kernel null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/hdcp: Add encoder check in hdcp2_get_capability<br /> <br /> Add encoder check in intel_hdcp2_get_capability to avoid<br /> null pointer error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported<br /> <br /> acpi_evaluate_object() may return AE_NOT_FOUND (failure), which<br /> would result in dereferencing buffer.pointer (obj) while being NULL.<br /> <br /> Although this case may be unrealistic for the current code, it is<br /> still better to protect against possible bugs.<br /> <br /> Bail out also when status is AE_NOT_FOUND.<br /> <br /> This fixes 1 FORWARD_NULL issue reported by Coverity<br /> Report: CID 1600951: Null pointer dereferences (FORWARD_NULL)<br /> <br /> (cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1)