Vulnerabilities

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 /> block: null_blk: end timed out poll request<br /> <br /> When poll request is timed out, it is removed from the poll list,<br /> but not completed, so the request is leaked, and never get chance<br /> to complete.<br /> <br /> Fix the issue by ending it in timeout handler.

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 /> 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 /> 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 /> 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 /> jffs2: fix use-after-free in jffs2_clear_xattr_subsystem<br /> <br /> When we mount a jffs2 image, assume that the first few blocks of<br /> the image are normal and contain at least one xattr-related inode,<br /> but the next block is abnormal. As a result, an error is returned<br /> in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then<br /> called in jffs2_build_filesystem() and then again in<br /> jffs2_do_fill_super().<br /> <br /> Finally we can observe the following report:<br /> ==================================================================<br /> BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac<br /> Read of size 8 at addr ffff8881243384e0 by task mount/719<br /> <br /> Call Trace:<br /> dump_stack+0x115/0x16b<br /> jffs2_clear_xattr_subsystem+0x95/0x6ac<br /> jffs2_do_fill_super+0x84f/0xc30<br /> jffs2_fill_super+0x2ea/0x4c0<br /> mtd_get_sb+0x254/0x400<br /> mtd_get_sb_by_nr+0x4f/0xd0<br /> get_tree_mtd+0x498/0x840<br /> jffs2_get_tree+0x25/0x30<br /> vfs_get_tree+0x8d/0x2e0<br /> path_mount+0x50f/0x1e50<br /> do_mount+0x107/0x130<br /> __se_sys_mount+0x1c5/0x2f0<br /> __x64_sys_mount+0xc7/0x160<br /> do_syscall_64+0x45/0x70<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Allocated by task 719:<br /> kasan_save_stack+0x23/0x60<br /> __kasan_kmalloc.constprop.0+0x10b/0x120<br /> kasan_slab_alloc+0x12/0x20<br /> kmem_cache_alloc+0x1c0/0x870<br /> jffs2_alloc_xattr_ref+0x2f/0xa0<br /> jffs2_scan_medium.cold+0x3713/0x4794<br /> jffs2_do_mount_fs.cold+0xa7/0x2253<br /> jffs2_do_fill_super+0x383/0xc30<br /> jffs2_fill_super+0x2ea/0x4c0<br /> [...]<br /> <br /> Freed by task 719:<br /> kmem_cache_free+0xcc/0x7b0<br /> jffs2_free_xattr_ref+0x78/0x98<br /> jffs2_clear_xattr_subsystem+0xa1/0x6ac<br /> jffs2_do_mount_fs.cold+0x5e6/0x2253<br /> jffs2_do_fill_super+0x383/0xc30<br /> jffs2_fill_super+0x2ea/0x4c0<br /> [...]<br /> <br /> The buggy address belongs to the object at ffff8881243384b8<br /> which belongs to the cache jffs2_xattr_ref of size 48<br /> The buggy address is located 40 bytes inside of<br /> 48-byte region [ffff8881243384b8, ffff8881243384e8)<br /> [...]<br /> ==================================================================<br /> <br /> The triggering of the BUG is shown in the following stack:<br /> -----------------------------------------------------------<br /> jffs2_fill_super<br /> jffs2_do_fill_super<br /> jffs2_do_mount_fs<br /> jffs2_build_filesystem<br /> jffs2_scan_medium<br /> jffs2_scan_eraseblock

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.