Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1<br /> <br /> When allocating initialized blocks from a large unwritten extent, or<br /> when splitting an unwritten extent during end I/O and converting it to<br /> initialized, there is currently a potential issue of stale data if the<br /> extent needs to be split in the middle.<br /> <br /> 0 A B N<br /> [UUUUUUUUUUUU] U: unwritten extent<br /> [--DDDDDDDD--] D: valid data<br /> || ----&gt; this range needs to be initialized<br /> <br /> ext4_split_extent() first try to split this extent at B with<br /> EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but<br /> ext4_split_extent_at() failed to split this extent due to temporary lack<br /> of space. It zeroout B to N and mark the entire extent from 0 to N<br /> as written.<br /> <br /> 0 A B N<br /> [WWWWWWWWWWWW] W: written extent<br /> [SSDDDDDDDDZZ] Z: zeroed, S: stale data<br /> <br /> ext4_split_extent() then try to split this extent at A with<br /> EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left<br /> a stale written extent from 0 to A.<br /> <br /> 0 A B N<br /> [WW|WWWWWWWWWW]<br /> [SS|DDDDDDDDZZ]<br /> <br /> Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at()<br /> when splitting at B, don&amp;#39;t convert the entire extent to written and left<br /> it as unwritten after zeroing out B to N. The remaining work is just<br /> like the standard two-part split. ext4_split_extent() will pass the<br /> EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the<br /> second time, allowing it to properly handle the split. If the split is<br /> successful, it will keep extent from 0 to A as unwritten.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send<br /> <br /> ib_uverbs_post_send() uses cmd.wqe_size from userspace without any<br /> validation before passing it to kmalloc() and using the allocated<br /> buffer as struct ib_uverbs_send_wr.<br /> <br /> If a user provides a small wqe_size value (e.g., 1), kmalloc() will<br /> succeed, but subsequent accesses to user_wr-&gt;opcode, user_wr-&gt;num_sge,<br /> and other fields will read beyond the allocated buffer, resulting in<br /> an out-of-bounds read from kernel heap memory. This could potentially<br /> leak sensitive kernel information to userspace.<br /> <br /> Additionally, providing an excessively large wqe_size can trigger a<br /> WARNING in the memory allocation path, as reported by syzkaller.<br /> <br /> This is inconsistent with ib_uverbs_unmarshall_recv() which properly<br /> validates that wqe_size &gt;= sizeof(struct ib_uverbs_recv_wr) before<br /> proceeding.<br /> <br /> Add the same validation for ib_uverbs_post_send() to ensure wqe_size<br /> is at least sizeof(struct ib_uverbs_send_wr).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix double free in rxe_srq_from_init<br /> <br /> In rxe_srq_from_init(), the queue pointer &amp;#39;q&amp;#39; is assigned to<br /> &amp;#39;srq-&gt;rq.queue&amp;#39; before copying the SRQ number to user space.<br /> If copy_to_user() fails, the function calls rxe_queue_cleanup()<br /> to free the queue, but leaves the now-invalid pointer in<br /> &amp;#39;srq-&gt;rq.queue&amp;#39;.<br /> <br /> The caller of rxe_srq_from_init() (rxe_create_srq) eventually<br /> calls rxe_srq_cleanup() upon receiving the error, which triggers<br /> a second rxe_queue_cleanup() on the same memory, leading to a<br /> double free.<br /> <br /> The call trace looks like this:<br /> kmem_cache_free+0x.../0x...<br /> rxe_queue_cleanup+0x1a/0x30 [rdma_rxe]<br /> rxe_srq_cleanup+0x42/0x60 [rdma_rxe]<br /> rxe_elem_release+0x31/0x70 [rdma_rxe]<br /> rxe_create_srq+0x12b/0x1a0 [rdma_rxe]<br /> ib_create_srq_user+0x9a/0x150 [ib_core]<br /> <br /> Fix this by moving &amp;#39;srq-&gt;rq.queue = q&amp;#39; after copy_to_user.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: remove WARN_ON_ONCE when accessing forward path array<br /> <br /> Although unlikely, recent support for IPIP tunnels increases chances of<br /> reaching this WARN_ON_ONCE if userspace manages to build a sufficiently<br /> long forward path.<br /> <br /> Remove it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix NULL sock in aa_sock_file_perm<br /> <br /> Deal with the potential that sock and sock-sk can be NULL during<br /> socket setup or teardown. This could lead to an oops. The fix for NULL<br /> pointer dereference in __unix_needs_revalidation shows this is at<br /> least possible for af_unix sockets. While the fix for af_unix sockets<br /> applies for newer mediation this is still the fall back path for older<br /> af_unix mediation and other sockets, so ensure it is covered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mscc: ocelot: add missing lock protection in ocelot_port_xmit_inj()<br /> <br /> ocelot_port_xmit_inj() calls ocelot_can_inject() and<br /> ocelot_port_inject_frame() without holding the injection group lock.<br /> Both functions contain lockdep_assert_held() for the injection lock,<br /> and the correct caller felix_port_deferred_xmit() properly acquires<br /> the lock using ocelot_lock_inj_grp() before calling these functions.<br /> <br /> Add ocelot_lock_inj_grp()/ocelot_unlock_inj_grp() around the register<br /> injection path to fix the missing lock protection. The FDMA path is not<br /> affected as it uses its own locking mechanism.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: skip ipv6 extension headers for csum checks<br /> <br /> Protocol checksum validation fails for IPv6 if there are extension<br /> headers before the protocol header. iph-&gt;len already contains its<br /> offset, so use it to fix the problem.

Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_ocsp module) allows forged OCSP responses signed with an expired responder certificate to be accepted as valid.<br /> <br /> OCSP response verification in pubkey_ocsp:verify_response/5 and pubkey_ocsp:is_authorized_responder/3 in lib/public_key/src/pubkey_ocsp.erl does not check the validity period (notBefore/notAfter) of the OCSP responder certificate. An attacker who has obtained the private key of an expired CA-designated OCSP responder certificate can forge OCSP responses that Erlang/OTP accepts as valid.<br /> <br /> This affects TLS clients using OCSP stapling via the ssl application: a malicious or compromised server can present a revoked TLS certificate together with a forged OCSP response signed by an expired responder key, and the client will accept the revoked certificate as valid. It also affects applications calling public_key:pkix_ocsp_validate/5 directly, where the impact depends on the use case — server-side client certificate validation using this API may allow authentication bypass with a revoked client certificate.<br /> <br /> This issue affects OTP from OTP 27.0 before OTP 27.3.4.12, 28.5.0.1, and 29.0.1 corresponding to public_key from 1.16 before 1.17.1.3, 1.20.3.1, and 1.21.1.

Improper Following of a Certificate&amp;#39;s Chain of Trust vulnerability in Erlang OTP public_key (pubkey_cert module) allows a non-CA certificate to be accepted as an intermediate issuer, enabling certificate chain forgery.<br /> <br /> In lib/public_key/src/pubkey_cert.erl, pubkey_cert:validate_extensions/7 contains two flaws that together allow a certificate with basicConstraints cA:false and no keyUsage extension to be used as an intermediate issuer in a chain passed to public_key:pkix_path_validation/3: the cA:false clause recurses into the remaining extensions without rejecting the certificate when it is in issuer position, and the keyUsage check only fires when the extension is present, so a certificate lacking keyUsage entirely bypasses the keyCertSign enforcement.<br /> <br /> Any party holding an end-entity certificate with basicConstraints cA:false and no keyUsage extension, issued by any CA in the victim&amp;#39;s trust store, can use that certificate&amp;#39;s private key to sign forged leaf certificates for arbitrary identities. public_key:pkix_path_validation/3 accepts the resulting chain, and by extension every TLS or mTLS endpoint built on the OTP ssl application that relies on the default verifier is affected, including server identity verification on the client side and client certificate verification on mTLS servers.<br /> <br /> This issue affects OTP from OTP 17.0 before OTP 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1 corresponding to public_key from 0.22 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.

IBM Cloud APM, Base Private 8.1.4 and IBM Cloud APM, Advanced Private 8.1.4 IBM Db2 for Linux, UNIX and Windows (includes DB2 Connect Server) could allow an authenticated user to cause a denial of service due to improper neutralization of special elements in the data query logic of the Fenced environment.

IBM Netezza Performance Server Replication Services 3.0.2.0 through 3.0.5.0 allows an attacker with low‑privileged access to escalate their privileges to root. By exploiting this flaw, the attacker can execute root‑level commands, obtain a root shell, and change the root user’s password. Successful exploitation also enables modification or removal of system‑wide files and the installation of persistent backdoors. This results in full system compromise with complete loss of confidentiality, integrity, and availability.

An issue in fetch_jpg() in xdrv_10_scripter.ino in Tasmota through 15.3.0.3 allows a remote attacker to cause heap buffer overflow. The Content-Length from a JPEG stream is stored in a uint16_t variable; values above 65535 wrap around, causing allocation of a smaller buffer than the data actually read.