Most recent entries from all

ALSA-2026:71329 — Important: kernel security update

Affected: AlmaLinux:8: bpftool, AlmaLinux:8: kernel, AlmaLinux:8: kernel-abi-stablelists, AlmaLinux:8: kernel-core, AlmaLinux:8: kernel-cross-headers, AlmaLinux:8: kernel-debug, AlmaLinux:8: kernel-debug-core, AlmaLinux:8: kernel-debug-devel, AlmaLinux:8: kernel-debug-modules, AlmaLinux:8: kernel-debug-modules-extra and 15 more

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib (CVE-2026-31566) * kernel: netfilter: nf_queue: hold bridge skb->dev while queued (CVE-2026-52912) * kernel: Linux kernel: PPPoE memory corruption via stale pointer (CVE-2026-68121) * kernel: Linux kernel IPVS: Denial of Service due to stale memory references (CVE-2026-80714) * kernel: nvme-tcp: reject a read that transferred too few bytes (CVE-2026-89480)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

BELL-CVE-2026-89480

Affected: Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

certfr-2026-avi-1230 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Red Hat. Certaines d'entre elles permettent à un…

certfr-2026-avi-1230

EUVD-2026-367591

fkie_cve-2026-89480

In the Linux kernel, the following vulnerability has been resolved:

nvme-tcp: reject a read that transferred too few bytes

nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above.

A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target.

Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against.

GHSA-p53f-q495-p25h

In the Linux kernel, the following vulnerability has been resolved:

nvme-tcp: reject a read that transferred too few bytes

openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media

kernel-devel-7.2.7-1.1 on GA media

RHSA-2026:71330 — Red Hat Security Advisory: kernel-rt security update

kernel: drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib kernel: netfilter: nf_queue: hold bridge skb->dev while queued kernel: pppoe: reload header pointer after dev_hard_header() kernel: ipvs: do not propagate one-packet flag to synced conns kernel: nvme-tcp: reject a read that transferred too few bytes

RLSA-2026:71329 — Important: kernel security update

Affected: Rocky Linux:8: kernel

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ib (CVE-2026-31566)

* kernel: netfilter: nf_queue: hold bridge skb->dev while queued (CVE-2026-52912)

* kernel: Linux kernel: PPPoE memory corruption via stale pointer (CVE-2026-68121)

* kernel: Linux kernel IPVS: Denial of Service due to stale memory references (CVE-2026-80714)

* kernel: nvme-tcp: reject a read that transferred too few bytes (CVE-2026-89480)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

UBUNTU-CVE-2026-89480

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 219 more

In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: reject a read that transferred too few bytes nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above. A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target. Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against.

WID-SEC-W-2026-3321 — Linux Kernel: Mehrere Schwachstellen

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsmaßnahmen zu umgehen, Daten oder den Systemzustand zu manipulieren, Denial-of-Service-Zustände herbeizuführen oder andere, nicht näher spezifizierte Angriffe durchzuführen.