Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()<br /> <br /> Syzbot reported a hang issue in migrate_pages_batch() called by mbind()<br /> and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.<br /> <br /> While migrate_pages_batch() locks a folio and waits for the writeback to<br /> complete, the log writer thread that should bring the writeback to<br /> completion picks up the folio being written back in<br /> nilfs_lookup_dirty_data_buffers() that it calls for subsequent log<br /> creation and was trying to lock the folio. Thus causing a deadlock.<br /> <br /> In the first place, it is unexpected that folios/pages in the middle of<br /> writeback will be updated and become dirty. Nilfs2 adds a checksum to<br /> verify the validity of the log being written and uses it for recovery at<br /> mount, so data changes during writeback are suppressed. Since this is<br /> broken, an unclean shutdown could potentially cause recovery to fail.<br /> <br /> Investigation revealed that the root cause is that the wait for writeback<br /> completion in nilfs_page_mkwrite() is conditional, and if the backing<br /> device does not require stable writes, data may be modified without<br /> waiting.<br /> <br /> Fix these issues by making nilfs_page_mkwrite() wait for writeback to<br /> finish regardless of the stable write requirement of the backing device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix data corruption in dsync block recovery for small block sizes<br /> <br /> The helper function nilfs_recovery_copy_block() of<br /> nilfs_recovery_dsync_blocks(), which recovers data from logs created by<br /> data sync writes during a mount after an unclean shutdown, incorrectly<br /> calculates the on-page offset when copying repair data to the file&amp;#39;s page<br /> cache. In environments where the block size is smaller than the page<br /> size, this flaw can cause data corruption and leak uninitialized memory<br /> bytes during the recovery process.<br /> <br /> Fix these issues by correcting this byte offset calculation on the page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove<br /> <br /> In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the<br /> VMBus channel"), napi_disable was getting called for all channels,<br /> including all subchannels without confirming if they are enabled or not.<br /> <br /> This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()<br /> has finished running but nvdev-&gt;subchan_work has not started yet.<br /> netvsc_subchan_work() -&gt; rndis_set_subchannel() has not created the<br /> sub-channels and because of that netvsc_sc_open() is not running.<br /> netvsc_remove() calls cancel_work_sync(&amp;nvdev-&gt;subchan_work), for which<br /> netvsc_subchan_work did not run.<br /> <br /> netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI<br /> cannot be scheduled. Then netvsc_sc_open() -&gt; napi_enable will clear the<br /> NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the<br /> opposite.<br /> <br /> Now during netvsc_device_remove(), when napi_disable is called for those<br /> subchannels, napi_disable gets stuck on infinite msleep.<br /> <br /> This fix addresses this problem by ensuring that napi_disable() is not<br /> getting called for non-enabled NAPI struct.<br /> But netif_napi_del() is still necessary for these non-enabled NAPI struct<br /> for cleanup purpose.<br /> <br /> Call trace:<br /> [ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002<br /> [ 654.568030] Call Trace:<br /> [ 654.571221] <br /> [ 654.573790] __schedule+0x2d6/0x960<br /> [ 654.577733] schedule+0x69/0xf0<br /> [ 654.581214] schedule_timeout+0x87/0x140<br /> [ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20<br /> [ 654.590291] msleep+0x2d/0x40<br /> [ 654.593625] napi_disable+0x2b/0x80<br /> [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]<br /> [ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]<br /> [ 654.611101] ? do_wait_intr+0xb0/0xb0<br /> [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc]<br /> [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr<br /> <br /> [Why]<br /> There is a potential memory access violation while<br /> iterating through array of dcn35 clks.<br /> <br /> [How]<br /> Limit iteration per array size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/proc: do_task_stat: use sig-&gt;stats_lock to gather the threads/children stats<br /> <br /> lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call<br /> do_task_stat() at the same time and the process has NR_THREADS, it will<br /> spin with irqs disabled O(NR_CPUS * NR_THREADS) time.<br /> <br /> Change do_task_stat() to use sig-&gt;stats_lock to gather the statistics<br /> outside of -&gt;siglock protected section, in the likely case this code will<br /> run lockless.

Rejected reason: **REJECT** Duplicate of CVE-2023-46784. Please refer to CVE-2023-46784.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)<br /> <br /> Lock jsk-&gt;sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)<br /> modifies jsk-&gt;filters while receiving packets.<br /> <br /> Following trace was seen on affected system:<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]<br /> Read of size 4 at addr ffff888012144014 by task j1939/350<br /> <br /> CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> Call Trace:<br /> print_report+0xd3/0x620<br /> ? kasan_complete_mode_report_info+0x7d/0x200<br /> ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]<br /> kasan_report+0xc2/0x100<br /> ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]<br /> __asan_load4+0x84/0xb0<br /> j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]<br /> j1939_sk_recv+0x20b/0x320 [can_j1939]<br /> ? __kasan_check_write+0x18/0x20<br /> ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]<br /> ? j1939_simple_recv+0x69/0x280 [can_j1939]<br /> ? j1939_ac_recv+0x5e/0x310 [can_j1939]<br /> j1939_can_recv+0x43f/0x580 [can_j1939]<br /> ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]<br /> ? raw_rcv+0x42/0x3c0 [can_raw]<br /> ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]<br /> can_rcv_filter+0x11f/0x350 [can]<br /> can_receive+0x12f/0x190 [can]<br /> ? __pfx_can_rcv+0x10/0x10 [can]<br /> can_rcv+0xdd/0x130 [can]<br /> ? __pfx_can_rcv+0x10/0x10 [can]<br /> __netif_receive_skb_one_core+0x13d/0x150<br /> ? __pfx___netif_receive_skb_one_core+0x10/0x10<br /> ? __kasan_check_write+0x18/0x20<br /> ? _raw_spin_lock_irq+0x8c/0xe0<br /> __netif_receive_skb+0x23/0xb0<br /> process_backlog+0x107/0x260<br /> __napi_poll+0x69/0x310<br /> net_rx_action+0x2a1/0x580<br /> ? __pfx_net_rx_action+0x10/0x10<br /> ? __pfx__raw_spin_lock+0x10/0x10<br /> ? handle_irq_event+0x7d/0xa0<br /> __do_softirq+0xf3/0x3f8<br /> do_softirq+0x53/0x80<br /> <br /> <br /> __local_bh_enable_ip+0x6e/0x70<br /> netif_rx+0x16b/0x180<br /> can_send+0x32b/0x520 [can]<br /> ? __pfx_can_send+0x10/0x10 [can]<br /> ? __check_object_size+0x299/0x410<br /> raw_sendmsg+0x572/0x6d0 [can_raw]<br /> ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]<br /> ? apparmor_socket_sendmsg+0x2f/0x40<br /> ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]<br /> sock_sendmsg+0xef/0x100<br /> sock_write_iter+0x162/0x220<br /> ? __pfx_sock_write_iter+0x10/0x10<br /> ? __rtnl_unlock+0x47/0x80<br /> ? security_file_permission+0x54/0x320<br /> vfs_write+0x6ba/0x750<br /> ? __pfx_vfs_write+0x10/0x10<br /> ? __fget_light+0x1ca/0x1f0<br /> ? __rcu_read_unlock+0x5b/0x280<br /> ksys_write+0x143/0x170<br /> ? __pfx_ksys_write+0x10/0x10<br /> ? __kasan_check_read+0x15/0x20<br /> ? fpregs_assert_state_consistent+0x62/0x70<br /> __x64_sys_write+0x47/0x60<br /> do_syscall_64+0x60/0x90<br /> ? do_syscall_64+0x6d/0x90<br /> ? irqentry_exit+0x3f/0x50<br /> ? exc_page_fault+0x79/0xf0<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Allocated by task 348:<br /> kasan_save_stack+0x2a/0x50<br /> kasan_set_track+0x29/0x40<br /> kasan_save_alloc_info+0x1f/0x30<br /> __kasan_kmalloc+0xb5/0xc0<br /> __kmalloc_node_track_caller+0x67/0x160<br /> j1939_sk_setsockopt+0x284/0x450 [can_j1939]<br /> __sys_setsockopt+0x15c/0x2f0<br /> __x64_sys_setsockopt+0x6b/0x80<br /> do_syscall_64+0x60/0x90<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Freed by task 349:<br /> kasan_save_stack+0x2a/0x50<br /> kasan_set_track+0x29/0x40<br /> kasan_save_free_info+0x2f/0x50<br /> __kasan_slab_free+0x12e/0x1c0<br /> __kmem_cache_free+0x1b9/0x380<br /> kfree+0x7a/0x120<br /> j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]<br /> __sys_setsockopt+0x15c/0x2f0<br /> __x64_sys_setsockopt+0x6b/0x80<br /> do_syscall_64+0x60/0x90<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock<br /> <br /> The following 3 locks would race against each other, causing the<br /> deadlock situation in the Syzbot bug report:<br /> <br /> - j1939_socks_lock<br /> - active_session_list_lock<br /> - sk_session_queue_lock<br /> <br /> A reasonable fix is to change j1939_socks_lock to an rwlock, since in<br /> the rare situations where a write lock is required for the linked list<br /> that j1939_socks_lock is protecting, the code does not attempt to<br /> acquire any more locks. This would break the circular lock dependency,<br /> where, for example, the current thread already locks j1939_socks_lock<br /> and attempts to acquire sk_session_queue_lock, and at the same time,<br /> another thread attempts to acquire j1939_socks_lock while holding<br /> sk_session_queue_lock.<br /> <br /> NOTE: This patch along does not fix the unregister_netdevice bug<br /> reported by Syzbot; instead, it solves a deadlock situation to prepare<br /> for one or more further patches to actually fix the Syzbot bug, which<br /> appears to be a reference counting problem within the j1939 codebase.<br /> <br /> [mkl: remove unrelated newline change]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: s390: vsie: fix race during shadow creation<br /> <br /> Right now it is possible to see gmap-&gt;private being zero in<br /> kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the<br /> fact that we add gmap-&gt;private == kvm after creation:<br /> <br /> static int acquire_gmap_shadow(struct kvm_vcpu *vcpu,<br /> struct vsie_page *vsie_page)<br /> {<br /> [...]<br /> gmap = gmap_shadow(vcpu-&gt;arch.gmap, asce, edat);<br /> if (IS_ERR(gmap))<br /> return PTR_ERR(gmap);<br /> gmap-&gt;private = vcpu-&gt;kvm;<br /> <br /> Let children inherit the private field of the parent.

A vulnerability was found in SourceCodester Internship Portal Management System 1.0. It has been declared as critical. This vulnerability affects unknown code of the file admin/delete_activity.php. The manipulation of the argument activity_id leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-259108.

A NULL pointer dereference flaw was found in KubeVirt. This flaw allows an attacker who has access to a virtual machine guest on a node with DownwardMetrics enabled to cause a denial of service by issuing a high number of calls to vm-dump-metrics --virtio and then deleting the virtual machine.

An improper input validation vulnerability exists in the OAS Engine User Configuration functionality of Open Automation Software OAS Platform V19.00.0057. A specially crafted series of network requests can lead to unexpected data in the configuration. An attacker can send a sequence of requests to trigger this vulnerability.