Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> null_blk: fix null-ptr-dereference while configuring &amp;#39;power&amp;#39; and &amp;#39;submit_queues&amp;#39;<br /> <br /> Writing &amp;#39;power&amp;#39; and &amp;#39;submit_queues&amp;#39; concurrently will trigger kernel<br /> panic:<br /> <br /> Test script:<br /> <br /> modprobe null_blk nr_devices=0<br /> mkdir -p /sys/kernel/config/nullb/nullb0<br /> while true; do echo 1 &gt; submit_queues; echo 4 &gt; submit_queues; done &amp;<br /> while true; do echo 1 &gt; power; echo 0 &gt; power; done<br /> <br /> Test result:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000148<br /> Oops: 0000 [#1] PREEMPT SMP<br /> RIP: 0010:__lock_acquire+0x41d/0x28f0<br /> Call Trace:<br /> <br /> lock_acquire+0x121/0x450<br /> down_write+0x5f/0x1d0<br /> simple_recursive_removal+0x12f/0x5c0<br /> blk_mq_debugfs_unregister_hctxs+0x7c/0x100<br /> blk_mq_update_nr_hw_queues+0x4a3/0x720<br /> nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]<br /> nullb_device_submit_queues_store+0x79/0xf0 [null_blk]<br /> configfs_write_iter+0x119/0x1e0<br /> vfs_write+0x326/0x730<br /> ksys_write+0x74/0x150<br /> <br /> This is because del_gendisk() can concurrent with<br /> blk_mq_update_nr_hw_queues():<br /> <br /> nullb_device_power_store nullb_apply_submit_queues<br /> null_del_dev<br /> del_gendisk<br /> nullb_update_nr_hw_queues<br /> if (!dev-&gt;nullb)<br /> // still set while gendisk is deleted<br /> return 0<br /> blk_mq_update_nr_hw_queues<br /> dev-&gt;nullb = NULL<br /> <br /> Fix this problem by resuing the global mutex to protect<br /> nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup<br /> <br /> Use the control private_free callback to free the associated data<br /> block. This ensures that the memory won&amp;#39;t leak, whatever way the<br /> control gets destroyed.<br /> <br /> The original implementation didn&amp;#39;t actually remove the ALSA<br /> controls in hda_cs_dsp_control_remove(). It only freed the internal<br /> tracking structure. This meant it was possible to remove/unload the<br /> amp driver while leaving its ALSA controls still present in the<br /> soundcard. Obviously attempting to access them could cause segfaults<br /> or at least dereferencing stale pointers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nci: Fix uninit-value in nci_rx_work<br /> <br /> syzbot reported the following uninit-value access issue [1]<br /> <br /> nci_rx_work() parses received packet from ndev-&gt;rx_q. It should be<br /> validated header size, payload size and total packet size before<br /> processing the packet. If an invalid packet is detected, it should be<br /> silently discarded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline<br /> <br /> The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of<br /> interrupt affinity reconfiguration via procfs. Instead, the change is<br /> deferred until the next instance of the interrupt being triggered on the<br /> original CPU.<br /> <br /> When the interrupt next triggers on the original CPU, the new affinity is<br /> enforced within __irq_move_irq(). A vector is allocated from the new CPU,<br /> but the old vector on the original CPU remains and is not immediately<br /> reclaimed. Instead, apicd-&gt;move_in_progress is flagged, and the reclaiming<br /> process is delayed until the next trigger of the interrupt on the new CPU.<br /> <br /> Upon the subsequent triggering of the interrupt on the new CPU,<br /> irq_complete_move() adds a task to the old CPU&amp;#39;s vector_cleanup list if it<br /> remains online. Subsequently, the timer on the old CPU iterates over its<br /> vector_cleanup list, reclaiming old vectors.<br /> <br /> However, a rare scenario arises if the old CPU is outgoing before the<br /> interrupt triggers again on the new CPU.<br /> <br /> In that case irq_force_complete_move() is not invoked on the outgoing CPU<br /> to reclaim the old apicd-&gt;prev_vector because the interrupt isn&amp;#39;t currently<br /> affine to the outgoing CPU, and irq_needs_fixup() returns false. Even<br /> though __vector_schedule_cleanup() is later called on the new CPU, it<br /> doesn&amp;#39;t reclaim apicd-&gt;prev_vector; instead, it simply resets both<br /> apicd-&gt;move_in_progress and apicd-&gt;prev_vector to 0.<br /> <br /> As a result, the vector remains unreclaimed in vector_matrix, leading to a<br /> CPU vector leak.<br /> <br /> To address this issue, move the invocation of irq_force_complete_move()<br /> before the irq_needs_fixup() call to reclaim apicd-&gt;prev_vector, if the<br /> interrupt is currently or used to be affine to the outgoing CPU.<br /> <br /> Additionally, reclaim the vector in __vector_schedule_cleanup() as well,<br /> following a warning message, although theoretically it should never see<br /> apicd-&gt;move_in_progress with apicd-&gt;prev_cpu pointing to an offline CPU.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi: libstub: only free priv.runtime_map when allocated<br /> <br /> priv.runtime_map is only allocated when efi_novamap is not set.<br /> Otherwise, it is an uninitialized value. In the error path, it is freed<br /> unconditionally. Avoid passing an uninitialized value to free_pool.<br /> Free priv.runtime_map only when it was allocated.<br /> <br /> This bug was discovered and resolved using Coverity Static Analysis<br /> Security Testing (SAST) by Synopsys, Inc.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvlan: Dont Use skb-&gt;sk in ipvlan_process_v{4,6}_outbound<br /> <br /> Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will<br /> hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.<br /> <br /> WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70<br /> Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper<br /> CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:sk_mc_loop+0x2d/0x70<br /> Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c<br /> RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212<br /> RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001<br /> RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000<br /> RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00<br /> R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000<br /> R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000<br /> FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __warn (kernel/panic.c:693)<br /> ? sk_mc_loop (net/core/sock.c:760)<br /> ? report_bug (lib/bug.c:201 lib/bug.c:219)<br /> ? handle_bug (arch/x86/kernel/traps.c:239)<br /> ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))<br /> ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)<br /> ? sk_mc_loop (net/core/sock.c:760)<br /> ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))<br /> ? nf_hook_slow (net/netfilter/core.c:626)<br /> ip6_finish_output (net/ipv6/ip6_output.c:222)<br /> ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)<br /> ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan<br /> ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan<br /> dev_hard_start_xmit (net/core/dev.c:3594)<br /> sch_direct_xmit (net/sched/sch_generic.c:343)<br /> __qdisc_run (net/sched/sch_generic.c:416)<br /> net_tx_action (net/core/dev.c:5286)<br /> handle_softirqs (kernel/softirq.c:555)<br /> __irq_exit_rcu (kernel/softirq.c:589)<br /> sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)<br /> <br /> The warning triggers as this:<br /> packet_sendmsg<br /> packet_snd //skb-&gt;sk is packet sk<br /> __dev_queue_xmit<br /> __dev_xmit_skb //q-&gt;enqueue is not NULL<br /> __qdisc_run<br /> sch_direct_xmit<br /> dev_hard_start_xmit<br /> ipvlan_start_xmit<br /> ipvlan_xmit_mode_l3 //l3 mode<br /> ipvlan_process_outbound //vepa flag<br /> ipvlan_process_v6_outbound<br /> ip6_local_out<br /> __ip6_finish_output<br /> ip6_finish_output2 //multicast packet<br /> sk_mc_loop //sk-&gt;sk_family is AF_PACKET<br /> <br /> Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: taprio: extend minimum interval restriction to entire cycle too<br /> <br /> It is possible for syzbot to side-step the restriction imposed by the<br /> blamed commit in the Fixes: tag, because the taprio UAPI permits a<br /> cycle-time different from (and potentially shorter than) the sum of<br /> entry intervals.<br /> <br /> We need one more restriction, which is that the cycle time itself must<br /> be larger than N * ETH_ZLEN bit times, where N is the number of schedule<br /> entries. This restriction needs to apply regardless of whether the cycle<br /> time came from the user or was the implicit, auto-calculated value, so<br /> we move the existing "cycle == 0" check outside the "if "(!new-&gt;cycle_time)"<br /> branch. This way covers both conditions and scenarios.<br /> <br /> Add a selftest which illustrates the issue triggered by syzbot.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: cyapa - add missing input core locking to suspend/resume functions<br /> <br /> Grab input-&gt;mutex during suspend/resume functions like it is done in<br /> other input drivers. This fixes the following warning during system<br /> suspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c<br /> Modules linked in: ...<br /> CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109<br /> Hardware name: Samsung Exynos (Flattened Device Tree)<br /> Workqueue: events_unbound async_run_entry_fn<br /> unwind_backtrace from show_stack+0x10/0x14<br /> show_stack from dump_stack_lvl+0x58/0x70<br /> dump_stack_lvl from __warn+0x1a8/0x1cc<br /> __warn from warn_slowpath_fmt+0x18c/0x1b4<br /> warn_slowpath_fmt from input_device_enabled+0x68/0x6c<br /> input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc<br /> cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c<br /> cyapa_reinitialize from cyapa_resume+0x48/0x98<br /> cyapa_resume from dpm_run_callback+0x90/0x298<br /> dpm_run_callback from device_resume+0xb4/0x258<br /> device_resume from async_resume+0x20/0x64<br /> async_resume from async_run_entry_fn+0x40/0x15c<br /> async_run_entry_fn from process_scheduled_works+0xbc/0x6a8<br /> process_scheduled_works from worker_thread+0x188/0x454<br /> worker_thread from kthread+0x108/0x140<br /> kthread from ret_from_fork+0x14/0x28<br /> Exception stack(0xf1625fb0 to 0xf1625ff8)<br /> ...<br /> ---[ end trace 0000000000000000 ]---<br /> ...<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c<br /> Modules linked in: ...<br /> CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109<br /> Hardware name: Samsung Exynos (Flattened Device Tree)<br /> Workqueue: events_unbound async_run_entry_fn<br /> unwind_backtrace from show_stack+0x10/0x14<br /> show_stack from dump_stack_lvl+0x58/0x70<br /> dump_stack_lvl from __warn+0x1a8/0x1cc<br /> __warn from warn_slowpath_fmt+0x18c/0x1b4<br /> warn_slowpath_fmt from input_device_enabled+0x68/0x6c<br /> input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc<br /> cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c<br /> cyapa_reinitialize from cyapa_resume+0x48/0x98<br /> cyapa_resume from dpm_run_callback+0x90/0x298<br /> dpm_run_callback from device_resume+0xb4/0x258<br /> device_resume from async_resume+0x20/0x64<br /> async_resume from async_run_entry_fn+0x40/0x15c<br /> async_run_entry_fn from process_scheduled_works+0xbc/0x6a8<br /> process_scheduled_works from worker_thread+0x188/0x454<br /> worker_thread from kthread+0x108/0x140<br /> kthread from ret_from_fork+0x14/0x28<br /> Exception stack(0xf1625fb0 to 0xf1625ff8)<br /> ...<br /> ---[ end trace 0000000000000000 ]---

The Themify – WooCommerce Product Filter plugin for WordPress is vulnerable to time-based SQL Injection via the ‘conditions’ parameter in all versions up to, and including, 1.4.9 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

IBM i 7.3, 7.4, and 7.5 product IBM TCP/IP Connectivity Utilities for i contains a local privilege escalation vulnerability. A malicious actor with command line access to the host operating system can elevate privileges to gain root access to the host operating system. IBM X-Force ID: 288171.

The Online Booking &amp; Scheduling Calendar for WordPress by vcita plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the ‘d’ parameter in all versions up to, and including, 4.4.2 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.

The Booking for Appointments and Events Calendar – Amelia plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 1.1.5 (and 7.5.1 for the Pro version) due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.