Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/iova: Fix alloc iova overflows issue<br /> <br /> In __alloc_and_insert_iova_range, there is an issue that retry_pfn<br /> overflows. The value of iovad-&gt;anchor.pfn_hi is ~0UL, then when<br /> iovad-&gt;cached_node is iovad-&gt;anchor, curr_iova-&gt;pfn_hi + 1 will<br /> overflow. As a result, if the retry logic is executed, low_pfn is<br /> updated to 0, and then new_pfn cached_node is assigned as iovad-&gt;anchor. For<br /> example, the iova domain size is 10M, start_pfn is 0x1_F000_0000,<br /> and the iova size allocated for the first time is 11M. The<br /> following is the log information, new-&gt;pfn_lo is smaller than<br /> iovad-&gt;cached_node.<br /> <br /> Example log as follows:<br /> [ 223.798112][T1705487] sh: [name:iova&amp;]__alloc_and_insert_iova_range<br /> start_pfn:0x1f0000,retry_pfn:0x0,size:0xb00,limit_pfn:0x1f0a00<br /> [ 223.799590][T1705487] sh: [name:iova&amp;]__alloc_and_insert_iova_range<br /> success start_pfn:0x1f0000,new-&gt;pfn_lo:0x1efe00,new-&gt;pfn_hi:0x1f08ff<br /> <br /> 2. The node with the largest iova-&gt;pfn_lo value in the iova domain<br /> is deleted, iovad-&gt;cached_node will be updated to iovad-&gt;anchor,<br /> and then the alloc iova size exceeds the maximum iova size that can<br /> be allocated in the domain.<br /> <br /> After judging that retry_pfn is less than limit_pfn, call retry_pfn+1<br /> to fix the overflow issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: another fix for the headless Adreno GPU<br /> <br /> Fix another oops reproducible when rebooting the board with the Adreno<br /> GPU working in the headless mode (e.g. iMX platforms).<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read<br /> [00000000] *pgd=74936831, *pte=00000000, *ppte=00000000<br /> Internal error: Oops: 17 [#1] ARM<br /> CPU: 0 PID: 51 Comm: reboot Not tainted 6.2.0-rc1-dirty #11<br /> Hardware name: Freescale i.MX53 (Device Tree Support)<br /> PC is at msm_atomic_commit_tail+0x50/0x970<br /> LR is at commit_tail+0x9c/0x188<br /> pc : [] lr : [] psr: 600e0013<br /> sp : e0851d30 ip : ee4eb7eb fp : 00090acc<br /> r10: 00000058 r9 : c2193014 r8 : c4310000<br /> r7 : c4759380 r6 : 07bef61d r5 : 00000000 r4 : 00000000<br /> r3 : c44cc440 r2 : 00000000 r1 : 00000000 r0 : 00000000<br /> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none<br /> Control: 10c5387d Table: 74910019 DAC: 00000051<br /> Register r0 information: NULL pointer<br /> Register r1 information: NULL pointer<br /> Register r2 information: NULL pointer<br /> Register r3 information: slab kmalloc-1k start c44cc400 pointer offset 64 size 1024<br /> Register r4 information: NULL pointer<br /> Register r5 information: NULL pointer<br /> Register r6 information: non-paged memory<br /> Register r7 information: slab kmalloc-128 start c4759380 pointer offset 0 size 128<br /> Register r8 information: slab kmalloc-2k start c4310000 pointer offset 0 size 2048<br /> Register r9 information: non-slab/vmalloc memory<br /> Register r10 information: non-paged memory<br /> Register r11 information: non-paged memory<br /> Register r12 information: non-paged memory<br /> Process reboot (pid: 51, stack limit = 0xc80046d9)<br /> Stack: (0xe0851d30 to 0xe0852000)<br /> 1d20: c4759380 fbd77200 000005ff 002b9c70<br /> 1d40: c4759380 c4759380 00000000 07bef61d 00000600 c0d6fe7c c2193014 00000058<br /> 1d60: 00090acc c067a214 00000000 c4759380 c4310000 00000000 c44cc854 c067a89c<br /> 1d80: 00000000 00000000 00000000 c4310468 00000000 c4759380 c4310000 c4310468<br /> 1da0: c4310470 c0643258 c4759380 00000000 00000000 c0c4ee24 00000000 c44cc810<br /> 1dc0: 00000000 c0c4ee24 00000000 c44cc810 00000000 0347d2a8 e0851e00 e0851e00<br /> 1de0: c4759380 c067ad20 c4310000 00000000 c44cc810 c27f8718 c44cc854 c067adb8<br /> 1e00: c4933000 00000002 00000001 00000000 00000000 c2130850 00000000 c2130854<br /> 1e20: c25fc488 00000000 c0ff162c 00000000 00000001 00000002 00000000 00000000<br /> 1e40: c43102c0 c43102c0 00000000 0347d2a8 c44cc810 c44cc814 c2133da8 c06d1a60<br /> 1e60: 00000000 00000000 00079028 c2012f24 fee1dead c4933000 00000058 c01431e4<br /> 1e80: 01234567 c0143a20 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1ea0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1f40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1f80: 00000000 00000000 00000000 0347d2a8 00000002 00000004 00000078 00000058<br /> 1fa0: c010028c c0100060 00000002 00000004 fee1dead 28121969 01234567 00079028<br /> 1fc0: 00000002 00000004 00000078 00000058 0002fdc5 00000000 00000000 00090acc<br /> 1fe0: 00000058 becc9c64 b6e97e05 b6e0e5f6 600e0030 fee1dead 00000000 00000000<br /> msm_atomic_commit_tail from commit_tail+0x9c/0x188<br /> commit_tail from drm_atomic_helper_commit+0x160/0x188<br /> drm_atomic_helper_commit from drm_atomic_commit+0xac/0xe0<br /> drm_atomic_commit from drm_atomic_helper_disable_all+0x1b0/0x1c0<br /> drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x88/0x140<br /> drm_atomic_helper_shutdown from device_shutdown+0x16c/0x240<br /> device_shutdown from kernel_restart+0x38/0x90<br /> kernel_restart from __do_sys_reboot+0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix potential memory leak in ice_gnss_tty_write()<br /> <br /> The ice_gnss_tty_write() return directly if the write_buf alloc failed,<br /> leaking the cmd_buf.<br /> <br /> Fix by free cmd_buf if write_buf alloc failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Add check for kzalloc<br /> <br /> Add the check for the return value of kzalloc in order to avoid<br /> NULL pointer dereference.<br /> Moreover, use the goto-label to share the clean code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Remove rcu locks from user resources<br /> <br /> User resource lookups used rcu to avoid two extra atomics. Unfortunately<br /> the rcu paths were buggy and it was easy to make the driver crash by<br /> submitting command buffers from two different threads. Because the<br /> lookups never show up in performance profiles replace them with a<br /> regular spin lock which fixes the races in accesses to those shared<br /> resources.<br /> <br /> Fixes kernel oops&amp;#39;es in IGT&amp;#39;s vmwgfx execution_buffer stress test and<br /> seen crashes with apps using shared resources.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: Fix memory leak in msm_mdss_parse_data_bus_icc_path<br /> <br /> of_icc_get() alloc resources for path1, we should release it when not<br /> need anymore. Early return when IS_ERR_OR_NULL(path0) may leak path1.<br /> Defer getting path1 to fix this.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/514264/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: sof-nau8825: fix module alias overflow<br /> <br /> The maximum name length for a platform_device_id entry is 20 characters<br /> including the trailing NUL byte. The sof_nau8825.c file exceeds that,<br /> which causes an obscure error message:<br /> <br /> sound/soc/intel/boards/snd-soc-sof_nau8825.mod.c:35:45: error: illegal character encoding in string literal [-Werror,-Winvalid-source-encoding]<br /> MODULE_ALIAS("platform:adl_max98373_nau8825");<br /> ^~~~<br /> include/linux/module.h:168:49: note: expanded from macro &amp;#39;MODULE_ALIAS&amp;#39;<br /> ^~~~~~<br /> include/linux/module.h:165:56: note: expanded from macro &amp;#39;MODULE_INFO&amp;#39;<br /> ^~~~<br /> include/linux/moduleparam.h:26:47: note: expanded from macro &amp;#39;__MODULE_INFO&amp;#39;<br /> = __MODULE_INFO_PREFIX __stringify(tag) "=" info<br /> <br /> I could not figure out how to make the module handling robust enough<br /> to handle this better, but as a quick fix, using slightly shorter<br /> names that are still unique avoids the build issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM<br /> <br /> storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(),<br /> which in a confidential VM allocates swiotlb bounce buffers. If the I/O<br /> submission fails in storvsc_do_io(), the I/O is typically retried by higher<br /> level code, but the bounce buffer memory is never freed. The mostly like<br /> cause of I/O submission failure is a full VMBus channel ring buffer, which<br /> is not uncommon under high I/O loads. Eventually enough bounce buffer<br /> memory leaks that the confidential VM can&amp;#39;t do any I/O. The same problem<br /> can arise in a non-confidential VM with kernel boot parameter<br /> swiotlb=force.<br /> <br /> Fix this by doing scsi_dma_unmap() in the case of an I/O submission<br /> error, which frees the bounce buffer memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: da9211: Use irq handler when ready<br /> <br /> If the system does not come from reset (like when it is kexec()), the<br /> regulator might have an IRQ waiting for us.<br /> <br /> If we enable the IRQ handler before its structures are ready, we crash.<br /> <br /> This patch fixes:<br /> <br /> [ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078<br /> [ 1.316096] Call trace:<br /> [ 1.316101] blocking_notifier_call_chain+0x20/0xa8<br /> [ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests<br /> [ 1.327823] regulator_notifier_call_chain+0x1c/0x2c<br /> [ 1.327825] da9211_irq_handler+0x68/0xf8<br /> [ 1.327829] irq_thread+0x11c/0x234<br /> [ 1.327833] kthread+0x13c/0x154

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/core: Fix use-after-free bug in dup_user_cpus_ptr()<br /> <br /> Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be<br /> restricted on asymmetric systems"), the setting and clearing of<br /> user_cpus_ptr are done under pi_lock for arm64 architecture. However,<br /> dup_user_cpus_ptr() accesses user_cpus_ptr without any lock<br /> protection. Since sched_setaffinity() can be invoked from another<br /> process, the process being modified may be undergoing fork() at<br /> the same time. When racing with the clearing of user_cpus_ptr in<br /> __set_cpus_allowed_ptr_locked(), it can lead to user-after-free and<br /> possibly double-free in arm64 kernel.<br /> <br /> Commit 8f9ea86fdf99 ("sched: Always preserve the user requested<br /> cpumask") fixes this problem as user_cpus_ptr, once set, will never<br /> be cleared in a task&amp;#39;s lifetime. However, this bug was re-introduced<br /> in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in<br /> do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in<br /> do_set_cpus_allowed(). This time, it will affect all arches.<br /> <br /> Fix this bug by always clearing the user_cpus_ptr of the newly<br /> cloned/forked task before the copying process starts and check the<br /> user_cpus_ptr state of the source task under pi_lock.<br /> <br /> Note to stable, this patch won&amp;#39;t be applicable to stable releases.<br /> Just copy the new dup_user_cpus_ptr() function over.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu-v3: Don&amp;#39;t unregister on shutdown<br /> <br /> Similar to SMMUv2, this driver calls iommu_device_unregister() from the<br /> shutdown path, which removes the IOMMU groups with no coordination<br /> whatsoever with their users - shutdown methods are optional in device<br /> drivers. This can lead to NULL pointer dereferences in those drivers&amp;#39;<br /> DMA API calls, or worse.<br /> <br /> Instead of calling the full arm_smmu_device_remove() from<br /> arm_smmu_device_shutdown(), let&amp;#39;s pick only the relevant function call -<br /> arm_smmu_device_disable() - more or less the reverse of<br /> arm_smmu_device_reset() - and call just that from the shutdown path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu: Don&amp;#39;t unregister on shutdown<br /> <br /> Michael Walle says he noticed the following stack trace while performing<br /> a shutdown with "reboot -f". He suggests he got "lucky" and just hit the<br /> correct spot for the reboot while there was a packet transmission in<br /> flight.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098<br /> CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 6.1.0-rc5-00088-gf3600ff8e322 #1930<br /> Hardware name: Kontron KBox A-230-LS (DT)<br /> pc : iommu_get_dma_domain+0x14/0x20<br /> lr : iommu_dma_map_page+0x9c/0x254<br /> Call trace:<br /> iommu_get_dma_domain+0x14/0x20<br /> dma_map_page_attrs+0x1ec/0x250<br /> enetc_start_xmit+0x14c/0x10b0<br /> enetc_xmit+0x60/0xdc<br /> dev_hard_start_xmit+0xb8/0x210<br /> sch_direct_xmit+0x11c/0x420<br /> __dev_queue_xmit+0x354/0xb20<br /> ip6_finish_output2+0x280/0x5b0<br /> __ip6_finish_output+0x15c/0x270<br /> ip6_output+0x78/0x15c<br /> NF_HOOK.constprop.0+0x50/0xd0<br /> mld_sendpack+0x1bc/0x320<br /> mld_ifc_work+0x1d8/0x4dc<br /> process_one_work+0x1e8/0x460<br /> worker_thread+0x178/0x534<br /> kthread+0xe0/0xe4<br /> ret_from_fork+0x10/0x20<br /> Code: d503201f f9416800 d503233f d50323bf (f9404c00)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception in interrupt<br /> <br /> This appears to be reproducible when the board has a fixed IP address,<br /> is ping flooded from another host, and "reboot -f" is used.<br /> <br /> The following is one more manifestation of the issue:<br /> <br /> $ reboot -f<br /> kvm: exiting hardware virtualization<br /> cfg80211: failed to load regulatory.db<br /> arm-smmu 5000000.iommu: disabling translation<br /> sdhci-esdhc 2140000.mmc: Removing from iommu group 11<br /> sdhci-esdhc 2150000.mmc: Removing from iommu group 12<br /> fsl-edma 22c0000.dma-controller: Removing from iommu group 17<br /> dwc3 3100000.usb: Removing from iommu group 9<br /> dwc3 3110000.usb: Removing from iommu group 10<br /> ahci-qoriq 3200000.sata: Removing from iommu group 2<br /> fsl-qdma 8380000.dma-controller: Removing from iommu group 20<br /> platform f080000.display: Removing from iommu group 0<br /> etnaviv-gpu f0c0000.gpu: Removing from iommu group 1<br /> etnaviv etnaviv: Removing from iommu group 1<br /> caam_jr 8010000.jr: Removing from iommu group 13<br /> caam_jr 8020000.jr: Removing from iommu group 14<br /> caam_jr 8030000.jr: Removing from iommu group 15<br /> caam_jr 8040000.jr: Removing from iommu group 16<br /> fsl_enetc 0000:00:00.0: Removing from iommu group 4<br /> arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications<br /> arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000429, GFSYNR2 0x00000000<br /> fsl_enetc 0000:00:00.1: Removing from iommu group 5<br /> arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications<br /> arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000002, GFSYNR1 0x00000429, GFSYNR2 0x00000000<br /> arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications<br /> arm-smmu 5000000.iommu: GFSR 0x80000002, GFSYNR0 0x00000000, GFSYNR1 0x00000429, GFSYNR2 0x00000000<br /> fsl_enetc 0000:00:00.2: Removing from iommu group 6<br /> fsl_enetc_mdio 0000:00:00.3: Removing from iommu group 8<br /> mscc_felix 0000:00:00.5: Removing from iommu group 3<br /> fsl_enetc 0000:00:00.6: Removing from iommu group 7<br /> pcieport 0001:00:00.0: Removing from iommu group 18<br /> arm-smmu 5000000.iommu: Blocked unknown Stream ID 0x429; boot with "arm-smmu.disable_bypass=0" to allow, but this may have security implications<br /> arm-smmu 5000000.iommu: GFSR 0x00000002, GFSYNR0 0x00000000, GFSYNR1 0x00000429, GFSYNR2 0x00000000<br /> pcieport 0002:00:00.0: Removing from iommu group 19<br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8<br /> pc : iommu_get_dma_domain+0x14/0x20<br /> lr : iommu_dma_unmap_page+0x38/0xe0<br /> Call trace:<br /> iommu_get_dma_domain+0x14/0x20<br /> dma_unmap_page_attrs+0x38/0x1d0<br /> en<br /> ---truncated---