Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix listen() setting the bar too high for the prealloc rings<br /> <br /> AF_RXRPC&amp;#39;s listen() handler lets you set the backlog up to 32 (if you bump<br /> up the sysctl), but whilst the preallocation circular buffers have 32 slots<br /> in them, one of them has to be a dead slot because we&amp;#39;re using CIRC_CNT().<br /> <br /> This means that listen(rxrpc_sock, 32) will cause an oops when the socket<br /> is closed because rxrpc_service_prealloc_one() allocated one too many calls<br /> and rxrpc_discard_prealloc() won&amp;#39;t then be able to get rid of them because<br /> it&amp;#39;ll think the ring is empty. rxrpc_release_calls_on_socket() then tries<br /> to abort them, but oopses because call-&gt;peer isn&amp;#39;t yet set.<br /> <br /> Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match<br /> the ring capacity.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000086<br /> ...<br /> RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc]<br /> Call Trace:<br /> <br /> ? __wake_up_common_lock+0x7a/0x90<br /> ? rxrpc_notify_socket+0x8e/0x140 [rxrpc]<br /> ? rxrpc_abort_call+0x4c/0x60 [rxrpc]<br /> rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc]<br /> rxrpc_release+0xc9/0x1c0 [rxrpc]<br /> __sock_release+0x37/0xa0<br /> sock_close+0x11/0x20<br /> __fput+0x89/0x240<br /> task_work_run+0x59/0x90<br /> do_exit+0x319/0xaa0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scmi: Fix list protocols enumeration in the base protocol<br /> <br /> While enumerating protocols implemented by the SCMI platform using<br /> BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is<br /> currently validated in an improper way since the check employs a sum<br /> between unsigned integers that could overflow and cause the check itself<br /> to be silently bypassed if the returned value &amp;#39;loop_num_ret&amp;#39; is big<br /> enough.<br /> <br /> Fix the validation avoiding the addition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpaa2-eth: retrieve the virtual address before dma_unmap<br /> <br /> The TSO header was DMA unmapped before the virtual address was retrieved<br /> and then used to free the buffer. This meant that we were actually<br /> removing the DMA map and then trying to search for it to help in<br /> retrieving the virtual address. This lead to a invalid virtual address<br /> being used in the kfree call.<br /> <br /> Fix this by calling dpaa2_iova_to_virt() prior to the dma_unmap call.<br /> <br /> [ 487.231819] Unable to handle kernel paging request at virtual address fffffd9807000008<br /> <br /> (...)<br /> <br /> [ 487.354061] Hardware name: SolidRun LX2160A Honeycomb (DT)<br /> [ 487.359535] pstate: a0400005 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 487.366485] pc : kfree+0xac/0x304<br /> [ 487.369799] lr : kfree+0x204/0x304<br /> [ 487.373191] sp : ffff80000c4eb120<br /> [ 487.376493] x29: ffff80000c4eb120 x28: ffff662240c46400 x27: 0000000000000001<br /> [ 487.383621] x26: 0000000000000001 x25: ffff662246da0cc0 x24: ffff66224af78000<br /> [ 487.390748] x23: ffffad184f4ce008 x22: ffffad1850185000 x21: ffffad1838d13cec<br /> [ 487.397874] x20: ffff6601c0000000 x19: fffffd9807000000 x18: 0000000000000000<br /> [ 487.405000] x17: ffffb910cdc49000 x16: ffffad184d7d9080 x15: 0000000000004000<br /> [ 487.412126] x14: 0000000000000008 x13: 000000000000ffff x12: 0000000000000000<br /> [ 487.419252] x11: 0000000000000004 x10: 0000000000000001 x9 : ffffad184d7d927c<br /> [ 487.426379] x8 : 0000000000000000 x7 : 0000000ffffffd1d x6 : ffff662240a94900<br /> [ 487.433505] x5 : 0000000000000003 x4 : 0000000000000009 x3 : ffffad184f4ce008<br /> [ 487.440632] x2 : ffff662243eec000 x1 : 0000000100000100 x0 : fffffc0000000000<br /> [ 487.447758] Call trace:<br /> [ 487.450194] kfree+0xac/0x304<br /> [ 487.453151] dpaa2_eth_free_tx_fd.isra.0+0x33c/0x3e0 [fsl_dpaa2_eth]<br /> [ 487.459507] dpaa2_eth_tx_conf+0x100/0x2e0 [fsl_dpaa2_eth]<br /> [ 487.464989] dpaa2_eth_poll+0xdc/0x380 [fsl_dpaa2_eth]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: ti: ti_sci_pm_domains: Check for null return of devm_kcalloc<br /> <br /> The allocation funciton devm_kcalloc may fail and return a null pointer,<br /> which would cause a null-pointer dereference later.<br /> It might be better to check it and directly return -ENOMEM just like the<br /> usage of devm_kcalloc in previous code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: mediatek: Fix refcount leak in mtk_pcie_subsys_powerup()<br /> <br /> The of_find_compatible_node() function returns a node pointer with<br /> refcount incremented, We should use of_node_put() on it when done<br /> Add the missing of_node_put() to release the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: ocxl: fix possible double free in ocxl_file_register_afu<br /> <br /> info_release() will be called in device_unregister() when info-&gt;dev&amp;#39;s<br /> reference count is 0. So there is no need to call ocxl_afu_put() and<br /> kfree() again.<br /> <br /> Fix this by adding free_minor() and return to err_unregister error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: fix missed rcu protection<br /> <br /> When removing the rcu_read_lock in bond_ethtool_get_ts_info() as<br /> discussed [1], I didn&amp;#39;t notice it could be called via setsockopt,<br /> which doesn&amp;#39;t hold rcu lock, as syzbot pointed:<br /> <br /> stack backtrace:<br /> CPU: 0 PID: 3599 Comm: syz-executor317 Not tainted 5.18.0-rc5-syzkaller-01392-g01f4685797a5 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> bond_option_active_slave_get_rcu include/net/bonding.h:353 [inline]<br /> bond_ethtool_get_ts_info+0x32c/0x3a0 drivers/net/bonding/bond_main.c:5595<br /> __ethtool_get_ts_info+0x173/0x240 net/ethtool/common.c:554<br /> ethtool_get_phc_vclocks+0x99/0x110 net/ethtool/common.c:568<br /> sock_timestamping_bind_phc net/core/sock.c:869 [inline]<br /> sock_set_timestamping+0x3a3/0x7e0 net/core/sock.c:916<br /> sock_setsockopt+0x543/0x2ec0 net/core/sock.c:1221<br /> __sys_setsockopt+0x55e/0x6a0 net/socket.c:2223<br /> __do_sys_setsockopt net/socket.c:2238 [inline]<br /> __se_sys_setsockopt net/socket.c:2235 [inline]<br /> __x64_sys_setsockopt+0xba/0x150 net/socket.c:2235<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f8902c8eb39<br /> <br /> Fix it by adding rcu_read_lock and take a ref on the real_dev.<br /> Since dev_hold() and dev_put() can take NULL these days, we can<br /> skip checking if real_dev exist.<br /> <br /> [1] https://lore.kernel.org/netdev/27565.1642742439@famine/