Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: detach gendisk from ublk device if add_disk() fails<br /> <br /> Inside ublk_abort_requests(), gendisk is grabbed for aborting all<br /> inflight requests. And ublk_abort_requests() is called when exiting<br /> the uring context or handling timeout.<br /> <br /> If add_disk() fails, the gendisk may have been freed when calling<br /> ublk_abort_requests(), so use-after-free can be caused when getting<br /> disk&amp;#39;s reference in ublk_abort_requests().<br /> <br /> Fixes the bug by detaching gendisk from ublk device if add_disk() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries/vas: Add close() callback in vas_vm_ops struct<br /> <br /> The mapping VMA address is saved in VAS window struct when the<br /> paste address is mapped. This VMA address is used during migration<br /> to unmap the paste address if the window is active. The paste<br /> address mapping will be removed when the window is closed or with<br /> the munmap(). But the VMA address in the VAS window is not updated<br /> with munmap() which is causing invalid access during migration.<br /> <br /> The KASAN report shows:<br /> [16386.254991] BUG: KASAN: slab-use-after-free in reconfig_close_windows+0x1a0/0x4e8<br /> [16386.255043] Read of size 8 at addr c00000014a819670 by task drmgr/696928<br /> <br /> [16386.255096] CPU: 29 UID: 0 PID: 696928 Comm: drmgr Kdump: loaded Tainted: G B 6.11.0-rc5-nxgzip #2<br /> [16386.255128] Tainted: [B]=BAD_PAGE<br /> [16386.255148] Hardware name: IBM,9080-HEX Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.00 (NH1110_016) hv:phyp pSeries<br /> [16386.255181] Call Trace:<br /> [16386.255202] [c00000016b297660] [c0000000018ad0ac] dump_stack_lvl+0x84/0xe8 (unreliable)<br /> [16386.255246] [c00000016b297690] [c0000000006e8a90] print_report+0x19c/0x764<br /> [16386.255285] [c00000016b297760] [c0000000006e9490] kasan_report+0x128/0x1f8<br /> [16386.255309] [c00000016b297880] [c0000000006eb5c8] __asan_load8+0xac/0xe0<br /> [16386.255326] [c00000016b2978a0] [c00000000013f898] reconfig_close_windows+0x1a0/0x4e8<br /> [16386.255343] [c00000016b297990] [c000000000140e58] vas_migration_handler+0x3a4/0x3fc<br /> [16386.255368] [c00000016b297a90] [c000000000128848] pseries_migrate_partition+0x4c/0x4c4<br /> ...<br /> <br /> [16386.256136] Allocated by task 696554 on cpu 31 at 16377.277618s:<br /> [16386.256149] kasan_save_stack+0x34/0x68<br /> [16386.256163] kasan_save_track+0x34/0x80<br /> [16386.256175] kasan_save_alloc_info+0x58/0x74<br /> [16386.256196] __kasan_slab_alloc+0xb8/0xdc<br /> [16386.256209] kmem_cache_alloc_noprof+0x200/0x3d0<br /> [16386.256225] vm_area_alloc+0x44/0x150<br /> [16386.256245] mmap_region+0x214/0x10c4<br /> [16386.256265] do_mmap+0x5fc/0x750<br /> [16386.256277] vm_mmap_pgoff+0x14c/0x24c<br /> [16386.256292] ksys_mmap_pgoff+0x20c/0x348<br /> [16386.256303] sys_mmap+0xd0/0x160<br /> ...<br /> <br /> [16386.256350] Freed by task 0 on cpu 31 at 16386.204848s:<br /> [16386.256363] kasan_save_stack+0x34/0x68<br /> [16386.256374] kasan_save_track+0x34/0x80<br /> [16386.256384] kasan_save_free_info+0x64/0x10c<br /> [16386.256396] __kasan_slab_free+0x120/0x204<br /> [16386.256415] kmem_cache_free+0x128/0x450<br /> [16386.256428] vm_area_free_rcu_cb+0xa8/0xd8<br /> [16386.256441] rcu_do_batch+0x2c8/0xcf0<br /> [16386.256458] rcu_core+0x378/0x3c4<br /> [16386.256473] handle_softirqs+0x20c/0x60c<br /> [16386.256495] do_softirq_own_stack+0x6c/0x88<br /> [16386.256509] do_softirq_own_stack+0x58/0x88<br /> [16386.256521] __irq_exit_rcu+0x1a4/0x20c<br /> [16386.256533] irq_exit+0x20/0x38<br /> [16386.256544] interrupt_async_exit_prepare.constprop.0+0x18/0x2c<br /> ...<br /> <br /> [16386.256717] Last potentially related work creation:<br /> [16386.256729] kasan_save_stack+0x34/0x68<br /> [16386.256741] __kasan_record_aux_stack+0xcc/0x12c<br /> [16386.256753] __call_rcu_common.constprop.0+0x94/0xd04<br /> [16386.256766] vm_area_free+0x28/0x3c<br /> [16386.256778] remove_vma+0xf4/0x114<br /> [16386.256797] do_vmi_align_munmap.constprop.0+0x684/0x870<br /> [16386.256811] __vm_munmap+0xe0/0x1f8<br /> [16386.256821] sys_munmap+0x54/0x6c<br /> [16386.256830] system_call_exception+0x1a0/0x4a0<br /> [16386.256841] system_call_vectored_common+0x15c/0x2ec<br /> <br /> [16386.256868] The buggy address belongs to the object at c00000014a819670<br /> which belongs to the cache vm_area_struct of size 168<br /> [16386.256887] The buggy address is located 0 bytes inside of<br /> freed 168-byte region [c00000014a819670, c00000014a819718)<br /> <br /> [16386.256915] The buggy address belongs to the physical page:<br /> [16386.256928] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14a81<br /> [16386.256950] memcg:c0000000ba430001<br /> [16386.256961] anon flags: 0x43ffff800000000(node=4|zone=0|lastcpupid=0x7ffff)<br /> [16386.256975] page_type: 0xfdffffff(slab)<br /> [16386<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/MSI: Handle lack of irqdomain gracefully<br /> <br /> Alexandre observed a warning emitted from pci_msi_setup_msi_irqs() on a<br /> RISCV platform which does not provide PCI/MSI support:<br /> <br /> WARNING: CPU: 1 PID: 1 at drivers/pci/msi/msi.h:121 pci_msi_setup_msi_irqs+0x2c/0x32<br /> __pci_enable_msix_range+0x30c/0x596<br /> pci_msi_setup_msi_irqs+0x2c/0x32<br /> pci_alloc_irq_vectors_affinity+0xb8/0xe2<br /> <br /> RISCV uses hierarchical interrupt domains and correctly does not implement<br /> the legacy fallback. The warning triggers from the legacy fallback stub.<br /> <br /> That warning is bogus as the PCI/MSI layer knows whether a PCI/MSI parent<br /> domain is associated with the device or not. There is a check for MSI-X,<br /> which has a legacy assumption. But that legacy fallback assumption is only<br /> valid when legacy support is enabled, but otherwise the check should simply<br /> return -ENOTSUPP.<br /> <br /> Loongarch tripped over the same problem and blindly enabled legacy support<br /> without implementing the legacy fallbacks. There are weak implementations<br /> which return an error, so the problem was papered over.<br /> <br /> Correct pci_msi_domain_supports() to evaluate the legacy mode and add<br /> the missing supported check into the MSI enable path to complete it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fred: Clear WFE in missing-ENDBRANCH #CPs<br /> <br /> An indirect branch instruction sets the CPU indirect branch tracker<br /> (IBT) into WAIT_FOR_ENDBRANCH (WFE) state and WFE stays asserted<br /> across the instruction boundary. When the decoder finds an<br /> inappropriate instruction while WFE is set ENDBR, the CPU raises a #CP<br /> fault.<br /> <br /> For the "kernel IBT no ENDBR" selftest where #CPs are deliberately<br /> triggered, the WFE state of the interrupted context needs to be<br /> cleared to let execution continue. Otherwise when the CPU resumes<br /> from the instruction that just caused the previous #CP, another<br /> missing-ENDBRANCH #CP is raised and the CPU enters a dead loop.<br /> <br /> This is not a problem with IDT because it doesn&amp;#39;t preserve WFE and<br /> IRET doesn&amp;#39;t set WFE. But FRED provides space on the entry stack<br /> (in an expanded CS area) to save and restore the WFE state, thus the<br /> WFE state is no longer clobbered, so software must clear it.<br /> <br /> Clear WFE to avoid dead looping in ibt_clear_fred_wfe() and the<br /> !ibt_fatal code path when execution is allowed to continue.<br /> <br /> Clobbering WFE in any other circumstance is a security-relevant bug.<br /> <br /> [ dhansen: changelog rewording ]

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 /> Bluetooth: btusb: mediatek: add intf release flow when usb disconnect<br /> <br /> MediaTek claim an special usb intr interface for ISO data transmission.<br /> The interface need to be released before unregistering hci device when<br /> usb disconnect. Removing BT usb dongle without properly releasing the<br /> interface may cause Kernel panic while unregister hci device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: check folio mapping after unlock in relocate_one_folio()<br /> <br /> When we call btrfs_read_folio() to bring a folio uptodate, we unlock the<br /> folio. The result of that is that a different thread can modify the<br /> mapping (like remove it with invalidate) before we call folio_lock().<br /> This results in an invalid page and we need to try again.<br /> <br /> In particular, if we are relocating concurrently with aborting a<br /> transaction, this can result in a crash like the following:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP<br /> CPU: 76 PID: 1411631 Comm: kworker/u322:5<br /> Workqueue: events_unbound btrfs_reclaim_bgs_work<br /> RIP: 0010:set_page_extent_mapped+0x20/0xb0<br /> RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246<br /> RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880<br /> RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0<br /> R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000<br /> R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff<br /> FS: 0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die+0x78/0xc0<br /> ? page_fault_oops+0x2a8/0x3a0<br /> ? __switch_to+0x133/0x530<br /> ? wq_worker_running+0xa/0x40<br /> ? exc_page_fault+0x63/0x130<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? set_page_extent_mapped+0x20/0xb0<br /> relocate_file_extent_cluster+0x1a7/0x940<br /> relocate_data_extent+0xaf/0x120<br /> relocate_block_group+0x20f/0x480<br /> btrfs_relocate_block_group+0x152/0x320<br /> btrfs_relocate_chunk+0x3d/0x120<br /> btrfs_reclaim_bgs_work+0x2ae/0x4e0<br /> process_scheduled_works+0x184/0x370<br /> worker_thread+0xc6/0x3e0<br /> ? blk_add_timer+0xb0/0xb0<br /> kthread+0xae/0xe0<br /> ? flush_tlb_kernel_range+0x90/0x90<br /> ret_from_fork+0x2f/0x40<br /> ? flush_tlb_kernel_range+0x90/0x90<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> <br /> This occurs because cleanup_one_transaction() calls<br /> destroy_delalloc_inodes() which calls invalidate_inode_pages2() which<br /> takes the folio_lock before setting mapping to NULL. We fail to check<br /> this, and subsequently call set_extent_mapping(), which assumes that<br /> mapping != NULL (in fact it asserts that in debug mode)<br /> <br /> Note that the "fixes" patch here is not the one that introduced the<br /> race (the very first iteration of this code from 2009) but a more recent<br /> change that made this particular crash happen in practice.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix use-after-free when COWing tree bock and tracing is enabled<br /> <br /> When a COWing a tree block, at btrfs_cow_block(), and we have the<br /> tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled<br /> (CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent<br /> buffer while inside the tracepoint code. This is because in some paths<br /> that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding<br /> the last reference on the extent buffer @buf so btrfs_force_cow_block()<br /> drops the last reference on the @buf extent buffer when it calls<br /> free_extent_buffer_stale(buf), which schedules the release of the extent<br /> buffer with RCU. This means that if we are on a kernel with preemption,<br /> the current task may be preempted before calling trace_btrfs_cow_block()<br /> and the extent buffer already released by the time trace_btrfs_cow_block()<br /> is called, resulting in a use-after-free.<br /> <br /> Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to<br /> btrfs_force_cow_block() before the COWed extent buffer is freed.<br /> This also has a side effect of invoking the tracepoint in the tree defrag<br /> code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is<br /> called there, but this is fine and it was actually missing there.

Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to 7.0.8, a large input buffer to the to_lowercase, to_uppercase, strip_whitespace, compress_whitespace, dotprefix, header_lowercase, strip_pseudo_headers, url_decode, or xor transform can lead to a stack overflow causing Suricata to crash. The issue has been addressed in Suricata 7.0.8.

IBM UrbanCode Deploy (UCD) 7.2 through 7.2.3.13, 7.3 through 7.3.2.8, and IBM DevOps Deploy 8.0 through 8.0.1.3 are vulnerable to HTML injection. This vulnerability may allow a user to embed arbitrary HTML tags in the Web UI potentially leading to sensitive information disclosure.

Dell PowerScale OneFS 8.2.2.x through 9.8.0.x contains an incorrect permission assignment for critical resource vulnerability. A locally authenticated attacker could potentially exploit this vulnerability, leading to denial of service.

A flaw was found in FFmpeg&amp;#39;s HLS demuxer. This vulnerability allows bypassing unsafe file extension checks and triggering arbitrary demuxers via base64-encoded data URIs appended with specific file extensions.