Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Validate command buffer payload count<br /> <br /> The count field in the command header is used to determine the valid<br /> payload size. Verify that the valid payload does not exceed the remaining<br /> buffer space.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Fix ID register initialization for non-protected pKVM guests<br /> <br /> In protected mode, the hypervisor maintains a separate instance of<br /> the `kvm` structure for each VM. For non-protected VMs, this structure is<br /> initialized from the host&amp;#39;s `kvm` state.<br /> <br /> Currently, `pkvm_init_features_from_host()` copies the<br /> `KVM_ARCH_FLAG_ID_REGS_INITIALIZED` flag from the host without the<br /> underlying `id_regs` data being initialized. This results in the<br /> hypervisor seeing the flag as set while the ID registers remain zeroed.<br /> <br /> Consequently, `kvm_has_feat()` checks at EL2 fail (return 0) for<br /> non-protected VMs. This breaks logic that relies on feature detection,<br /> such as `ctxt_has_tcrx()` for TCR2_EL1 support. As a result, certain<br /> system registers (e.g., TCR2_EL1, PIR_EL1, POR_EL1) are not<br /> saved/restored during the world switch, which could lead to state<br /> corruption.<br /> <br /> Fix this by explicitly copying the ID registers from the host `kvm` to<br /> the hypervisor `kvm` for non-protected VMs during initialization, since<br /> we trust the host with its non-protected guests&amp;#39; features. Also ensure<br /> `KVM_ARCH_FLAG_ID_REGS_INITIALIZED` is cleared initially in<br /> `pkvm_init_features_from_host` so that `vm_copy_id_regs` can properly<br /> initialize them and set the flag once done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/logicvc: Fix device node reference leak in logicvc_drm_config_parse()<br /> <br /> The logicvc_drm_config_parse() function calls of_get_child_by_name() to<br /> find the "layers" node but fails to release the reference, leading to a<br /> device node reference leak.<br /> <br /> Fix this by using the __free(device_node) cleanup attribute to automatic<br /> release the reference when the variable goes out of scope.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/reg_sr: Fix leak on xa_store failure<br /> <br /> Free the newly allocated entry when xa_store() fails to avoid a memory<br /> leak on the error path.<br /> <br /> v2: use goto fail_free. (Bala)<br /> <br /> (cherry picked from commit 6bc6fec71ac45f52db609af4e62bdb96b9f5fadb)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: Fix circular locking dependency in rds_tcp_tune<br /> <br /> syzbot reported a circular locking dependency in rds_tcp_tune() where<br /> sk_net_refcnt_upgrade() is called while holding the socket lock:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> ======================================================<br /> kworker/u10:8/15040 is trying to acquire lock:<br /> ffffffff8e9aaf80 (fs_reclaim){+.+.}-{0:0},<br /> at: __kmalloc_cache_noprof+0x4b/0x6f0<br /> <br /> but task is already holding lock:<br /> ffff88805a3c1ce0 (k-sk_lock-AF_INET6){+.+.}-{0:0},<br /> at: rds_tcp_tune+0xd7/0x930<br /> <br /> The issue occurs because sk_net_refcnt_upgrade() performs memory<br /> allocation (via get_net_track() -&gt; ref_tracker_alloc()) while the<br /> socket lock is held, creating a circular dependency with fs_reclaim.<br /> <br /> Fix this by moving sk_net_refcnt_upgrade() outside the socket lock<br /> critical section. This is safe because the fields modified by the<br /> sk_net_refcnt_upgrade() call (sk_net_refcnt, ns_tracker) are not<br /> accessed by any concurrent code path at this point.<br /> <br /> v2:<br /> - Corrected fixes tag<br /> - check patch line wrap nits<br /> - ai commentary nits

Zohocorp ManageEngine Exchange Reporter Plus versions before 5802 are vulnerable to Stored XSS in Permissions Based on Mailboxes report.

A vulnerability was identified in Casdoor 2.356.0. Affected by this issue is some unknown functionality of the component OAuth Authorization Request Handler. Such manipulation of the argument redirect_uri leads to open redirect. It is possible to launch the attack remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.

Zohocorp ManageEngine Exchange Reporter Plus versions before 5802 are vulnerable to Stored XSS in Non-Owner Mailbox Permission report.

Zohocorp ManageEngine Exchange Reporter Plus versions before 5802 are vulnerable to Stored XSS in Folder Message Count and Size report.

Zohocorp ManageEngine Exchange Reporter Plus versions before 5802 are vulnerable to Stored XSS in Public Folder Client Permissions report.

Zohocorp ManageEngine Exchange Reporter Plus versions before 5802 are vulnerable to Stored XSS in Equipment Mailbox Details report.

Zohocorp ManageEngine Exchange Reporter Plus versions before 5802 are vulnerable to Stored XSS in Mails Exchanged Between Users report.