Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix unexpected zeroed page mapping with zram swap<br /> <br /> Two processes under CLONE_VM cloning, user process can be corrupted by<br /> seeing zeroed page unexpectedly.<br /> <br /> CPU A CPU B<br /> <br /> do_swap_page do_swap_page<br /> SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path<br /> swap_readpage valid data<br /> swap_slot_free_notify<br /> delete zram entry<br /> swap_readpage zeroed(invalid) data<br /> pte_lock<br /> map the *zero data* to userspace<br /> pte_unlock<br /> pte_lock<br /> if (!pte_same)<br /> goto out_nomap;<br /> pte_unlock<br /> return and next refault will<br /> read zeroed data<br /> <br /> The swap_slot_free_notify is bogus for CLONE_VM case since it doesn&amp;#39;t<br /> increase the refcount of swap slot at copy_mm so it couldn&amp;#39;t catch up<br /> whether it&amp;#39;s safe or not to discard data from backing device. In the<br /> case, only the lock it could rely on to synchronize swap slot freeing is<br /> page table lock. Thus, this patch gets rid of the swap_slot_free_notify<br /> function. With this patch, CPU A will see correct data.<br /> <br /> CPU A CPU B<br /> <br /> do_swap_page do_swap_page<br /> SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path<br /> swap_readpage original data<br /> pte_lock<br /> map the original data<br /> swap_free<br /> swap_range_free<br /> bd_disk-&gt;fops-&gt;swap_slot_free_notify<br /> swap_readpage read zeroed data<br /> pte_unlock<br /> pte_lock<br /> if (!pte_same)<br /> goto out_nomap;<br /> pte_unlock<br /> return<br /> on next refault will see mapped data by CPU B<br /> <br /> The concern of the patch would increase memory consumption since it<br /> could keep wasted memory with compressed form in zram as well as<br /> uncompressed form in address space. However, most of cases of zram uses<br /> no readahead and do_swap_page is followed by swap_free so it will free<br /> the compressed form from in zram quickly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: hv: vmbus: Deactivate sysctl_record_panic_msg by default in isolated guests<br /> <br /> hv_panic_page might contain guest-sensitive information, do not dump it<br /> over to Hyper-V by default in isolated guests.<br /> <br /> While at it, update some comments in hyperv_{panic,die}_event().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm integrity: fix memory corruption when tag_size is less than digest size<br /> <br /> It is possible to set up dm-integrity in such a way that the<br /> "tag_size" parameter is less than the actual digest size. In this<br /> situation, a part of the digest beyond tag_size is ignored.<br /> <br /> In this case, dm-integrity would write beyond the end of the<br /> ic-&gt;recalc_tags array and corrupt memory. The corruption happened in<br /> integrity_recalc-&gt;integrity_sector_checksum-&gt;crypto_shash_final.<br /> <br /> Fix this corruption by increasing the tags array so that it has enough<br /> padding at the end to accomodate the loop in integrity_recalc() being<br /> able to write a full digest size for the last member of the tags<br /> array.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: dev: check return value when calling dev_set_name()<br /> <br /> If dev_set_name() fails, the dev_name() is null, check the return<br /> value of dev_set_name() to avoid the null-ptr-deref.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ep93xx: clock: Fix UAF in ep93xx_clk_register_gate()<br /> <br /> arch/arm/mach-ep93xx/clock.c:154:2: warning: Use of memory after it is freed [clang-analyzer-unix.Malloc]<br /> arch/arm/mach-ep93xx/clock.c:151:2: note: Taking true branch<br /> if (IS_ERR(clk))<br /> ^<br /> arch/arm/mach-ep93xx/clock.c:152:3: note: Memory is released<br /> kfree(psc);<br /> ^~~~~~~~~~<br /> arch/arm/mach-ep93xx/clock.c:154:2: note: Use of memory after it is freed<br /> return &amp;psc-&gt;hw;<br /> ^ ~~~~~~~~

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: fix a potential gpu_metrics_table memory leak<br /> <br /> Memory is allocated for gpu_metrics_table in renoir_init_smc_tables(),<br /> but not freed in int smu_v12_0_fini_smc_tables(). Free it!

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: davinci: vpif: fix use-after-free on driver unbind<br /> <br /> The driver allocates and registers two platform device structures during<br /> probe, but the devices were never deregistered on driver unbind.<br /> <br /> This results in a use-after-free on driver unbind as the device<br /> structures were allocated using devres and would be freed by driver<br /> core when remove() returns.<br /> <br /> Fix this by adding the missing deregistration calls to the remove()<br /> callback and failing probe on registration errors.<br /> <br /> Note that the platform device structures must be freed using a proper<br /> release callback to avoid leaking associated resources like device<br /> names.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> samples/landlock: Fix path_list memory leak<br /> <br /> Clang static analysis reports this error<br /> <br /> sandboxer.c:134:8: warning: Potential leak of memory<br /> pointed to by &amp;#39;path_list&amp;#39;<br /> ret = 0;<br /> ^<br /> path_list is allocated in parse_path() but never freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: vdec: fixed possible memory leak issue<br /> <br /> The venus_helper_alloc_dpb_bufs() implementation allows an early return<br /> on an error path when checking the id from ida_alloc_min() which would<br /> not release the earlier buffer allocation.<br /> <br /> Move the direct kfree() from the error checking of dma_alloc_attrs() to<br /> the common fail path to ensure that allocations are released on all<br /> error paths in this function.<br /> <br /> Addresses-Coverity: 1494120 ("Resource leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free()<br /> <br /> If virtio_gpu_object_shmem_init() fails (e.g. due to fault injection, as it<br /> happened in the bug report by syzbot), virtio_gpu_array_put_free() could be<br /> called with objs equal to NULL.<br /> <br /> Ensure that objs is not NULL in virtio_gpu_array_put_free(), or otherwise<br /> return from the function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: fix a potential gpu_metrics_table memory leak<br /> <br /> Memory is allocated for gpu_metrics_table in renoir_init_smc_tables(),<br /> but not freed in int smu_v12_0_fini_smc_tables(). Free it!