Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: sof-common: Add NULL check for normal_link string<br /> <br /> It&amp;#39;s not granted that all entries of struct sof_conn_stream declare<br /> a `normal_link` (a non-SOF, direct link) string, and this is the case<br /> for SoCs that support only SOF paths (hence do not support both direct<br /> and SOF usecases).<br /> <br /> For example, in the case of MT8188 there is no normal_link string in<br /> any of the sof_conn_stream entries and there will be more drivers<br /> doing that in the future.<br /> <br /> To avoid possible NULL pointer KPs, add a NULL check for `normal_link`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Use device rbtree in iopf reporting path<br /> <br /> The existing I/O page fault handler currently locates the PCI device by<br /> calling pci_get_domain_bus_and_slot(). This function searches the list<br /> of all PCI devices until the desired device is found. To improve lookup<br /> efficiency, replace it with device_rbtree_find() to search the device<br /> within the probed device rbtree.<br /> <br /> The I/O page fault is initiated by the device, which does not have any<br /> synchronization mechanism with the software to ensure that the device<br /> stays in the probed device tree. Theoretically, a device could be released<br /> by the IOMMU subsystem after device_rbtree_find() and before<br /> iopf_get_dev_fault_param(), which would cause a use-after-free problem.<br /> <br /> Add a mutex to synchronize the I/O page fault reporting path and the IOMMU<br /> release device path. This lock doesn&amp;#39;t introduce any performance overhead,<br /> as the conflict between I/O page fault reporting and device releasing is<br /> very rare.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: compress: fix reserve_cblocks counting error when out of space<br /> <br /> When a file only needs one direct_node, performing the following<br /> operations will cause the file to be unrepairable:<br /> <br /> unisoc # ./f2fs_io compress test.apk<br /> unisoc #df -h | grep dm-48<br /> /dev/block/dm-48 112G 112G 1.2M 100% /data<br /> <br /> unisoc # ./f2fs_io release_cblocks test.apk<br /> 924<br /> unisoc # df -h | grep dm-48<br /> /dev/block/dm-48 112G 112G 4.8M 100% /data<br /> <br /> unisoc # dd if=/dev/random of=file4 bs=1M count=3<br /> 3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s<br /> unisoc # df -h | grep dm-48<br /> /dev/block/dm-48 112G 112G 1.8M 100% /data<br /> <br /> unisoc # ./f2fs_io reserve_cblocks test.apk<br /> F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device<br /> <br /> adb reboot<br /> unisoc # df -h | grep dm-48<br /> /dev/block/dm-48 112G 112G 11M 100% /data<br /> unisoc # ./f2fs_io reserve_cblocks test.apk<br /> 0<br /> <br /> This is because the file has only one direct_node. After returning<br /> to -ENOSPC, reserved_blocks += ret will not be executed. As a result,<br /> the reserved_blocks at this time is still 0, which is not the real<br /> number of reserved blocks. Therefore, fsck cannot be set to repair<br /> the file.<br /> <br /> After this patch, the fsck flag will be set to fix this problem.<br /> <br /> unisoc # df -h | grep dm-48<br /> /dev/block/dm-48 112G 112G 1.8M 100% /data<br /> unisoc # ./f2fs_io reserve_cblocks test.apk<br /> F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device<br /> <br /> adb reboot then fsck will be executed<br /> unisoc # df -h | grep dm-48<br /> /dev/block/dm-48 112G 112G 11M 100% /data<br /> unisoc # ./f2fs_io reserve_cblocks test.apk<br /> 924

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: dbg-tlv: ensure NUL termination<br /> <br /> The iwl_fw_ini_debug_info_tlv is used as a string, so we must<br /> ensure the string is terminated correctly before using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: zswap: fix shrinker NULL crash with cgroup_disable=memory<br /> <br /> Christian reports a NULL deref in zswap that he bisected down to the zswap<br /> shrinker. The issue also cropped up in the bug trackers of libguestfs [1]<br /> and the Red Hat bugzilla [2].<br /> <br /> The problem is that when memcg is disabled with the boot time flag, the<br /> zswap shrinker might get called with sc-&gt;memcg == NULL. This is okay in<br /> many places, like the lruvec operations. But it crashes in<br /> memcg_page_state() - which is only used due to the non-node accounting of<br /> cgroup&amp;#39;s the zswap memory to begin with.<br /> <br /> Nhat spotted that the memcg can be NULL in the memcg-disabled case, and I<br /> was then able to reproduce the crash locally as well.<br /> <br /> [1] https://github.com/libguestfs/libguestfs/issues/139<br /> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2275252

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gic-v3-its: Prevent double free on error<br /> <br /> The error handling path in its_vpe_irq_domain_alloc() causes a double free<br /> when its_vpe_init() fails after successfully allocating at least one<br /> interrupt. This happens because its_vpe_irq_domain_free() frees the<br /> interrupts along with the area bitmap and the vprop_page and<br /> its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the<br /> vprop_page again.<br /> <br /> Fix this by unconditionally invoking its_vpe_irq_domain_free() which<br /> handles all cases correctly and by removing the bitmap/vprop_page freeing<br /> from its_vpe_irq_domain_alloc().<br /> <br /> [ tglx: Massaged change log ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix information leak in btrfs_ioctl_logical_to_ino()<br /> <br /> Syzbot reported the following information leak for in<br /> btrfs_ioctl_logical_to_ino():<br /> <br /> BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40<br /> instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> _copy_to_user+0xbc/0x110 lib/usercopy.c:40<br /> copy_to_user include/linux/uaccess.h:191 [inline]<br /> btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499<br /> btrfs_ioctl+0x714/0x1260<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:904 [inline]<br /> __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890<br /> __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890<br /> x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> __kmalloc_large_node+0x231/0x370 mm/slub.c:3921<br /> __do_kmalloc_node mm/slub.c:3954 [inline]<br /> __kmalloc_node+0xb07/0x1060 mm/slub.c:3973<br /> kmalloc_node include/linux/slab.h:648 [inline]<br /> kvmalloc_node+0xc0/0x2d0 mm/util.c:634<br /> kvmalloc include/linux/slab.h:766 [inline]<br /> init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779<br /> btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480<br /> btrfs_ioctl+0x714/0x1260<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:904 [inline]<br /> __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890<br /> __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890<br /> x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Bytes 40-65535 of 65536 are uninitialized<br /> Memory access of size 65536 starts at ffff888045a40000<br /> <br /> This happens, because we&amp;#39;re copying a &amp;#39;struct btrfs_data_container&amp;#39; back<br /> to user-space. This btrfs_data_container is allocated in<br /> &amp;#39;init_data_container()&amp;#39; via kvmalloc(), which does not zero-fill the<br /> memory.<br /> <br /> Fix this by using kvzalloc() which zeroes out the memory on allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: qca: fix NULL-deref on non-serdev setup<br /> <br /> Qualcomm ROME controllers can be registered from the Bluetooth line<br /> discipline and in this case the HCI UART serdev pointer is NULL.<br /> <br /> Add the missing sanity check to prevent a NULL-pointer dereference when<br /> setup() is called for a non-serdev controller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: qca: fix NULL-deref on non-serdev suspend<br /> <br /> Qualcomm ROME controllers can be registered from the Bluetooth line<br /> discipline and in this case the HCI UART serdev pointer is NULL.<br /> <br /> Add the missing sanity check to prevent a NULL-pointer dereference when<br /> wakeup() is called for a non-serdev controller during suspend.<br /> <br /> Just return true for now to restore the original behaviour and address<br /> the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657<br /> ("Bluetooth: hci_qca: only assign wakeup with serial port support") that<br /> causes the crash to happen already at setup() time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eeprom: at24: fix memory corruption race condition<br /> <br /> If the eeprom is not accessible, an nvmem device will be registered, the<br /> read will fail, and the device will be torn down. If another driver<br /> accesses the nvmem device after the teardown, it will reference<br /> invalid memory.<br /> <br /> Move the failure point before registering the nvmem device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/powernv: Add a null pointer check to scom_debug_init_one()<br /> <br /> kasprintf() returns a pointer to dynamically allocated memory<br /> which can be NULL upon failure.<br /> Add a null pointer check, and release &amp;#39;ent&amp;#39; to avoid memory leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: fix a double-free in si_dpm_init<br /> <br /> When the allocation of<br /> adev-&gt;pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,<br /> amdgpu_free_extended_power_table is called to free some fields of adev.<br /> However, when the control flow returns to si_dpm_sw_init, it goes to<br /> label dpm_failed and calls si_dpm_fini, which calls<br /> amdgpu_free_extended_power_table again and free those fields again. Thus<br /> a double-free is triggered.