Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM / devfreq: rk3399_dmc: Disable edev on remove()<br /> <br /> Otherwise we hit an unablanced enable-count when unbinding the DFI<br /> device:<br /> <br /> [ 1279.659119] ------------[ cut here ]------------<br /> [ 1279.659179] WARNING: CPU: 2 PID: 5638 at drivers/devfreq/devfreq-event.c:360 devfreq_event_remove_edev+0x84/0x8c<br /> ...<br /> [ 1279.659352] Hardware name: Google Kevin (DT)<br /> [ 1279.659363] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO BTYPE=--)<br /> [ 1279.659371] pc : devfreq_event_remove_edev+0x84/0x8c<br /> [ 1279.659380] lr : devm_devfreq_event_release+0x1c/0x28<br /> ...<br /> [ 1279.659571] Call trace:<br /> [ 1279.659582] devfreq_event_remove_edev+0x84/0x8c<br /> [ 1279.659590] devm_devfreq_event_release+0x1c/0x28<br /> [ 1279.659602] release_nodes+0x1cc/0x244<br /> [ 1279.659611] devres_release_all+0x44/0x60<br /> [ 1279.659621] device_release_driver_internal+0x11c/0x1ac<br /> [ 1279.659629] device_driver_detach+0x20/0x2c<br /> [ 1279.659641] unbind_store+0x7c/0xb0<br /> [ 1279.659650] drv_attr_store+0x2c/0x40<br /> [ 1279.659663] sysfs_kf_write+0x44/0x58<br /> [ 1279.659672] kernfs_fop_write_iter+0xf4/0x190<br /> [ 1279.659684] vfs_write+0x2b0/0x2e4<br /> [ 1279.659693] ksys_write+0x80/0xec<br /> [ 1279.659701] __arm64_sys_write+0x24/0x30<br /> [ 1279.659714] el0_svc_common+0xf0/0x1d8<br /> [ 1279.659724] do_el0_svc_compat+0x28/0x3c<br /> [ 1279.659738] el0_svc_compat+0x10/0x1c<br /> [ 1279.659746] el0_sync_compat_handler+0xa8/0xcc<br /> [ 1279.659758] el0_sync_compat+0x188/0x1c0<br /> [ 1279.659768] ---[ end trace cec200e5094155b4 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amt: fix memory leak for advertisement message<br /> <br /> When a gateway receives an advertisement message, it extracts relay<br /> information and then it should be freed.<br /> But the advertisement handler doesn&amp;#39;t free it.<br /> So, memory leak would occur.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/a6xx: Fix refcount leak in a6xx_gpu_init<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> <br /> a6xx_gmu_init() passes the node to of_find_device_by_node()<br /> and of_dma_configure(), of_find_device_by_node() will takes its<br /> reference, of_dma_configure() doesn&amp;#39;t need the node after usage.<br /> <br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal/drivers/imx_sc_thermal: Fix refcount leak in imx_sc_thermal_probe<br /> <br /> of_find_node_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix buffer copy overflow of ztailpacking feature<br /> <br /> I got some KASAN report as below:<br /> <br /> [ 46.959738] ==================================================================<br /> [ 46.960430] BUG: KASAN: use-after-free in z_erofs_shifted_transform+0x2bd/0x370<br /> [ 46.960430] Read of size 4074 at addr ffff8880300c2f8e by task fssum/188<br /> ...<br /> [ 46.960430] Call Trace:<br /> [ 46.960430] <br /> [ 46.960430] dump_stack_lvl+0x41/0x5e<br /> [ 46.960430] print_report.cold+0xb2/0x6b7<br /> [ 46.960430] ? z_erofs_shifted_transform+0x2bd/0x370<br /> [ 46.960430] kasan_report+0x8a/0x140<br /> [ 46.960430] ? z_erofs_shifted_transform+0x2bd/0x370<br /> [ 46.960430] kasan_check_range+0x14d/0x1d0<br /> [ 46.960430] memcpy+0x20/0x60<br /> [ 46.960430] z_erofs_shifted_transform+0x2bd/0x370<br /> [ 46.960430] z_erofs_decompress_pcluster+0xaae/0x1080<br /> <br /> The root cause is that the tail pcluster won&amp;#39;t be a complete filesystem<br /> block anymore. So if ztailpacking is used, the second part of an<br /> uncompressed tail pcluster may not be ``rq-&gt;pageofs_out``.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: scmi: Fix refcount leak in scmi_regulator_probe<br /> <br /> of_find_node_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: msm: fix possible memory leak in mdp5_crtc_cursor_set()<br /> <br /> drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo<br /> needs to be put when msm_gem_get_and_pin_iova fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-throttle: Set BIO_THROTTLED when bio has been throttled<br /> <br /> 1.In current process, all bio will set the BIO_THROTTLED flag<br /> after __blk_throtl_bio().<br /> <br /> 2.If bio needs to be throttled, it will start the timer and<br /> stop submit bio directly. Bio will submit in<br /> blk_throtl_dispatch_work_fn() when the timer expires.But in<br /> the current process, if bio is throttled. The BIO_THROTTLED<br /> will be set to bio after timer start. If the bio has been<br /> completed, it may cause use-after-free blow.<br /> <br /> BUG: KASAN: use-after-free in blk_throtl_bio+0x12f0/0x2c70<br /> Read of size 2 at addr ffff88801b8902d4 by task fio/26380<br /> <br /> dump_stack+0x9b/0xce<br /> print_address_description.constprop.6+0x3e/0x60<br /> kasan_report.cold.9+0x22/0x3a<br /> blk_throtl_bio+0x12f0/0x2c70<br /> submit_bio_checks+0x701/0x1550<br /> submit_bio_noacct+0x83/0xc80<br /> submit_bio+0xa7/0x330<br /> mpage_readahead+0x380/0x500<br /> read_pages+0x1c1/0xbf0<br /> page_cache_ra_unbounded+0x471/0x6f0<br /> do_page_cache_ra+0xda/0x110<br /> ondemand_readahead+0x442/0xae0<br /> page_cache_async_ra+0x210/0x300<br /> generic_file_buffered_read+0x4d9/0x2130<br /> generic_file_read_iter+0x315/0x490<br /> blkdev_read_iter+0x113/0x1b0<br /> aio_read+0x2ad/0x450<br /> io_submit_one+0xc8e/0x1d60<br /> __se_sys_io_submit+0x125/0x350<br /> do_syscall_64+0x2d/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Allocated by task 26380:<br /> kasan_save_stack+0x19/0x40<br /> __kasan_kmalloc.constprop.2+0xc1/0xd0<br /> kmem_cache_alloc+0x146/0x440<br /> mempool_alloc+0x125/0x2f0<br /> bio_alloc_bioset+0x353/0x590<br /> mpage_alloc+0x3b/0x240<br /> do_mpage_readpage+0xddf/0x1ef0<br /> mpage_readahead+0x264/0x500<br /> read_pages+0x1c1/0xbf0<br /> page_cache_ra_unbounded+0x471/0x6f0<br /> do_page_cache_ra+0xda/0x110<br /> ondemand_readahead+0x442/0xae0<br /> page_cache_async_ra+0x210/0x300<br /> generic_file_buffered_read+0x4d9/0x2130<br /> generic_file_read_iter+0x315/0x490<br /> blkdev_read_iter+0x113/0x1b0<br /> aio_read+0x2ad/0x450<br /> io_submit_one+0xc8e/0x1d60<br /> __se_sys_io_submit+0x125/0x350<br /> do_syscall_64+0x2d/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Freed by task 0:<br /> kasan_save_stack+0x19/0x40<br /> kasan_set_track+0x1c/0x30<br /> kasan_set_free_info+0x1b/0x30<br /> __kasan_slab_free+0x111/0x160<br /> kmem_cache_free+0x94/0x460<br /> mempool_free+0xd6/0x320<br /> bio_free+0xe0/0x130<br /> bio_put+0xab/0xe0<br /> bio_endio+0x3a6/0x5d0<br /> blk_update_request+0x590/0x1370<br /> scsi_end_request+0x7d/0x400<br /> scsi_io_completion+0x1aa/0xe50<br /> scsi_softirq_done+0x11b/0x240<br /> blk_mq_complete_request+0xd4/0x120<br /> scsi_mq_done+0xf0/0x200<br /> virtscsi_vq_done+0xbc/0x150<br /> vring_interrupt+0x179/0x390<br /> __handle_irq_event_percpu+0xf7/0x490<br /> handle_irq_event_percpu+0x7b/0x160<br /> handle_irq_event+0xcc/0x170<br /> handle_edge_irq+0x215/0xb20<br /> common_interrupt+0x60/0x120<br /> asm_common_interrupt+0x1e/0x40<br /> <br /> Fix this by move BIO_THROTTLED set into the queue_lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvdimm: Fix firmware activation deadlock scenarios<br /> <br /> Lockdep reports the following deadlock scenarios for CXL root device<br /> power-management, device_prepare(), operations, and device_shutdown()<br /> operations for &amp;#39;nd_region&amp;#39; devices:<br /> <br /> Chain exists of:<br /> &amp;nvdimm_region_key --&gt; &amp;nvdimm_bus-&gt;reconfig_mutex --&gt; system_transition_mutex<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(system_transition_mutex);<br /> lock(&amp;nvdimm_bus-&gt;reconfig_mutex);<br /> lock(system_transition_mutex);<br /> lock(&amp;nvdimm_region_key);<br /> <br /> Chain exists of:<br /> &amp;cxl_nvdimm_bridge_key --&gt; acpi_scan_lock --&gt; &amp;cxl_root_key<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;cxl_root_key);<br /> lock(acpi_scan_lock);<br /> lock(&amp;cxl_root_key);<br /> lock(&amp;cxl_nvdimm_bridge_key);<br /> <br /> These stem from holding nvdimm_bus_lock() over hibernate_quiet_exec()<br /> which walks the entire system device topology taking device_lock() along<br /> the way. The nvdimm_bus_lock() is protecting against unregistration,<br /> multiple simultaneous ops callers, and preventing activate_show() from<br /> racing activate_store(). For the first 2, the lock is redundant.<br /> Unregistration already flushes all ops users, and sysfs already prevents<br /> multiple threads to be active in an ops handler at the same time. For<br /> the last userspace should already be waiting for its last<br /> activate_store() to complete, and does not need activate_show() to flush<br /> the write side, so this lock usage can be deleted in these attributes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: hisi: Add missing of_node_put after of_find_compatible_node<br /> <br /> of_find_compatible_node will increment the refcount of the returned<br /> device_node. Calling of_node_put() to avoid the refcount leak

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: bcm: Check for NULL return of devm_kzalloc()<br /> <br /> As the potential failure of allocation, devm_kzalloc() may return NULL. Then<br /> the &amp;#39;pd-&gt;pmb&amp;#39; and the follow lines of code may bring null pointer dereference.<br /> <br /> Therefore, it is better to check the return value of devm_kzalloc() to avoid<br /> this confusion.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: renesas: rzn1: Fix possible null-ptr-deref in sh_pfc_map_resources()<br /> <br /> It will cause null-ptr-deref when using &amp;#39;res&amp;#39;, if platform_get_resource()<br /> returns NULL, so move using &amp;#39;res&amp;#39; after devm_ioremap_resource() that<br /> will check it to avoid null-ptr-deref.<br /> And use devm_platform_get_and_ioremap_resource() to simplify code.