Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ravb: Fix use-after-free issue in ravb_tx_timeout_work()<br /> <br /> The ravb_stop() should call cancel_work_sync(). Otherwise,<br /> ravb_tx_timeout_work() is possible to use the freed priv after<br /> ravb_remove() was called like below:<br /> <br /> CPU0 CPU1<br /> ravb_tx_timeout()<br /> ravb_remove()<br /> unregister_netdev()<br /> free_netdev(ndev)<br /> // free priv<br /> ravb_tx_timeout_work()<br /> // use priv<br /> <br /> unregister_netdev() will call .ndo_stop() so that ravb_stop() is<br /> called. And, after phy_stop() is called, netif_carrier_off()<br /> is also called. So that .ndo_tx_timeout() will not be called<br /> after phy_stop().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ieee802154: ca8210: Fix a potential UAF in ca8210_probe<br /> <br /> If of_clk_add_provider() fails in ca8210_register_ext_clock(),<br /> it calls clk_unregister() to release priv-&gt;clk and returns an<br /> error. However, the caller ca8210_probe() then calls ca8210_remove(),<br /> where priv-&gt;clk is freed again in ca8210_unregister_ext_clock(). In<br /> this case, a use-after-free may happen in the second time we call<br /> clk_unregister().<br /> <br /> Fix this by removing the first clk_unregister(). Also, priv-&gt;clk could<br /> be an error code on failure of clk_register_fixed_rate(). Use<br /> IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().

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.

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 /> 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 /> net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()<br /> <br /> Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.<br /> <br /> Getting a reference on the socket found in a lookup while<br /> holding a lock should happen before releasing the lock.<br /> <br /> nfc_llcp_sock_get_sn() has a similar problem.<br /> <br /> Finally nfc_llcp_recv_snl() needs to make sure the socket<br /> found by nfc_llcp_sock_from_sn() does not disappear.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid()<br /> <br /> The nvme_fc_fcp_op structure describing an AEN operation is initialized with a<br /> null request structure pointer. An FC LLDD may make a call to<br /> nvme_fc_io_getuuid passing a pointer to an nvmefc_fcp_req for an AEN operation.<br /> <br /> Add validation of the request structure pointer before dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: nuvoton: wpcm450: fix out of bounds write<br /> <br /> Write into &amp;#39;pctrl-&gt;gpio_bank&amp;#39; happens before the check for GPIO index<br /> validity, so out of bounds write may happen.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

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 /> spi: sun6i: reduce DMA RX transfer width to single byte<br /> <br /> Through empirical testing it has been determined that sometimes RX SPI<br /> transfers with DMA enabled return corrupted data. This is down to single<br /> or even multiple bytes lost during DMA transfer from SPI peripheral to<br /> memory. It seems the RX FIFO within the SPI peripheral can become<br /> confused when performing bus read accesses wider than a single byte to it<br /> during an active SPI transfer.<br /> <br /> This patch reduces the width of individual DMA read accesses to the<br /> RX FIFO to a single byte to mitigate that issue.

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.