Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: Fix use-after-free in get_info()<br /> <br /> ip6table_nat module unload has refcnt warning for UAF. call trace is:<br /> <br /> WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80<br /> Modules linked in: ip6table_nat(-)<br /> CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:module_put+0x6f/0x80<br /> Call Trace:<br /> <br /> get_info+0x128/0x180<br /> do_ip6t_get_ctl+0x6a/0x430<br /> nf_getsockopt+0x46/0x80<br /> ipv6_getsockopt+0xb9/0x100<br /> rawv6_getsockopt+0x42/0x190<br /> do_sock_getsockopt+0xaa/0x180<br /> __sys_getsockopt+0x70/0xc0<br /> __x64_sys_getsockopt+0x20/0x30<br /> do_syscall_64+0xa2/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Concurrent execution of module unload and get_info() trigered the warning.<br /> The root cause is as follows:<br /> <br /> cpu0 cpu1<br /> module_exit<br /> //mod-&gt;state = MODULE_STATE_GOING<br /> ip6table_nat_exit<br /> xt_unregister_template<br /> kfree(t)<br /> //removed from templ_list<br /> getinfo()<br /> t = xt_find_table_lock<br /> list_for_each_entry(tmpl, &amp;xt_templates[af]...)<br /> if (strcmp(tmpl-&gt;name, name))<br /> continue; //table not found<br /> try_module_get<br /> list_for_each_entry(t, &amp;xt_net-&gt;tables[af]...)<br /> return t; //not get refcnt<br /> module_put(t-&gt;me) //uaf<br /> unregister_pernet_subsys<br /> //remove table from xt_net list<br /> <br /> While xt_table module was going away and has been removed from<br /> xt_templates list, we couldnt get refcnt of xt_table-&gt;me. Check<br /> module in xt_net-&gt;tables list re-traversal to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write()<br /> <br /> This was found by a static analyzer.<br /> We should not forget the trailing zero after copy_from_user()<br /> if we will further do some string operations, sscanf() in this<br /> case. Adding a trailing zero will ensure that the function<br /> performs properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macsec: Fix use-after-free while sending the offloading packet<br /> <br /> KASAN reports the following UAF. The metadata_dst, which is used to<br /> store the SCI value for macsec offload, is already freed by<br /> metadata_dst_free() in macsec_free_netdev(), while driver still use it<br /> for sending the packet.<br /> <br /> To fix this issue, dst_release() is used instead to release<br /> metadata_dst. So it is not freed instantly in macsec_free_netdev() if<br /> still referenced by skb.<br /> <br /> BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core]<br /> Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714<br /> [...]<br /> Workqueue: mld mld_ifc_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x51/0x60<br /> print_report+0xc1/0x600<br /> kasan_report+0xab/0xe0<br /> mlx5e_xmit+0x1e8f/0x4190 [mlx5_core]<br /> dev_hard_start_xmit+0x120/0x530<br /> sch_direct_xmit+0x149/0x11e0<br /> __qdisc_run+0x3ad/0x1730<br /> __dev_queue_xmit+0x1196/0x2ed0<br /> vlan_dev_hard_start_xmit+0x32e/0x510 [8021q]<br /> dev_hard_start_xmit+0x120/0x530<br /> __dev_queue_xmit+0x14a7/0x2ed0<br /> macsec_start_xmit+0x13e9/0x2340<br /> dev_hard_start_xmit+0x120/0x530<br /> __dev_queue_xmit+0x14a7/0x2ed0<br /> ip6_finish_output2+0x923/0x1a70<br /> ip6_finish_output+0x2d7/0x970<br /> ip6_output+0x1ce/0x3a0<br /> NF_HOOK.constprop.0+0x15f/0x190<br /> mld_sendpack+0x59a/0xbd0<br /> mld_ifc_work+0x48a/0xa80<br /> process_one_work+0x5aa/0xe50<br /> worker_thread+0x79c/0x1290<br /> kthread+0x28f/0x350<br /> ret_from_fork+0x2d/0x70<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> <br /> Allocated by task 3922:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x10/0x30<br /> __kasan_kmalloc+0x77/0x90<br /> __kmalloc_noprof+0x188/0x400<br /> metadata_dst_alloc+0x1f/0x4e0<br /> macsec_newlink+0x914/0x1410<br /> __rtnl_newlink+0xe08/0x15b0<br /> rtnl_newlink+0x5f/0x90<br /> rtnetlink_rcv_msg+0x667/0xa80<br /> netlink_rcv_skb+0x12c/0x360<br /> netlink_unicast+0x551/0x770<br /> netlink_sendmsg+0x72d/0xbd0<br /> __sock_sendmsg+0xc5/0x190<br /> ____sys_sendmsg+0x52e/0x6a0<br /> ___sys_sendmsg+0xeb/0x170<br /> __sys_sendmsg+0xb5/0x140<br /> do_syscall_64+0x4c/0x100<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Freed by task 4011:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x10/0x30<br /> kasan_save_free_info+0x37/0x50<br /> poison_slab_object+0x10c/0x190<br /> __kasan_slab_free+0x11/0x30<br /> kfree+0xe0/0x290<br /> macsec_free_netdev+0x3f/0x140<br /> netdev_run_todo+0x450/0xc70<br /> rtnetlink_rcv_msg+0x66f/0xa80<br /> netlink_rcv_skb+0x12c/0x360<br /> netlink_unicast+0x551/0x770<br /> netlink_sendmsg+0x72d/0xbd0<br /> __sock_sendmsg+0xc5/0x190<br /> ____sys_sendmsg+0x52e/0x6a0<br /> ___sys_sendmsg+0xeb/0x170<br /> __sys_sendmsg+0xb5/0x140<br /> do_syscall_64+0x4c/0x100<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix out-of-bounds write in trie_get_next_key()<br /> <br /> trie_get_next_key() allocates a node stack with size trie-&gt;max_prefixlen,<br /> while it writes (trie-&gt;max_prefixlen + 1) nodes to the stack when it has<br /> full paths from the root to leaves. For example, consider a trie with<br /> max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...<br /> 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with<br /> .prefixlen = 8 make 9 nodes be written on the node stack with size 8.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: Add bounds checking to mi_enum_attr()<br /> <br /> Added bounds checking to make sure that every attr don&amp;#39;t stray beyond<br /> valid memory region.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Add rough attr alloc_size check

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix general protection fault in run_is_mapped_full<br /> <br /> Fixed deleating of a non-resident attribute in ntfs_create_inode()<br /> rollback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Additional check in ni_clear()<br /> <br /> Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to<br /> uninitialized bitmap during replay process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix possible deadlock in mi_read<br /> <br /> Mutex lock with another subclass used in ni_lock_dir().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Check if more than chunk-size bytes are written<br /> <br /> A incorrectly formatted chunk may decompress into<br /> more than LZNT_CHUNK_SIZE bytes and a index out of bounds<br /> will occur in s_max_off.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: CPPC: Make rmw_lock a raw_spin_lock<br /> <br /> The following BUG was triggered:<br /> <br /> =============================<br /> [ BUG: Invalid wait context ]<br /> 6.12.0-rc2-XXX #406 Not tainted<br /> -----------------------------<br /> kworker/1:1/62 is trying to lock:<br /> ffffff8801593030 (&amp;cpc_ptr-&gt;rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370<br /> other info that might help us debug this:<br /> context-{5:5}<br /> 2 locks held by kworker/1:1/62:<br /> #0: ffffff897ef5ec98 (&amp;rq-&gt;__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50<br /> #1: ffffff880154e238 (&amp;sg_policy-&gt;update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280<br /> stack backtrace:<br /> CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406<br /> Workqueue: 0x0 (events)<br /> Call trace:<br /> dump_backtrace+0xa4/0x130<br /> show_stack+0x20/0x38<br /> dump_stack_lvl+0x90/0xd0<br /> dump_stack+0x18/0x28<br /> __lock_acquire+0x480/0x1ad8<br /> lock_acquire+0x114/0x310<br /> _raw_spin_lock+0x50/0x70<br /> cpc_write+0xcc/0x370<br /> cppc_set_perf+0xa0/0x3a8<br /> cppc_cpufreq_fast_switch+0x40/0xc0<br /> cpufreq_driver_fast_switch+0x4c/0x218<br /> sugov_update_shared+0x234/0x280<br /> update_load_avg+0x6ec/0x7b8<br /> dequeue_entities+0x108/0x830<br /> dequeue_task_fair+0x58/0x408<br /> __schedule+0x4f0/0x1070<br /> schedule+0x54/0x130<br /> worker_thread+0xc0/0x2e8<br /> kthread+0x130/0x148<br /> ret_from_fork+0x10/0x20<br /> <br /> sugov_update_shared() locks a raw_spinlock while cpc_write() locks a<br /> spinlock.<br /> <br /> To have a correct wait-type order, update rmw_lock to a raw spinlock and<br /> ensure that interrupts will be disabled on the CPU holding it.<br /> <br /> [ rjw: Changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsdax: dax_unshare_iter needs to copy entire blocks<br /> <br /> The code that copies data from srcmap to iomap in dax_unshare_iter is<br /> very very broken, which bfoster&amp;#39;s recent fsx changes have exposed.<br /> <br /> If the pos and len passed to dax_file_unshare are not aligned to an<br /> fsblock boundary, the iter pos and length in the _iter function will<br /> reflect this unalignment.<br /> <br /> dax_iomap_direct_access always returns a pointer to the start of the<br /> kmapped fsdax page, even if its pos argument is in the middle of that<br /> page. This is catastrophic for data integrity when iter-&gt;pos is not<br /> aligned to a page, because daddr/saddr do not point to the same byte in<br /> the file as iter-&gt;pos. Hence we corrupt user data by copying it to the<br /> wrong place.<br /> <br /> If iter-&gt;pos + iomap_length() in the _iter function not aligned to a<br /> page, then we fail to copy a full block, and only partially populate the<br /> destination block. This is catastrophic for data confidentiality<br /> because we expose stale pmem contents.<br /> <br /> Fix both of these issues by aligning copy_pos/copy_len to a page<br /> boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that<br /> we always copy full blocks.<br /> <br /> We&amp;#39;re not done yet -- there&amp;#39;s no call to invalidate_inode_pages2_range,<br /> so programs that have the file range mmap&amp;#39;d will continue accessing the<br /> old memory mapping after the file metadata updates have completed.<br /> <br /> Be careful with the return value -- if the unshare succeeds, we still<br /> need to return the number of bytes that the iomap iter thinks we&amp;#39;re<br /> operating on.