Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ila: block BH in ila_output()<br /> <br /> As explained in commit 1378817486d6 ("tipc: block BH<br /> before using dst_cache"), net/core/dst_cache.c<br /> helpers need to be called with BH disabled.<br /> <br /> ila_output() is called from lwtunnel_output()<br /> possibly from process context, and under rcu_read_lock().<br /> <br /> We might be interrupted by a softirq, re-enter ila_output()<br /> and corrupt dst_cache data structures.<br /> <br /> Fix the race by using local_bh_disable().

Twisted is an event-based framework for internet applications, supporting Python 3.6+. The HTTP 1.0 and 1.1 server provided by twisted.web could process pipelined HTTP requests out-of-order, possibly resulting in information disclosure. This vulnerability is fixed in 24.7.0rc1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: avoid double free special payload<br /> <br /> If a discard request needs to be retried, and that retry may fail before<br /> a new special payload is added, a double free will result. Clear the<br /> RQF_SPECIAL_LOAD when the request is cleaned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: scrub: handle RST lookup error correctly<br /> <br /> [BUG]<br /> When running btrfs/060 with forced RST feature, it would crash the<br /> following ASSERT() inside scrub_read_endio():<br /> <br /> ASSERT(sector_nr nr_sectors);<br /> <br /> Before that, we would have tree dump from<br /> btrfs_get_raid_extent_offset(), as we failed to find the RST entry for<br /> the range.<br /> <br /> [CAUSE]<br /> Inside scrub_submit_extent_sector_read() every time we allocated a new<br /> bbio we immediately called btrfs_map_block() to make sure there was some<br /> RST range covering the scrub target.<br /> <br /> But if btrfs_map_block() fails, we immediately call endio for the bbio,<br /> while the bbio is newly allocated, it&amp;#39;s completely empty.<br /> <br /> Then inside scrub_read_endio(), we go through the bvecs to find<br /> the sector number (as bi_sector is no longer reliable if the bio is<br /> submitted to lower layers).<br /> <br /> And since the bio is empty, such bvecs iteration would not find any<br /> sector matching the sector, and return sector_nr == stripe-&gt;nr_sectors,<br /> triggering the ASSERT().<br /> <br /> [FIX]<br /> Instead of calling btrfs_map_block() after allocating a new bbio, call<br /> btrfs_map_block() first.<br /> <br /> Since our only objective of calling btrfs_map_block() is only to update<br /> stripe_len, there is really no need to do that after btrfs_alloc_bio().<br /> <br /> This new timing would avoid the problem of handling empty bbio<br /> completely, and in fact fixes a possible race window for the old code,<br /> where if the submission thread is the only owner of the pending_io, the<br /> scrub would never finish (since we didn&amp;#39;t decrease the pending_io<br /> counter).<br /> <br /> Although the root cause of RST lookup failure still needs to be<br /> addressed.

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 /> drm/radeon: check bo_va-&gt;bo is non-NULL before using it<br /> <br /> The call to radeon_vm_clear_freed might clear bo_va-&gt;bo, so<br /> we have to check it before dereferencing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bluetooth/l2cap: sync sock recv cb and release<br /> <br /> The problem occurs between the system call to close the sock and hci_rx_work,<br /> where the former releases the sock and the latter accesses it without lock protection.<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> sock_close hci_rx_work<br /> l2cap_sock_release hci_acldata_packet<br /> l2cap_sock_kill l2cap_recv_frame<br /> sk_free l2cap_conless_channel<br /> l2cap_sock_recv_cb<br /> <br /> If hci_rx_work processes the data that needs to be received before the sock is<br /> closed, then everything is normal; Otherwise, the work thread may access the<br /> released sock when receiving data.<br /> <br /> Add a chan mutex in the rx callback of the sock to achieve synchronization between<br /> the sock release and recv cb.<br /> <br /> Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_core: cancel all works upon hci_unregister_dev()<br /> <br /> syzbot is reporting that calling hci_release_dev() from hci_error_reset()<br /> due to hci_dev_put() from hci_error_reset() can cause deadlock at<br /> destroy_workqueue(), for hci_error_reset() is called from<br /> hdev-&gt;req_workqueue which destroy_workqueue() needs to flush.<br /> <br /> We need to make sure that hdev-&gt;{rx_work,cmd_work,tx_work} which are<br /> queued into hdev-&gt;workqueue and hdev-&gt;{power_on,error_reset} which are<br /> queued into hdev-&gt;req_workqueue are no longer running by the moment<br /> <br /> destroy_workqueue(hdev-&gt;workqueue);<br /> destroy_workqueue(hdev-&gt;req_workqueue);<br /> <br /> are called from hci_release_dev().<br /> <br /> Call cancel_work_sync() on these work items from hci_unregister_dev()<br /> as soon as hdev-&gt;list is removed from hci_dev_list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/eeh: avoid possible crash when edev-&gt;pdev changes<br /> <br /> If a PCI device is removed during eeh_pe_report_edev(), edev-&gt;pdev<br /> will change and can cause a crash, hold the PCI rescan/remove lock<br /> while taking a copy of edev-&gt;pdev-&gt;bus.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: Whitelist dtl slub object for copying to userspace<br /> <br /> Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*<br /> results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as<br /> shown below.<br /> <br /> kernel BUG at mm/usercopy.c:102!<br /> Oops: Exception in kernel mode, sig: 5 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc<br /> scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse<br /> CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85<br /> Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries<br /> NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8<br /> REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3)<br /> MSR: 8000000000029033 CR: 2828220f XER: 0000000e<br /> CFAR: c0000000001fdc80 IRQMASK: 0<br /> [ ... GPRs omitted ... ]<br /> NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0<br /> LR [c0000000005d23d0] usercopy_abort+0x74/0xb0<br /> Call Trace:<br /> usercopy_abort+0x74/0xb0 (unreliable)<br /> __check_heap_object+0xf8/0x120<br /> check_heap_object+0x218/0x240<br /> __check_object_size+0x84/0x1a4<br /> dtl_file_read+0x17c/0x2c4<br /> full_proxy_read+0x8c/0x110<br /> vfs_read+0xdc/0x3a0<br /> ksys_read+0x84/0x144<br /> system_call_exception+0x124/0x330<br /> system_call_vectored_common+0x15c/0x2ec<br /> --- interrupt: 3000 at 0x7fff81f3ab34<br /> <br /> Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")<br /> requires that only whitelisted areas in slab/slub objects can be copied to<br /> userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.<br /> Dtl contains hypervisor dispatch events which are expected to be read by<br /> privileged users. Hence mark this safe for user access.<br /> Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the<br /> entire object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: Add tx check to prevent skb leak<br /> <br /> Below is a summary of how the driver stores a reference to an skb during<br /> transmit:<br /> tx_buff[free_map[consumer_index]]-&gt;skb = new_skb;<br /> free_map[consumer_index] = IBMVNIC_INVALID_MAP;<br /> consumer_index ++;<br /> Where variable data looks like this:<br /> free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]<br /> consumer_index^<br /> tx_buff == [skb=null, skb=, skb=, skb=null, skb=null]<br /> <br /> The driver has checks to ensure that free_map[consumer_index] pointed to<br /> a valid index but there was no check to ensure that this index pointed<br /> to an unused/null skb address. So, if, by some chance, our free_map and<br /> tx_buff lists become out of sync then we were previously risking an<br /> skb memory leak. This could then cause tcp congestion control to stop<br /> sending packets, eventually leading to ETIMEDOUT.<br /> <br /> Therefore, add a conditional to ensure that the skb address is null. If<br /> not then warn the user (because this is still a bug that should be<br /> patched) and free the old pointer to prevent memleak/tcp problems.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: topology: Fix references to freed memory<br /> <br /> Most users after parsing a topology file, release memory used by it, so<br /> having pointer references directly into topology file contents is wrong.<br /> Use devm_kmemdup(), to allocate memory as needed.