Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix uaf for flush rq while iterating tags<br /> <br /> blk_mq_clear_flush_rq_mapping() is not called during scsi probe, by<br /> checking blk_queue_init_done(). However, QUEUE_FLAG_INIT_DONE is cleared<br /> in del_gendisk by commit aec89dc5d421 ("block: keep q_usage_counter in<br /> atomic mode after del_gendisk"), hence for disk like scsi, following<br /> blk_mq_destroy_queue() will not clear flush rq from tags-&gt;rqs[] as well,<br /> cause following uaf that is found by our syzkaller for v6.6:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in blk_mq_find_and_get_req+0x16e/0x1a0 block/blk-mq-tag.c:261<br /> Read of size 4 at addr ffff88811c969c20 by task kworker/1:2H/224909<br /> <br /> CPU: 1 PID: 224909 Comm: kworker/1:2H Not tainted 6.6.0-ga836a5060850 #32<br /> Workqueue: kblockd blk_mq_timeout_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106<br /> print_address_description.constprop.0+0x66/0x300 mm/kasan/report.c:364<br /> print_report+0x3e/0x70 mm/kasan/report.c:475<br /> kasan_report+0xb8/0xf0 mm/kasan/report.c:588<br /> blk_mq_find_and_get_req+0x16e/0x1a0 block/blk-mq-tag.c:261<br /> bt_iter block/blk-mq-tag.c:288 [inline]<br /> __sbitmap_for_each_set include/linux/sbitmap.h:295 [inline]<br /> sbitmap_for_each_set include/linux/sbitmap.h:316 [inline]<br /> bt_for_each+0x455/0x790 block/blk-mq-tag.c:325<br /> blk_mq_queue_tag_busy_iter+0x320/0x740 block/blk-mq-tag.c:534<br /> blk_mq_timeout_work+0x1a3/0x7b0 block/blk-mq.c:1673<br /> process_one_work+0x7c4/0x1450 kernel/workqueue.c:2631<br /> process_scheduled_works kernel/workqueue.c:2704 [inline]<br /> worker_thread+0x804/0xe40 kernel/workqueue.c:2785<br /> kthread+0x346/0x450 kernel/kthread.c:388<br /> ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:293<br /> <br /> Allocated by task 942:<br /> kasan_save_stack+0x22/0x50 mm/kasan/common.c:45<br /> kasan_set_track+0x25/0x30 mm/kasan/common.c:52<br /> ____kasan_kmalloc mm/kasan/common.c:374 [inline]<br /> __kasan_kmalloc mm/kasan/common.c:383 [inline]<br /> __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:380<br /> kasan_kmalloc include/linux/kasan.h:198 [inline]<br /> __do_kmalloc_node mm/slab_common.c:1007 [inline]<br /> __kmalloc_node+0x69/0x170 mm/slab_common.c:1014<br /> kmalloc_node include/linux/slab.h:620 [inline]<br /> kzalloc_node include/linux/slab.h:732 [inline]<br /> blk_alloc_flush_queue+0x144/0x2f0 block/blk-flush.c:499<br /> blk_mq_alloc_hctx+0x601/0x940 block/blk-mq.c:3788<br /> blk_mq_alloc_and_init_hctx+0x27f/0x330 block/blk-mq.c:4261<br /> blk_mq_realloc_hw_ctxs+0x488/0x5e0 block/blk-mq.c:4294<br /> blk_mq_init_allocated_queue+0x188/0x860 block/blk-mq.c:4350<br /> blk_mq_init_queue_data block/blk-mq.c:4166 [inline]<br /> blk_mq_init_queue+0x8d/0x100 block/blk-mq.c:4176<br /> scsi_alloc_sdev+0x843/0xd50 drivers/scsi/scsi_scan.c:335<br /> scsi_probe_and_add_lun+0x77c/0xde0 drivers/scsi/scsi_scan.c:1189<br /> __scsi_scan_target+0x1fc/0x5a0 drivers/scsi/scsi_scan.c:1727<br /> scsi_scan_channel drivers/scsi/scsi_scan.c:1815 [inline]<br /> scsi_scan_channel+0x14b/0x1e0 drivers/scsi/scsi_scan.c:1791<br /> scsi_scan_host_selected+0x2fe/0x400 drivers/scsi/scsi_scan.c:1844<br /> scsi_scan+0x3a0/0x3f0 drivers/scsi/scsi_sysfs.c:151<br /> store_scan+0x2a/0x60 drivers/scsi/scsi_sysfs.c:191<br /> dev_attr_store+0x5c/0x90 drivers/base/core.c:2388<br /> sysfs_kf_write+0x11c/0x170 fs/sysfs/file.c:136<br /> kernfs_fop_write_iter+0x3fc/0x610 fs/kernfs/file.c:338<br /> call_write_iter include/linux/fs.h:2083 [inline]<br /> new_sync_write+0x1b4/0x2d0 fs/read_write.c:493<br /> vfs_write+0x76c/0xb00 fs/read_write.c:586<br /> ksys_write+0x127/0x250 fs/read_write.c:639<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> <br /> Freed by task 244687:<br /> kasan_save_stack+0x22/0x50 mm/kasan/common.c:45<br /> kasan_set_track+0x25/0x30 mm/kasan/common.c:52<br /> kasan_save_free_info+0x2b/0x50 mm/kasan/generic.c:522<br /> ____kasan_slab_free mm/kasan/common.c:236 [inline]<br /> __kasan_slab_free+0x12a/0x1b0 mm/kasan/common.c:244<br /> kasan_slab_free include/linux/kasan.h:164 [in<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit<br /> <br /> After an insertion in TNC, the tree might split and cause a node to<br /> change its `znode-&gt;parent`. A further deletion of other nodes in the<br /> tree (which also could free the nodes), the aforementioned node&amp;#39;s<br /> `znode-&gt;cparent` could still point to a freed node. This<br /> `znode-&gt;cparent` may not be updated when getting nodes to commit in<br /> `ubifs_tnc_start_commit()`. This could then trigger a use-after-free<br /> when accessing the `znode-&gt;cparent` in `write_index()` in<br /> `ubifs_tnc_end_commit()`.<br /> <br /> This can be triggered by running<br /> <br /> rm -f /etc/test-file.bin<br /> dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync<br /> <br /> in a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then<br /> reports:<br /> <br /> BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950<br /> Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153<br /> <br /> Call trace:<br /> dump_backtrace+0x0/0x340<br /> show_stack+0x18/0x24<br /> dump_stack_lvl+0x9c/0xbc<br /> print_address_description.constprop.0+0x74/0x2b0<br /> kasan_report+0x1d8/0x1f0<br /> kasan_check_range+0xf8/0x1a0<br /> memcpy+0x84/0xf4<br /> ubifs_tnc_end_commit+0xa5c/0x1950<br /> do_commit+0x4e0/0x1340<br /> ubifs_bg_thread+0x234/0x2e0<br /> kthread+0x36c/0x410<br /> ret_from_fork+0x10/0x20<br /> <br /> Allocated by task 401:<br /> kasan_save_stack+0x38/0x70<br /> __kasan_kmalloc+0x8c/0xd0<br /> __kmalloc+0x34c/0x5bc<br /> tnc_insert+0x140/0x16a4<br /> ubifs_tnc_add+0x370/0x52c<br /> ubifs_jnl_write_data+0x5d8/0x870<br /> do_writepage+0x36c/0x510<br /> ubifs_writepage+0x190/0x4dc<br /> __writepage+0x58/0x154<br /> write_cache_pages+0x394/0x830<br /> do_writepages+0x1f0/0x5b0<br /> filemap_fdatawrite_wbc+0x170/0x25c<br /> file_write_and_wait_range+0x140/0x190<br /> ubifs_fsync+0xe8/0x290<br /> vfs_fsync_range+0xc0/0x1e4<br /> do_fsync+0x40/0x90<br /> __arm64_sys_fsync+0x34/0x50<br /> invoke_syscall.constprop.0+0xa8/0x260<br /> do_el0_svc+0xc8/0x1f0<br /> el0_svc+0x34/0x70<br /> el0t_64_sync_handler+0x108/0x114<br /> el0t_64_sync+0x1a4/0x1a8<br /> <br /> Freed by task 403:<br /> kasan_save_stack+0x38/0x70<br /> kasan_set_track+0x28/0x40<br /> kasan_set_free_info+0x28/0x4c<br /> __kasan_slab_free+0xd4/0x13c<br /> kfree+0xc4/0x3a0<br /> tnc_delete+0x3f4/0xe40<br /> ubifs_tnc_remove_range+0x368/0x73c<br /> ubifs_tnc_remove_ino+0x29c/0x2e0<br /> ubifs_jnl_delete_inode+0x150/0x260<br /> ubifs_evict_inode+0x1d4/0x2e4<br /> evict+0x1c8/0x450<br /> iput+0x2a0/0x3c4<br /> do_unlinkat+0x2cc/0x490<br /> __arm64_sys_unlinkat+0x90/0x100<br /> invoke_syscall.constprop.0+0xa8/0x260<br /> do_el0_svc+0xc8/0x1f0<br /> el0_svc+0x34/0x70<br /> el0t_64_sync_handler+0x108/0x114<br /> el0t_64_sync+0x1a4/0x1a8<br /> <br /> The offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free<br /> when a node becomes root in TNC but still has a `cparent` to an already<br /> freed node. More specifically, consider the following TNC:<br /> <br /> zroot<br /> /<br /> /<br /> zp1<br /> /<br /> /<br /> zn<br /> <br /> Inserting a new node `zn_new` with a key smaller then `zn` will trigger<br /> a split in `tnc_insert()` if `zp1` is full:<br /> <br /> zroot<br /> / \<br /> / \<br /> zp1 zp2<br /> / \<br /> / \<br /> zn_new zn<br /> <br /> `zn-&gt;parent` has now been moved to `zp2`, *but* `zn-&gt;cparent` still<br /> points to `zp1`.<br /> <br /> Now, consider a removal of all the nodes _except_ `zn`. Just when<br /> `tnc_delete()` is about to delete `zroot` and `zp2`:<br /> <br /> zroot<br /> \<br /> \<br /> zp2<br /> \<br /> \<br /> zn<br /> <br /> `zroot` and `zp2` get freed and the tree collapses:<br /> <br /> zn<br /> <br /> `zn` now becomes the new `zroot`.<br /> <br /> `get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and<br /> `write_index()` will check its `znode-&gt;cparent` that wrongly points to<br /> the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called<br /> with `znode-&gt;cparent-&gt;zbranch[znode-&gt;iip].hash` that triggers the<br /> use-after-free!<br /> <br /> Fix this by explicitly setting `znode-&gt;cparent` to `NULL` in<br /> `get_znodes_to_commit()` for the root node. The search for the dirty<br /> nodes<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: fastmap: Fix duplicate slab cache names while attaching<br /> <br /> Since commit 4c39529663b9 ("slab: Warn on duplicate cache names when<br /> DEBUG_VM=y"), the duplicate slab cache names can be detected and a<br /> kernel WARNING is thrown out.<br /> In UBI fast attaching process, alloc_ai() could be invoked twice<br /> with the same slab cache name &amp;#39;ubi_aeb_slab_cache&amp;#39;, which will trigger<br /> following warning messages:<br /> kmem_cache of name &amp;#39;ubi_aeb_slab_cache&amp;#39; already exists<br /> WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107<br /> __kmem_cache_create_args+0x100/0x5f0<br /> Modules linked in: ubi(+) nandsim [last unloaded: nandsim]<br /> CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2<br /> RIP: 0010:__kmem_cache_create_args+0x100/0x5f0<br /> Call Trace:<br /> __kmem_cache_create_args+0x100/0x5f0<br /> alloc_ai+0x295/0x3f0 [ubi]<br /> ubi_attach+0x3c3/0xcc0 [ubi]<br /> ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi]<br /> ubi_init+0x3fb/0x800 [ubi]<br /> do_init_module+0x265/0x7d0<br /> __x64_sys_finit_module+0x7a/0xc0<br /> <br /> The problem could be easily reproduced by loading UBI device by fastmap<br /> with CONFIG_DEBUG_VM=y.<br /> Fix it by using different slab names for alloc_ai() callers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4.0: Fix a use-after-free problem in the asynchronous open()<br /> <br /> Yang Erkun reports that when two threads are opening files at the same<br /> time, and are forced to abort before a reply is seen, then the call to<br /> nfs_release_seqid() in nfs4_opendata_free() can result in a<br /> use-after-free of the pointer to the defunct rpc task of the other<br /> thread.<br /> The fix is to ensure that if the RPC call is aborted before the call to<br /> nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid()<br /> in nfs4_open_release() before the rpc_task is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: make sure cache entry active before cache_show<br /> <br /> The function `c_show` was called with protection from RCU. This only<br /> ensures that `cp` will not be freed. Therefore, the reference count for<br /> `cp` can drop to zero, which will trigger a refcount use-after-free<br /> warning when `cache_get` is called. To resolve this issue, use<br /> `cache_get_rcu` to ensure that `cp` remains active.<br /> <br /> ------------[ cut here ]------------<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 7 PID: 822 at lib/refcount.c:25<br /> refcount_warn_saturate+0xb1/0x120<br /> CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.16.1-2.fc37 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0xb1/0x120<br /> <br /> Call Trace:<br /> <br /> c_show+0x2fc/0x380 [sunrpc]<br /> seq_read_iter+0x589/0x770<br /> seq_read+0x1e5/0x270<br /> proc_reg_read+0xe1/0x140<br /> vfs_read+0x125/0x530<br /> ksys_read+0xc1/0x160<br /> do_syscall_64+0x5f/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipc: fix memleak if msg_init_ns failed in create_ipc_ns<br /> <br /> Percpu memory allocation may failed during create_ipc_ns however this<br /> fail is not handled properly since ipc sysctls and mq sysctls is not<br /> released properly. Fix this by release these two resource when failure.<br /> <br /> Here is the kmemleak stack when percpu failed:<br /> <br /> unreferenced object 0xffff88819de2a600 (size 512):<br /> comm "shmem_2nstest", pid 120711, jiffies 4300542254<br /> hex dump (first 32 bytes):<br /> 60 aa 9d 84 ff ff ff ff fc 18 48 b2 84 88 ff ff `.........H.....<br /> 04 00 00 00 a4 01 00 00 20 e4 56 81 ff ff ff ff ........ .V.....<br /> backtrace (crc be7cba35):<br /> [] __kmalloc_node_track_caller_noprof+0x333/0x420<br /> [] kmemdup_noprof+0x26/0x50<br /> [] setup_mq_sysctls+0x57/0x1d0<br /> [] copy_ipcs+0x29c/0x3b0<br /> [] create_new_namespaces+0x1d0/0x920<br /> [] copy_namespaces+0x2e9/0x3e0<br /> [] copy_process+0x29f3/0x7ff0<br /> [] kernel_clone+0xc0/0x650<br /> [] __do_sys_clone+0xa1/0xe0<br /> [] do_syscall_64+0xbf/0x1c0<br /> [] entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs/blocklayout: Don&amp;#39;t attempt unregister for invalid block device<br /> <br /> Since commit d869da91cccb ("nfs/blocklayout: Fix premature PR key<br /> unregistration") an unmount of a pNFS SCSI layout-enabled NFS may<br /> dereference a NULL block_device in:<br /> <br /> bl_unregister_scsi+0x16/0xe0 [blocklayoutdriver]<br /> bl_free_device+0x70/0x80 [blocklayoutdriver]<br /> bl_free_deviceid_node+0x12/0x30 [blocklayoutdriver]<br /> nfs4_put_deviceid_node+0x60/0xc0 [nfsv4]<br /> nfs4_deviceid_purge_client+0x132/0x190 [nfsv4]<br /> unset_pnfs_layoutdriver+0x59/0x60 [nfsv4]<br /> nfs4_destroy_server+0x36/0x70 [nfsv4]<br /> nfs_free_server+0x23/0xe0 [nfs]<br /> deactivate_locked_super+0x30/0xb0<br /> cleanup_mnt+0xba/0x150<br /> task_work_run+0x59/0x90<br /> syscall_exit_to_user_mode+0x217/0x220<br /> do_syscall_64+0x8e/0x160<br /> <br /> This happens because even though we were able to create the<br /> nfs4_deviceid_node, the lookup for the device was unable to attach the<br /> block device to the pnfs_block_dev.<br /> <br /> If we never found a block device to register, we can avoid this case with<br /> the PNFS_BDEV_REGISTERED flag. Move the deref behind the test for the<br /> flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket<br /> <br /> BUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0<br /> Read of size 1 at addr ffff888111f322cd by task swapper/0/0<br /> <br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x68/0xa0<br /> print_address_description.constprop.0+0x2c/0x3d0<br /> print_report+0xb4/0x270<br /> kasan_report+0xbd/0xf0<br /> tcp_write_timer_handler+0x156/0x3e0<br /> tcp_write_timer+0x66/0x170<br /> call_timer_fn+0xfb/0x1d0<br /> __run_timers+0x3f8/0x480<br /> run_timer_softirq+0x9b/0x100<br /> handle_softirqs+0x153/0x390<br /> __irq_exit_rcu+0x103/0x120<br /> irq_exit_rcu+0xe/0x20<br /> sysvec_apic_timer_interrupt+0x76/0x90<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x1a/0x20<br /> RIP: 0010:default_idle+0xf/0x20<br /> Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90<br /> 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 c3 cc cc cc<br /> cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90<br /> RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242<br /> RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d<br /> R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000<br /> R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0<br /> default_idle_call+0x6b/0xa0<br /> cpuidle_idle_call+0x1af/0x1f0<br /> do_idle+0xbc/0x130<br /> cpu_startup_entry+0x33/0x40<br /> rest_init+0x11f/0x210<br /> start_kernel+0x39a/0x420<br /> x86_64_start_reservations+0x18/0x30<br /> x86_64_start_kernel+0x97/0xa0<br /> common_startup_64+0x13e/0x141<br /> <br /> <br /> Allocated by task 595:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_slab_alloc+0x87/0x90<br /> kmem_cache_alloc_noprof+0x12b/0x3f0<br /> copy_net_ns+0x94/0x380<br /> create_new_namespaces+0x24c/0x500<br /> unshare_nsproxy_namespaces+0x75/0xf0<br /> ksys_unshare+0x24e/0x4f0<br /> __x64_sys_unshare+0x1f/0x30<br /> do_syscall_64+0x70/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Freed by task 100:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x54/0x70<br /> kmem_cache_free+0x156/0x5d0<br /> cleanup_net+0x5d3/0x670<br /> process_one_work+0x776/0xa90<br /> worker_thread+0x2e2/0x560<br /> kthread+0x1a8/0x1f0<br /> ret_from_fork+0x34/0x60<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Reproduction script:<br /> <br /> mkdir -p /mnt/nfsshare<br /> mkdir -p /mnt/nfs/netns_1<br /> mkfs.ext4 /dev/sdb<br /> mount /dev/sdb /mnt/nfsshare<br /> systemctl restart nfs-server<br /> chmod 777 /mnt/nfsshare<br /> exportfs -i -o rw,no_root_squash *:/mnt/nfsshare<br /> <br /> ip netns add netns_1<br /> ip link add name veth_1_peer type veth peer veth_1<br /> ifconfig veth_1_peer 11.11.0.254 up<br /> ip link set veth_1 netns netns_1<br /> ip netns exec netns_1 ifconfig veth_1 11.11.0.1<br /> <br /> ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \<br /> --tcp-flags FIN FIN -j DROP<br /> <br /> (note: In my environment, a DESTROY_CLIENTID operation is always sent<br /> immediately, breaking the nfs tcp connection.)<br /> ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \<br /> 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1<br /> <br /> ip netns del netns_1<br /> <br /> The reason here is that the tcp socket in netns_1 (nfs side) has been<br /> shutdown and closed (done in xs_destroy), but the FIN message (with ack)<br /> is discarded, and the nfsd side keeps sending retransmission messages.<br /> As a result, when the tcp sock in netns_1 processes the received message,<br /> it sends the message (FIN message) in the sending queue, and the tcp timer<br /> is re-established. When the network namespace is deleted, the net structure<br /> accessed by tcp&amp;#39;s timer handler function causes problems.<br /> <br /> To fix this problem, let&amp;#39;s hold netns refcnt for the tcp kernel socket as<br /> done in other modules. This is an ugly hack which can easily be backported<br /> to earlier kernels. A proper fix which cleans up the interfaces will<br /> follow, but may not be so easy to backport.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: fix ordering of qlen adjustment<br /> <br /> Changes to sch-&gt;q.qlen around qdisc_tree_reduce_backlog() need to happen<br /> _before_ a call to said function because otherwise it may fail to notify<br /> parent qdiscs when the child is about to become empty.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sh: intc: Fix use-after-free bug in register_intc_controller()<br /> <br /> In the error handling for this function, d is freed without ever<br /> removing it from intc_list which would lead to a use after free.<br /> To fix this, let&amp;#39;s only add it to the list after everything has<br /> succeeded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block, bfq: fix bfqq uaf in bfq_limit_depth()<br /> <br /> Set new allocated bfqq to bic or remove freed bfqq from bic are both<br /> protected by bfqd-&gt;lock, however bfq_limit_depth() is deferencing bfqq<br /> from bic without the lock, this can lead to UAF if the io_context is<br /> shared by multiple tasks.<br /> <br /> For example, test bfq with io_uring can trigger following UAF in v6.6:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in bfqq_group+0x15/0x50<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x47/0x80<br /> print_address_description.constprop.0+0x66/0x300<br /> print_report+0x3e/0x70<br /> kasan_report+0xb4/0xf0<br /> bfqq_group+0x15/0x50<br /> bfqq_request_over_limit+0x130/0x9a0<br /> bfq_limit_depth+0x1b5/0x480<br /> __blk_mq_alloc_requests+0x2b5/0xa00<br /> blk_mq_get_new_requests+0x11d/0x1d0<br /> blk_mq_submit_bio+0x286/0xb00<br /> submit_bio_noacct_nocheck+0x331/0x400<br /> __block_write_full_folio+0x3d0/0x640<br /> writepage_cb+0x3b/0xc0<br /> write_cache_pages+0x254/0x6c0<br /> write_cache_pages+0x254/0x6c0<br /> do_writepages+0x192/0x310<br /> filemap_fdatawrite_wbc+0x95/0xc0<br /> __filemap_fdatawrite_range+0x99/0xd0<br /> filemap_write_and_wait_range.part.0+0x4d/0xa0<br /> blkdev_read_iter+0xef/0x1e0<br /> io_read+0x1b6/0x8a0<br /> io_issue_sqe+0x87/0x300<br /> io_wq_submit_work+0xeb/0x390<br /> io_worker_handle_work+0x24d/0x550<br /> io_wq_worker+0x27f/0x6c0<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> Allocated by task 808602:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> __kasan_slab_alloc+0x83/0x90<br /> kmem_cache_alloc_node+0x1b1/0x6d0<br /> bfq_get_queue+0x138/0xfa0<br /> bfq_get_bfqq_handle_split+0xe3/0x2c0<br /> bfq_init_rq+0x196/0xbb0<br /> bfq_insert_request.isra.0+0xb5/0x480<br /> bfq_insert_requests+0x156/0x180<br /> blk_mq_insert_request+0x15d/0x440<br /> blk_mq_submit_bio+0x8a4/0xb00<br /> submit_bio_noacct_nocheck+0x331/0x400<br /> __blkdev_direct_IO_async+0x2dd/0x330<br /> blkdev_write_iter+0x39a/0x450<br /> io_write+0x22a/0x840<br /> io_issue_sqe+0x87/0x300<br /> io_wq_submit_work+0xeb/0x390<br /> io_worker_handle_work+0x24d/0x550<br /> io_wq_worker+0x27f/0x6c0<br /> ret_from_fork+0x2d/0x50<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> Freed by task 808589:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> kasan_save_free_info+0x27/0x40<br /> __kasan_slab_free+0x126/0x1b0<br /> kmem_cache_free+0x10c/0x750<br /> bfq_put_queue+0x2dd/0x770<br /> __bfq_insert_request.isra.0+0x155/0x7a0<br /> bfq_insert_request.isra.0+0x122/0x480<br /> bfq_insert_requests+0x156/0x180<br /> blk_mq_dispatch_plug_list+0x528/0x7e0<br /> blk_mq_flush_plug_list.part.0+0xe5/0x590<br /> __blk_flush_plug+0x3b/0x90<br /> blk_finish_plug+0x40/0x60<br /> do_writepages+0x19d/0x310<br /> filemap_fdatawrite_wbc+0x95/0xc0<br /> __filemap_fdatawrite_range+0x99/0xd0<br /> filemap_write_and_wait_range.part.0+0x4d/0xa0<br /> blkdev_read_iter+0xef/0x1e0<br /> io_read+0x1b6/0x8a0<br /> io_issue_sqe+0x87/0x300<br /> io_wq_submit_work+0xeb/0x390<br /> io_worker_handle_work+0x24d/0x550<br /> io_wq_worker+0x27f/0x6c0<br /> ret_from_fork+0x2d/0x50<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> Fix the problem by protecting bic_to_bfqq() with bfqd-&gt;lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK<br /> <br /> When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected,<br /> cpu_max_bits_warn() generates a runtime warning similar as below when<br /> showing /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)<br /> instead of NR_CPUS to iterate CPUs.<br /> <br /> [ 3.052463] ------------[ cut here ]------------<br /> [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0<br /> [ 3.070072] Modules linked in: efivarfs autofs4<br /> [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052<br /> [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000<br /> [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430<br /> [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff<br /> [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890<br /> [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa<br /> [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000<br /> [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000<br /> [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000<br /> [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286<br /> [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c<br /> [ 3.195868] ...<br /> [ 3.199917] Call Trace:<br /> [ 3.203941] [] show_stack+0x38/0x14c<br /> [ 3.210666] [] dump_stack_lvl+0x60/0x88<br /> [ 3.217625] [] __warn+0xd0/0x100<br /> [ 3.223958] [] warn_slowpath_fmt+0x7c/0xcc<br /> [ 3.231150] [] show_cpuinfo+0x5e8/0x5f0<br /> [ 3.238080] [] seq_read_iter+0x354/0x4b4<br /> [ 3.245098] [] new_sync_read+0x17c/0x1c4<br /> [ 3.252114] [] vfs_read+0x138/0x1d0<br /> [ 3.258694] [] ksys_read+0x70/0x100<br /> [ 3.265265] [] do_syscall+0x7c/0x94<br /> [ 3.271820] [] handle_syscall+0xc4/0x160<br /> [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---