Vulnerabilities

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

The Premium Addons for Elementor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin&amp;#39;s Animated Text widget in all versions up to, and including, 4.10.36 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Form Vibes plugin for WordPress is vulnerable to SQL Injection via the ‘fv_export_data’ parameter in all versions up to, and including, 1.4.10 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with Subscriber-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

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 /> drm/amdgpu: fix UBSAN warning in kv_dpm.c<br /> <br /> Adds bounds check for sumo_vid_mapping_entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: fix UBSAN warning in kv_dpm.c<br /> <br /> Adds bounds check for sumo_vid_mapping_entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Disassociate vcpus from redistributor region on teardown<br /> <br /> When tearing down a redistributor region, make sure we don&amp;#39;t have<br /> any dangling pointer to that region stored in a vcpu.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Add check for srq max_sge attribute<br /> <br /> max_sge attribute is passed by the user, and is inserted and used<br /> unchecked, so verify that the value doesn&amp;#39;t exceed maximum allowed value<br /> before using it.

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.