Vulnerabilities

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 ]---

A Denial of Service vulnerability in the DNS Security feature of Palo Alto Networks PAN-OS software allows an unauthenticated attacker to send a malicious packet through the data plane of the firewall that reboots the firewall. Repeated attempts to trigger this condition will cause the firewall to enter maintenance mode.

There is a stack overflow vulnerability in some Huawei smart phone. An attacker can craft specific packet to exploit this vulnerability. Due to insufficient verification, this could be exploited to tamper with the information to affect the availability. (Vulnerability ID: HWPSIRT-2019-11030)<br /> <br /> This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9253.

There is a privilege escalation vulnerability in Huawei FusionCompute product. Due to insufficient verification on specific files that need to be deserialized, local attackers can exploit this vulnerability to elevate permissions. (Vulnerability ID: HWPSIRT-2020-05241)<br /> <br /> This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9222.

There is an improper interface design vulnerability in Huawei product. A module interface of the impated product does not deal with some operations properly. Attackers can exploit this vulnerability to perform malicious operatation to compromise module service. (Vulnerability ID: HWPSIRT-2020-05010)<br /> <br /> <br /> This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9236.

There is an insufficient integrity vulnerability in Huawei products. A module does not perform sufficient integrity check in a specific scenario. Attackers can exploit the vulnerability by physically install malware. This could compromise normal service of the affected device. (Vulnerability ID: HWPSIRT-2020-00145)<br /> <br /> This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9210.