Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/sqpoll: work around a potential audit memory leak<br /> <br /> kmemleak complains that there&amp;#39;s a memory leak related to connect<br /> handling:<br /> <br /> unreferenced object 0xffff0001093bdf00 (size 128):<br /> comm "iou-sqp-455", pid 457, jiffies 4294894164<br /> hex dump (first 32 bytes):<br /> 02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc 2e481b1a):<br /> [] kmemleak_alloc+0x30/0x38<br /> [] kmalloc_trace+0x228/0x358<br /> [] __audit_sockaddr+0xd0/0x138<br /> [] move_addr_to_kernel+0x1a0/0x1f8<br /> [] io_connect_prep+0x1ec/0x2d4<br /> [] io_submit_sqes+0x588/0x1e48<br /> [] io_sq_thread+0x8a4/0x10e4<br /> [] ret_from_fork+0x10/0x20<br /> <br /> which can can happen if:<br /> <br /> 1) The command type does something on the prep side that triggers an<br /> audit call.<br /> 2) The thread hasn&amp;#39;t done any operations before this that triggered<br /> an audit call inside -&gt;issue(), where we have audit_uring_entry()<br /> and audit_uring_exit().<br /> <br /> Work around this by issuing a blanket NOP operation before the SQPOLL<br /> does anything.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: hisilicon/sec - Fix memory leak for sec resource release<br /> <br /> The AIV is one of the SEC resources. When releasing resources,<br /> it need to release the AIV resources at the same time.<br /> Otherwise, memory leakage occurs.<br /> <br /> The aiv resource release is added to the sec resource release<br /> function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Build event generation tests only as modules<br /> <br /> The kprobes and synth event generation test modules add events and lock<br /> (get a reference) those event file reference in module init function,<br /> and unlock and delete it in module exit function. This is because those<br /> are designed for playing as modules.<br /> <br /> If we make those modules as built-in, those events are left locked in the<br /> kernel, and never be removed. This causes kprobe event self-test failure<br /> as below.<br /> <br /> [ 97.349708] ------------[ cut here ]------------<br /> [ 97.353453] WARNING: CPU: 3 PID: 1 at kernel/trace/trace_kprobe.c:2133 kprobe_trace_self_tests_init+0x3f1/0x480<br /> [ 97.357106] Modules linked in:<br /> [ 97.358488] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.9.0-g699646734ab5-dirty #14<br /> [ 97.361556] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> [ 97.363880] RIP: 0010:kprobe_trace_self_tests_init+0x3f1/0x480<br /> [ 97.365538] Code: a8 24 08 82 e9 ae fd ff ff 90 0f 0b 90 48 c7 c7 e5 aa 0b 82 e9 ee fc ff ff 90 0f 0b 90 48 c7 c7 2d 61 06 82 e9 8e fd ff ff 90 0b 90 48 c7 c7 33 0b 0c 82 89 c6 e8 6e 03 1f ff 41 ff c7 e9 90<br /> [ 97.370429] RSP: 0000:ffffc90000013b50 EFLAGS: 00010286<br /> [ 97.371852] RAX: 00000000fffffff0 RBX: ffff888005919c00 RCX: 0000000000000000<br /> [ 97.373829] RDX: ffff888003f40000 RSI: ffffffff8236a598 RDI: ffff888003f40a68<br /> [ 97.375715] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000<br /> [ 97.377675] R10: ffffffff811c9ae5 R11: ffffffff8120c4e0 R12: 0000000000000000<br /> [ 97.379591] R13: 0000000000000001 R14: 0000000000000015 R15: 0000000000000000<br /> [ 97.381536] FS: 0000000000000000(0000) GS:ffff88807dcc0000(0000) knlGS:0000000000000000<br /> [ 97.383813] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 97.385449] CR2: 0000000000000000 CR3: 0000000002244000 CR4: 00000000000006b0<br /> [ 97.387347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 97.389277] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 97.391196] Call Trace:<br /> [ 97.391967] <br /> [ 97.392647] ? __warn+0xcc/0x180<br /> [ 97.393640] ? kprobe_trace_self_tests_init+0x3f1/0x480<br /> [ 97.395181] ? report_bug+0xbd/0x150<br /> [ 97.396234] ? handle_bug+0x3e/0x60<br /> [ 97.397311] ? exc_invalid_op+0x1a/0x50<br /> [ 97.398434] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 97.399652] ? trace_kprobe_is_busy+0x20/0x20<br /> [ 97.400904] ? tracing_reset_all_online_cpus+0x15/0x90<br /> [ 97.402304] ? kprobe_trace_self_tests_init+0x3f1/0x480<br /> [ 97.403773] ? init_kprobe_trace+0x50/0x50<br /> [ 97.404972] do_one_initcall+0x112/0x240<br /> [ 97.406113] do_initcall_level+0x95/0xb0<br /> [ 97.407286] ? kernel_init+0x1a/0x1a0<br /> [ 97.408401] do_initcalls+0x3f/0x70<br /> [ 97.409452] kernel_init_freeable+0x16f/0x1e0<br /> [ 97.410662] ? rest_init+0x1f0/0x1f0<br /> [ 97.411738] kernel_init+0x1a/0x1a0<br /> [ 97.412788] ret_from_fork+0x39/0x50<br /> [ 97.413817] ? rest_init+0x1f0/0x1f0<br /> [ 97.414844] ret_from_fork_asm+0x11/0x20<br /> [ 97.416285] <br /> [ 97.417134] irq event stamp: 13437323<br /> [ 97.418376] hardirqs last enabled at (13437337): [] console_unlock+0x11c/0x150<br /> [ 97.421285] hardirqs last disabled at (13437370): [] console_unlock+0x101/0x150<br /> [ 97.423838] softirqs last enabled at (13437366): [] handle_softirqs+0x23f/0x2a0<br /> [ 97.426450] softirqs last disabled at (13437393): [] __irq_exit_rcu+0x66/0xd0<br /> [ 97.428850] ---[ end trace 0000000000000000 ]---<br /> <br /> And also, since we can not cleanup dynamic_event file, ftracetest are<br /> failed too.<br /> <br /> To avoid these issues, build these tests only as modules.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netpoll: Fix race condition in netpoll_owner_active<br /> <br /> KCSAN detected a race condition in netpoll:<br /> <br /> BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb<br /> write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:<br /> net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)<br /> <br /> read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2:<br /> netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393)<br /> netpoll_send_udp (net/core/netpoll.c:?)<br /> <br /> value changed: 0x0000000a -&gt; 0xffffffff<br /> <br /> This happens because netpoll_owner_active() needs to check if the<br /> current CPU is the owner of the lock, touching napi-&gt;poll_owner<br /> non atomically. The -&gt;poll_owner field contains the current CPU holding<br /> the lock.<br /> <br /> Use an atomic read to check if the poll owner is the current CPU.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netrom: Fix a memory leak in nr_heartbeat_expiry()<br /> <br /> syzbot reported a memory leak in nr_create() [0].<br /> <br /> Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.")<br /> added sock_hold() to the nr_heartbeat_expiry() function, where<br /> a) a socket has a SOCK_DESTROY flag or<br /> b) a listening socket has a SOCK_DEAD flag.<br /> <br /> But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor<br /> has already been closed and the nr_release() function has been called.<br /> So it makes no sense to hold the reference count because no one will<br /> call another nr_destroy_socket() and put it as in the case "b."<br /> <br /> nr_connect<br /> nr_establish_data_link<br /> nr_start_heartbeat<br /> <br /> nr_release<br /> switch (nr-&gt;state)<br /> case NR_STATE_3<br /> nr-&gt;state = NR_STATE_2<br /> sock_set_flag(sk, SOCK_DESTROY);<br /> <br /> nr_rx_frame<br /> nr_process_rx_frame<br /> switch (nr-&gt;state)<br /> case NR_STATE_2<br /> nr_state2_machine()<br /> nr_disconnect()<br /> nr_sk(sk)-&gt;state = NR_STATE_0<br /> sock_set_flag(sk, SOCK_DEAD)<br /> <br /> nr_heartbeat_expiry<br /> switch (nr-&gt;state)<br /> case NR_STATE_0<br /> if (sock_flag(sk, SOCK_DESTROY) ||<br /> (sk-&gt;sk_state == TCP_LISTEN<br /> &amp;&amp; sock_flag(sk, SOCK_DEAD)))<br /> sock_hold() // ( !!! )<br /> nr_destroy_socket()<br /> <br /> To fix the memory leak, let&amp;#39;s call sock_hold() only for a listening socket.<br /> <br /> Found by InfoTeCS on behalf of Linux Verification Center<br /> (linuxtesting.org) with Syzkaller.<br /> <br /> [0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp_ao: Don&amp;#39;t leak ao_info on error-path<br /> <br /> It seems I introduced it together with TCP_AO_CMDF_AO_REQUIRED, on<br /> version 5 [1] of TCP-AO patches. Quite frustrative that having all these<br /> selftests that I&amp;#39;ve written, running kmemtest &amp; kcov was always in todo.<br /> <br /> [1]: https://lore.kernel.org/netdev/20230215183335.800122-5-dima@arista.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: xilinx: xdma: Fix data synchronisation in xdma_channel_isr()<br /> <br /> Requests the vchan lock before using xdma-&gt;stop_request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: k3-udma-glue: Fix of_k3_udma_glue_parse_chn_by_id()<br /> <br /> The of_k3_udma_glue_parse_chn_by_id() helper function erroneously<br /> invokes "of_node_put()" on the "udmax_np" device-node passed to it,<br /> without having incremented its reference count at any point. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix responder length checking for UD request packets<br /> <br /> According to the IBA specification:<br /> If a UD request packet is detected with an invalid length, the request<br /> shall be an invalid request and it shall be silently dropped by<br /> the responder. The responder then waits for a new request packet.<br /> <br /> commit 689c5421bfe0 ("RDMA/rxe: Fix incorrect responder length checking")<br /> defers responder length check for UD QPs in function `copy_data`.<br /> But it introduces a regression issue for UD QPs.<br /> <br /> When the packet size is too large to fit in the receive buffer.<br /> `copy_data` will return error code -EINVAL. Then `send_data_in`<br /> will return RESPST_ERR_MALFORMED_WQE. UD QP will transfer into<br /> ERROR state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: amd-pstate: fix memory leak on CPU EPP exit<br /> <br /> The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is<br /> not freed in the analogous exit function, so fix that.<br /> <br /> [ rjw: Subject and changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix uninitialized ratelimit_state-&gt;lock access in __ext4_fill_super()<br /> <br /> In the following concurrency we will access the uninitialized rs-&gt;lock:<br /> <br /> ext4_fill_super<br /> ext4_register_sysfs<br /> // sysfs registered msg_ratelimit_interval_ms<br /> // Other processes modify rs-&gt;interval to<br /> // non-zero via msg_ratelimit_interval_ms<br /> ext4_orphan_cleanup<br /> ext4_msg(sb, KERN_INFO, "Errors on filesystem, "<br /> __ext4_msg<br /> ___ratelimit(&amp;(EXT4_SB(sb)-&gt;s_msg_ratelimit_state)<br /> if (!rs-&gt;interval) // do nothing if interval is 0<br /> return 1;<br /> raw_spin_trylock_irqsave(&amp;rs-&gt;lock, flags)<br /> raw_spin_trylock(lock)<br /> _raw_spin_trylock<br /> __raw_spin_trylock<br /> spin_acquire(&amp;lock-&gt;dep_map, 0, 1, _RET_IP_)<br /> lock_acquire<br /> __lock_acquire<br /> register_lock_class<br /> assign_lock_key<br /> dump_stack();<br /> ratelimit_state_init(&amp;sbi-&gt;s_msg_ratelimit_state, 5 * HZ, 10);<br /> raw_spin_lock_init(&amp;rs-&gt;lock);<br /> // init rs-&gt;lock here<br /> <br /> and get the following dump_stack:<br /> <br /> =========================================================<br /> INFO: trying to register non-static key.<br /> The code is fine but needs lockdep annotation, or maybe<br /> you didn&amp;#39;t initialize this object before use?<br /> turning off the locking correctness validator.<br /> CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504<br /> [...]<br /> Call Trace:<br /> dump_stack_lvl+0xc5/0x170<br /> dump_stack+0x18/0x30<br /> register_lock_class+0x740/0x7c0<br /> __lock_acquire+0x69/0x13a0<br /> lock_acquire+0x120/0x450<br /> _raw_spin_trylock+0x98/0xd0<br /> ___ratelimit+0xf6/0x220<br /> __ext4_msg+0x7f/0x160 [ext4]<br /> ext4_orphan_cleanup+0x665/0x740 [ext4]<br /> __ext4_fill_super+0x21ea/0x2b10 [ext4]<br /> ext4_fill_super+0x14d/0x360 [ext4]<br /> [...]<br /> =========================================================<br /> <br /> Normally interval is 0 until s_msg_ratelimit_state is initialized, so<br /> ___ratelimit() does nothing. But registering sysfs precedes initializing<br /> rs-&gt;lock, so it is possible to change rs-&gt;interval to a non-zero value<br /> via the msg_ratelimit_interval_ms interface of sysfs while rs-&gt;lock is<br /> uninitialized, and then a call to ext4_msg triggers the problem by<br /> accessing an uninitialized rs-&gt;lock. Therefore register sysfs after all<br /> initializations are complete to avoid such problems.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ena: Add validation for completion descriptors consistency<br /> <br /> Validate that `first` flag is set only for the first<br /> descriptor in multi-buffer packets.<br /> In case of an invalid descriptor, a reset will occur.<br /> A new reset reason for RX data corruption has been added.