Vulnerabilities

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---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbe: fix pci device refcount leak<br /> <br /> As the comment of pci_get_domain_bus_and_slot() says, it<br /> returns a PCI device with refcount incremented, when finish<br /> using it, the caller must decrement the reference count by<br /> calling pci_dev_put().<br /> <br /> In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),<br /> pci_dev_put() is called to avoid leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/mm: fix incorrect file_map_count for invalid pmd<br /> <br /> The page table check trigger BUG_ON() unexpectedly when split hugepage:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at mm/page_table_check.c:119!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> Dumping ftrace buffer:<br /> (ftrace buffer empty)<br /> Modules linked in:<br /> CPU: 7 PID: 210 Comm: transhuge-stres Not tainted 6.1.0-rc3+ #748<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : page_table_check_set.isra.0+0x398/0x468<br /> lr : page_table_check_set.isra.0+0x1c0/0x468<br /> [...]<br /> Call trace:<br /> page_table_check_set.isra.0+0x398/0x468<br /> __page_table_check_pte_set+0x160/0x1c0<br /> __split_huge_pmd_locked+0x900/0x1648<br /> __split_huge_pmd+0x28c/0x3b8<br /> unmap_page_range+0x428/0x858<br /> unmap_single_vma+0xf4/0x1c8<br /> zap_page_range+0x2b0/0x410<br /> madvise_vma_behavior+0xc44/0xe78<br /> do_madvise+0x280/0x698<br /> __arm64_sys_madvise+0x90/0xe8<br /> invoke_syscall.constprop.0+0xdc/0x1d8<br /> do_el0_svc+0xf4/0x3f8<br /> el0_svc+0x58/0x120<br /> el0t_64_sync_handler+0xb8/0xc0<br /> el0t_64_sync+0x19c/0x1a0<br /> [...]<br /> <br /> On arm64, pmd_leaf() will return true even if the pmd is invalid due to<br /> pmd_present_invalid() check. So in pmdp_invalidate() the file_map_count<br /> will not only decrease once but also increase once. Then in set_pte_at(),<br /> the file_map_count increase again, and so trigger BUG_ON() unexpectedly.<br /> <br /> Add !pmd_present_invalid() check in pmd_user_accessible_page() to fix the<br /> problem.