Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: Fix connection failure handling<br /> <br /> In case immediate MPA request processing fails, the newly<br /> created endpoint unlinks the listening endpoint and is<br /> ready to be dropped. This special case was not handled<br /> correctly by the code handling the later TCP socket close,<br /> causing a NULL dereference crash in siw_cm_work_handler()<br /> when dereferencing a NULL listener. We now also cancel<br /> the useless MPA timeout, if immediate MPA request<br /> processing fails.<br /> <br /> This patch furthermore simplifies MPA processing in general:<br /> Scheduling a useless TCP socket read in sk_data_ready() upcall<br /> is now surpressed, if the socket is already moved out of<br /> TCP_ESTABLISHED state.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/srp: Do not call scsi_done() from srp_abort()<br /> <br /> After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler<br /> callback, it performs one of the following actions:<br /> * Call scsi_queue_insert().<br /> * Call scsi_finish_command().<br /> * Call scsi_eh_scmd_add().<br /> Hence, SCSI abort handlers must not call scsi_done(). Otherwise all<br /> the above actions would trigger a use-after-free. Hence remove the<br /> scsi_done() call from srp_abort(). Keep the srp_free_req() call<br /> before returning SUCCESS because we may not see the command again if<br /> SUCCESS is returned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-debug: don&amp;#39;t call __dma_entry_alloc_check_leak() under free_entries_lock<br /> <br /> __dma_entry_alloc_check_leak() calls into printk -&gt; serial console<br /> output (qcom geni) and grabs port-&gt;lock under free_entries_lock<br /> spin lock, which is a reverse locking dependency chain as qcom_geni<br /> IRQ handler can call into dma-debug code and grab free_entries_lock<br /> under port-&gt;lock.<br /> <br /> Move __dma_entry_alloc_check_leak() call out of free_entries_lock<br /> scope so that we don&amp;#39;t acquire serial console&amp;#39;s port-&gt;lock under it.<br /> <br /> Trimmed-down lockdep splat:<br /> <br /> The existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #2 (free_entries_lock){-.-.}-{2:2}:<br /> _raw_spin_lock_irqsave+0x60/0x80<br /> dma_entry_alloc+0x38/0x110<br /> debug_dma_map_page+0x60/0xf8<br /> dma_map_page_attrs+0x1e0/0x230<br /> dma_map_single_attrs.constprop.0+0x6c/0xc8<br /> geni_se_rx_dma_prep+0x40/0xcc<br /> qcom_geni_serial_isr+0x310/0x510<br /> __handle_irq_event_percpu+0x110/0x244<br /> handle_irq_event_percpu+0x20/0x54<br /> handle_irq_event+0x50/0x88<br /> handle_fasteoi_irq+0xa4/0xcc<br /> handle_irq_desc+0x28/0x40<br /> generic_handle_domain_irq+0x24/0x30<br /> gic_handle_irq+0xc4/0x148<br /> do_interrupt_handler+0xa4/0xb0<br /> el1_interrupt+0x34/0x64<br /> el1h_64_irq_handler+0x18/0x24<br /> el1h_64_irq+0x64/0x68<br /> arch_local_irq_enable+0x4/0x8<br /> ____do_softirq+0x18/0x24<br /> ...<br /> <br /> -&gt; #1 (&amp;port_lock_key){-.-.}-{2:2}:<br /> _raw_spin_lock_irqsave+0x60/0x80<br /> qcom_geni_serial_console_write+0x184/0x1dc<br /> console_flush_all+0x344/0x454<br /> console_unlock+0x94/0xf0<br /> vprintk_emit+0x238/0x24c<br /> vprintk_default+0x3c/0x48<br /> vprintk+0xb4/0xbc<br /> _printk+0x68/0x90<br /> register_console+0x230/0x38c<br /> uart_add_one_port+0x338/0x494<br /> qcom_geni_serial_probe+0x390/0x424<br /> platform_probe+0x70/0xc0<br /> really_probe+0x148/0x280<br /> __driver_probe_device+0xfc/0x114<br /> driver_probe_device+0x44/0x100<br /> __device_attach_driver+0x64/0xdc<br /> bus_for_each_drv+0xb0/0xd8<br /> __device_attach+0xe4/0x140<br /> device_initial_probe+0x1c/0x28<br /> bus_probe_device+0x44/0xb0<br /> device_add+0x538/0x668<br /> of_device_add+0x44/0x50<br /> of_platform_device_create_pdata+0x94/0xc8<br /> of_platform_bus_create+0x270/0x304<br /> of_platform_populate+0xac/0xc4<br /> devm_of_platform_populate+0x60/0xac<br /> geni_se_probe+0x154/0x160<br /> platform_probe+0x70/0xc0<br /> ...<br /> <br /> -&gt; #0 (console_owner){-...}-{0:0}:<br /> __lock_acquire+0xdf8/0x109c<br /> lock_acquire+0x234/0x284<br /> console_flush_all+0x330/0x454<br /> console_unlock+0x94/0xf0<br /> vprintk_emit+0x238/0x24c<br /> vprintk_default+0x3c/0x48<br /> vprintk+0xb4/0xbc<br /> _printk+0x68/0x90<br /> dma_entry_alloc+0xb4/0x110<br /> debug_dma_map_sg+0xdc/0x2f8<br /> __dma_map_sg_attrs+0xac/0xe4<br /> dma_map_sgtable+0x30/0x4c<br /> get_pages+0x1d4/0x1e4 [msm]<br /> msm_gem_pin_pages_locked+0x38/0xac [msm]<br /> msm_gem_pin_vma_locked+0x58/0x88 [msm]<br /> msm_ioctl_gem_submit+0xde4/0x13ac [msm]<br /> drm_ioctl_kernel+0xe0/0x15c<br /> drm_ioctl+0x2e8/0x3f4<br /> vfs_ioctl+0x30/0x50<br /> ...<br /> <br /> Chain exists of:<br /> console_owner --&gt; &amp;port_lock_key --&gt; free_entries_lock<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(free_entries_lock);<br /> lock(&amp;port_lock_key);<br /> lock(free_entries_lock);<br /> lock(console_owner);<br /> <br /> *** DEADLOCK ***<br /> <br /> Call trace:<br /> dump_backtrace+0xb4/0xf0<br /> show_stack+0x20/0x30<br /> dump_stack_lvl+0x60/0x84<br /> dump_stack+0x18/0x24<br /> print_circular_bug+0x1cc/0x234<br /> check_noncircular+0x78/0xac<br /> __lock_acquire+0xdf8/0x109c<br /> lock_acquire+0x234/0x284<br /> console_flush_all+0x330/0x454<br /> consol<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain<br /> <br /> Previously the transfer complete IRQ immediately drained to RX FIFO to<br /> read any data remaining in FIFO to the RX buffer. This behaviour is<br /> correct when dealing with SPI in interrupt mode. However in DMA mode the<br /> transfer complete interrupt still fires as soon as all bytes to be<br /> transferred have been stored in the FIFO. At that point data in the FIFO<br /> still needs to be picked up by the DMA engine. Thus the drain procedure<br /> and DMA engine end up racing to read from RX FIFO, corrupting any data<br /> read. Additionally the RX buffer pointer is never adjusted according to<br /> DMA progress in DMA mode, thus calling the RX FIFO drain procedure in DMA<br /> mode is a bug.<br /> Fix corruptions in DMA RX mode by draining RX FIFO only in interrupt mode.<br /> Also wait for completion of RX DMA when in DMA mode before returning to<br /> ensure all data has been copied to the supplied memory buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_codec: Fix leaking content of local_codecs<br /> <br /> The following memory leak can be observed when the controller supports<br /> codecs which are stored in local_codecs list but the elements are never<br /> freed:<br /> <br /> unreferenced object 0xffff88800221d840 (size 32):<br /> comm "kworker/u3:0", pid 36, jiffies 4294898739 (age 127.060s)<br /> hex dump (first 32 bytes):<br /> f8 d3 02 03 80 88 ff ff 80 d8 21 02 80 88 ff ff ..........!.....<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc+0x47/0x120<br /> [] hci_codec_list_add.isra.0+0x2d/0x160<br /> [] hci_read_codec_capabilities+0x183/0x270<br /> [] hci_read_supported_codecs+0x1bb/0x2d0<br /> [] hci_read_local_codecs_sync+0x3e/0x60<br /> [] hci_dev_open_sync+0x943/0x11e0<br /> [] hci_power_on+0x10d/0x3f0<br /> [] process_one_work+0x404/0x800<br /> [] worker_thread+0x374/0x670<br /> [] kthread+0x188/0x1c0<br /> [] ret_from_fork+0x2b/0x50<br /> [] ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt: fix memory overlapping when deleting chars in the buffer<br /> <br /> A memory overlapping copy occurs when deleting a long line. This memory<br /> overlapping copy can cause data corruption when scr_memcpyw is optimized<br /> to memcpy because memcpy does not ensure its behavior if the destination<br /> buffer overlaps with the source buffer. The line buffer is not always<br /> broken, because the memcpy utilizes the hardware acceleration, whose<br /> result is not deterministic.<br /> <br /> Fix this problem by using replacing the scr_memcpyw with scr_memmovew.

The Ultimate Bootstrap Elements for Elementor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘heading_title_tag’ and ’heading_sub_title_tag’ parameters in all versions up to, and including, 1.3.6 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Master Slider – Responsive Touch Slider plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin&amp;#39;s ms_slide shortcode in all versions up to, and including, 3.9.10 due to insufficient input sanitization and output escaping on the &amp;#39;src&amp;#39; user supplied attributes. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Master Slider – Responsive Touch Slider plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the slides callback functionality in all versions up to, and including, 3.9.9. This makes it possible for authenticated attackers, with editor-level access, 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.

The Master Slider – Responsive Touch Slider plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 3.9.10. This is due to missing or incorrect nonce validation on the &amp;#39;process_bulk_action&amp;#39; function. This makes it possible for unauthenticated attackers to duplicate or delete arbitrary sliders via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. CVE-2023-50900 and CVE-2024-6490 may be a duplicate of this issue.

The AI Engine: Chatbots, Generators, Assistants, GPT 4 and more! plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the AI chat data when discussion tracking is enabled in all versions up to, and including, 2.2.0 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.