Vulnerabilities

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.

A flaw was found in FFmpeg. This vulnerability allows unexpected additional CPU load and storage consumption, potentially leading to degraded performance or denial of service via the demuxing of arbitrary data as XBIN-formatted data without proper format validation.

A flaw was found in FFmpeg&amp;#39;s DASH playlist support. This vulnerability allows arbitrary HTTP GET requests to be made on behalf of the machine running FFmpeg via a crafted DASH playlist containing malicious URLs.

tgstation-server is a production scale tool for BYOND server management. Prior to 6.12.3, roles used to authorize API methods were incorrectly OR&amp;#39;d instead of AND&amp;#39;ed with the role used to determine if a user was enabled. This allows enabled users access to most, but not all, authorized actions regardless of their permissions. Notably, the WriteUsers right is unaffected so users may not use this bug to permanently elevate their account permissions. The fix is release in tgstation-server-v6.12.3.