Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix transaction abort when snapshotting received subvolumes<br /> <br /> Currently a user can trigger a transaction abort by snapshotting a<br /> previously received snapshot a bunch of times until we reach a<br /> BTRFS_UUID_KEY_RECEIVED_SUBVOL item overflow (the maximum item size we<br /> can store in a leaf). This is very likely not common in practice, but<br /> if it happens, it turns the filesystem into RO mode. The snapshot, send<br /> and set_received_subvol and subvol_setflags (used by receive) don&amp;#39;t<br /> require CAP_SYS_ADMIN, just inode_owner_or_capable(). A malicious user<br /> could use this to turn a filesystem into RO mode and disrupt a system.<br /> <br /> Reproducer script:<br /> <br /> $ cat test.sh<br /> #!/bin/bash<br /> <br /> DEV=/dev/sdi<br /> MNT=/mnt/sdi<br /> <br /> # Use smallest node size to make the test faster.<br /> mkfs.btrfs -f --nodesize 4K $DEV<br /> mount $DEV $MNT<br /> <br /> # Create a subvolume and set it to RO so that it can be used for send.<br /> btrfs subvolume create $MNT/sv<br /> touch $MNT/sv/foo<br /> btrfs property set $MNT/sv ro true<br /> <br /> # Send and receive the subvolume into snaps/sv.<br /> mkdir $MNT/snaps<br /> btrfs send $MNT/sv | btrfs receive $MNT/snaps<br /> <br /> # Now snapshot the received subvolume, which has a received_uuid, a<br /> # lot of times to trigger the leaf overflow.<br /> total=500<br /> for ((i = 1; i /dev/null<br /> done<br /> echo<br /> <br /> umount $MNT<br /> <br /> When running the test:<br /> <br /> $ ./test.sh<br /> (...)<br /> Create subvolume &amp;#39;/mnt/sdi/sv&amp;#39;<br /> At subvol /mnt/sdi/sv<br /> At subvol sv<br /> Creating snapshot 496/500ERROR: Could not create subvolume: Value too large for defined data type<br /> Creating snapshot 497/500ERROR: Could not create subvolume: Read-only file system<br /> Creating snapshot 498/500ERROR: Could not create subvolume: Read-only file system<br /> Creating snapshot 499/500ERROR: Could not create subvolume: Read-only file system<br /> Creating snapshot 500/500ERROR: Could not create subvolume: Read-only file system<br /> <br /> And in dmesg/syslog:<br /> <br /> $ dmesg<br /> (...)<br /> [251067.627338] BTRFS warning (device sdi): insert uuid item failed -75 (0x4628b21c4ac8d898, 0x2598bee2b1515c91) type 252!<br /> [251067.629212] ------------[ cut here ]------------<br /> [251067.630033] BTRFS: Transaction aborted (error -75)<br /> [251067.630871] WARNING: fs/btrfs/transaction.c:1907 at create_pending_snapshot.cold+0x52/0x465 [btrfs], CPU#10: btrfs/615235<br /> [251067.632851] Modules linked in: btrfs dm_zero (...)<br /> [251067.644071] CPU: 10 UID: 0 PID: 615235 Comm: btrfs Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full)<br /> [251067.646165] Tainted: [W]=WARN<br /> [251067.646733] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014<br /> [251067.648735] RIP: 0010:create_pending_snapshot.cold+0x55/0x465 [btrfs]<br /> [251067.649984] Code: f0 48 0f (...)<br /> [251067.653313] RSP: 0018:ffffce644908fae8 EFLAGS: 00010292<br /> [251067.653987] RAX: 00000000ffffff01 RBX: ffff8e5639e63a80 RCX: 00000000ffffffd3<br /> [251067.655042] RDX: ffff8e53faa76b00 RSI: 00000000ffffffb5 RDI: ffffffffc0919750<br /> [251067.656077] RBP: ffffce644908fbd8 R08: 0000000000000000 R09: ffffce644908f820<br /> [251067.657068] R10: ffff8e5adc1fffa8 R11: 0000000000000003 R12: ffff8e53c0431bd0<br /> [251067.658050] R13: ffff8e5414593600 R14: ffff8e55efafd000 R15: 00000000ffffffb5<br /> [251067.659019] FS: 00007f2a4944b3c0(0000) GS:ffff8e5b27dae000(0000) knlGS:0000000000000000<br /> [251067.660115] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [251067.660943] CR2: 00007ffc5aa57898 CR3: 00000005813a2003 CR4: 0000000000370ef0<br /> [251067.661972] Call Trace:<br /> [251067.662292] <br /> [251067.662653] create_pending_snapshots+0x97/0xc0 [btrfs]<br /> [251067.663413] btrfs_commit_transaction+0x26e/0xc00 [btrfs]<br /> [251067.664257] ? btrfs_qgroup_convert_reserved_meta+0x35/0x390 [btrfs]<br /> [251067.665238] ? _raw_spin_unlock+0x15/0x30<br /> [251067.665837] ? record_root_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: mipi-i3c-hci: Fix race in DMA ring dequeue<br /> <br /> The HCI DMA dequeue path (hci_dma_dequeue_xfer()) may be invoked for<br /> multiple transfers that timeout around the same time. However, the<br /> function is not serialized and can race with itself.<br /> <br /> When a timeout occurs, hci_dma_dequeue_xfer() stops the ring, processes<br /> incomplete transfers, and then restarts the ring. If another timeout<br /> triggers a parallel call into the same function, the two instances may<br /> interfere with each other - stopping or restarting the ring at unexpected<br /> times.<br /> <br /> Add a mutex so that hci_dma_dequeue_xfer() is serialized with respect to<br /> itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Eagerly init vgic dist/redist on vgic creation<br /> <br /> If vgic_allocate_private_irqs_locked() fails for any odd reason,<br /> we exit kvm_vgic_create() early, leaving dist-&gt;rd_regions uninitialised.<br /> <br /> kvm_vgic_dist_destroy() then comes along and walks into the weeds<br /> trying to free the RDs. Got to love this stuff.<br /> <br /> Solve it by moving all the static initialisation early, and make<br /> sure that if we fail halfway, we&amp;#39;re in a reasonable shape to<br /> perform the rest of the teardown. While at it, reset the vgic model<br /> on failure, just in case...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: mipi-i3c-hci: Correct RING_CTRL_ABORT handling in DMA dequeue<br /> <br /> The logic used to abort the DMA ring contains several flaws:<br /> <br /> 1. The driver unconditionally issues a ring abort even when the ring has<br /> already stopped.<br /> 2. The completion used to wait for abort completion is never<br /> re-initialized, resulting in incorrect wait behavior.<br /> 3. The abort sequence unintentionally clears RING_CTRL_ENABLE, which<br /> resets hardware ring pointers and disrupts the controller state.<br /> 4. If the ring is already stopped, the abort operation should be<br /> considered successful without attempting further action.<br /> <br /> Fix the abort handling by checking whether the ring is running before<br /> issuing an abort, re-initializing the completion when needed, ensuring that<br /> RING_CTRL_ENABLE remains asserted during abort, and treating an already<br /> stopped ring as a successful condition.

RELATE is a web-based courseware package. Prior to commit 2f68e16, there is a timing attack vulnerability in course/auth.py — check_sign_in_key(). This issue has been patched via commit 2f68e16.

ZEBRA is a Zcash node written entirely in Rust. From zebrad versions 2.2.0 to before 4.3.1 and from zebra-rpc versions 1.0.0-beta.45 to before 6.0.2, a vulnerability in Zebra&amp;#39;s JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response. This issue has been patched in zebrad version 4.3.1 and zebra-rpc version 6.0.2.

ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.1 and prior to zebra-chain version 6.0.2, Orchard transactions contain a rk field which is a randomized validating key and also an elliptic curve point. The Zcash specification allows the field to be the identity (a "zero" value), however, the orchard crate which is used to verify Orchard proofs would panic when fed a rk with the identity value. Thus an attacker could send a crafted transaction that would make a Zebra node crash. This issue has been patched in zebrad version 4.3.1 and zebra-chain version 6.0.2.

ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.1 and prior to zebra-script version 5.0.2, after a refactoring, Zebra failed to validate a consensus rule that restricted the possible values of sighash hash types for V5 transactions which were enabled in the NU5 network upgrade. Zebra nodes could thus accept and eventually mine a block that would be considered invalid by zcashd nodes, creating a consensus split between Zebra and zcashd nodes. In a similar vein, for V4 transactions, Zebra mistakenly used the "canonical" hash type when computing the sighash while zcashd (correctly per the spec) uses the raw value, which could also crate a consensus split. This issue has been patched in zebrad version 4.3.1 and zebra-script version 5.0.2.

Brave CMS is an open-source CMS. Prior to commit 6c56603, the contact form is publicly accessible (no authentication required). User-supplied message text is passed through PHP&amp;#39;s nl2br() function, which converts newlines to tags but does not escape HTML. The resulting string is then passed to a Blade email template using the unescaped {!! $msg !!} directive. The resulting content is then rendered in a Blade email template using the unescaped {!! $msg !!} directive. Because HTML is not sanitized, arbitrary markup can be injected into the email body. While modern HTML-capable email clients (Gmail or Outlook Web) typically block JavaScript execution, they still render HTML content. This allows attackers to craft convincing phishing interfaces inside the email sent to the administrator. This issue has been patched via commit 6c56603.

Nhost is an open source Firebase alternative with GraphQL. Prior to version 0.49.1, Nhost automatically links an incoming OAuth identity to an existing Nhost account when the email addresses match. This is only safe when the email has been verified by the OAuth provider. Nhost&amp;#39;s controller trusts a profile.EmailVerified boolean that is set by each provider adapter. The vulnerability is that several provider adapters do not correctly populate this field they either silently drop a verified field the provider API actually returns (Discord), or they fall back to accepting unconfirmed emails and marking them as verified (Bitbucket). Two Microsoft providers (AzureAD, EntraID) derive the email from non-ownership-proving fields like the user principal name, then mark it verified. The result is that an attacker can present an email they don&amp;#39;t own to Nhost, have the OAuth identity merged into the victim&amp;#39;s account, and receive a full authenticated session. This issue has been patched in version 0.49.1.

In th30d4y/IP from version 1.0.1 to before version 2.0.1, a DOM-Based Cross-Site Scripting (XSS) vulnerability was identified in an IP Reputation Checker application. Unsanitized user input was directly rendered in the browser, allowing attackers to execute arbitrary JavaScript. This issue has been patched in version 2.0.1.

PHPUnit is a testing framework for PHP. In versions 12.5.21 and 13.1.5, PHPUnit forwards PHP INI settings to child processes (used for isolated/PHPT test execution) as -d name=value command-line arguments without neutralizing INI metacharacters. Because PHP&amp;#39;s INI parser interprets " as a string delimiter, ; as the start of a comment, and most importantly a newline as a directive separator, a value containing a newline is parsed by the child process as multiple INI directives. An attacker able to influence a single INI value can therefore inject arbitrary additional directives into the child&amp;#39;s configuration, including auto_prepend_file, extension, disable_functions, open_basedir, and others. Setting auto_prepend_file to an attacker-controlled path yields remote code execution in the child process. This issue has been patched in versions 12.5.22 and 13.1.6.