UBUNTU-CVE-2026-90079: Medium severity ubuntu/linux-hwe-edge vulnerability

Q: Which systems are most likely to encounter this issue?

Systems using the affected Ubuntu Linux kernel packages and OcteonTX2 AF mailbox handling are relevant. The problematic second initialization occurs when SR-IOV is enabled, after AF-PF mailboxes were initialized during device probe.

Q: What condition triggers the unsafe lifetime and cleanup behavior?

The issue is triggered by repeated rvu_mbox_init() calls: one during probe for AF-PF mailboxes and another when SR-IOV enables AF-VF mailboxes. An AF-VF initialization failure can then unwind shared resources incorrectly while AF-PF mailbox memory remains live.

Q: Are systems that do not use SR-IOV affected by the repeated initialization path?

The described repeated initialization occurs when SR-IOV is enabled for AF-VF mailboxes. Without that second initialization path, the specific AF-VF-related overwrite, mutex reinitialization, and failure-unwind scenario is not described.

Q: What can be done if an updated kernel cannot be deployed immediately?

Avoid enabling SR-IOV on the affected OcteonTX2 setup, since enabling it invokes the AF-VF mailbox initialization path. This does not replace applying the kernel fix.

Published Sep 17, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: fix cn20k mailbox lifetime on repeated rvumboxinit() rvumboxinit() is called separately for AF-PF mailboxes during probe and for AF-VF mailboxes when SR-IOV is enabled. Each call used to allocate a new ngrvu object, leaking the first allocation when the pointer was overwritten on the second call. Sharing one ngrvu across both paths exposed several teardown bugs: the error path freed all cn20k mailbox DMA and kfree()d ngrvu even when only the failing init type should be unwound, leaving live AF-PF mailbox memory in use after an AF-VF init failure. mutexinit() was also re-run on the AF-VF path while AF-PF mailbox handlers could still hold rvu->mboxlock. Probe and SR-IOV failure paths did not release cn20k mailbox DMA either, since cleanup only happened in rvuremove(). Allocate ngrvu once with devmkzalloc(), initialize mboxlock in the same block, unwind only the mailbox memory for the failing init type, and free cn20k mailbox DMA from the probe and pcienablesriov() error paths.

Affected Software

128 affected componentsFixes available

ubuntu/linux-hwe-edge*

ubuntu/linux-aws-5.0*

ubuntu/linux-aws-5.3*

ubuntu/linux-azure*

ubuntu/linux-azure-5.3*

ubuntu/linux-azure-edge*

ubuntu/linux-gcp*

ubuntu/linux-gcp-5.3*

ubuntu/linux-gke-4.15*

ubuntu/linux-gke-5.4*

ubuntu/linux-gkeop-5.4*

ubuntu/linux-hwe*

ubuntu/linux-hwe-edge*

ubuntu/linux-oem*

ubuntu/linux-oracle-5.0*

ubuntu/linux-oracle-5.3*

ubuntu/linux-aws-5.11*

ubuntu/linux-aws-5.13*

ubuntu/linux-aws-5.8*

ubuntu/linux-azure-5.11*

ubuntu/linux-azure-5.13*

ubuntu/linux-azure-5.8*

ubuntu/linux-azure-fde*

ubuntu/linux-gcp-5.11*

ubuntu/linux-gcp-5.13*

ubuntu/linux-gcp-5.8*

ubuntu/linux-gke*

ubuntu/linux-gke-5.15*

ubuntu/linux-gkeop*

ubuntu/linux-gkeop-5.15*

ubuntu/linux-hwe-5.11*

ubuntu/linux-hwe-5.13*

ubuntu/linux-hwe-5.8*

ubuntu/linux-intel-5.13*

ubuntu/linux-oem-5.10*

ubuntu/linux-oem-5.13*

ubuntu/linux-oem-5.6*

ubuntu/linux-oracle-5.11*

ubuntu/linux-oracle-5.13*

ubuntu/linux-oracle-5.8*

ubuntu/linux-raspi2*

ubuntu/linux-riscv*

ubuntu/linux-riscv-5.11*

ubuntu/linux-riscv-5.8*

ubuntu/linux-allwinner-5.19*

ubuntu/linux-aws-5.19*

ubuntu/linux-aws-6.2*

ubuntu/linux-aws-6.5*

ubuntu/linux-azure-5.19*

ubuntu/linux-azure-6.2*

ubuntu/linux-azure-6.5*

ubuntu/linux-azure-fde-5.19*

ubuntu/linux-azure-fde-6.2*

ubuntu/linux-gcp-5.19*

ubuntu/linux-gcp-6.2*

ubuntu/linux-gcp-6.5*

ubuntu/linux-hwe-5.19*

ubuntu/linux-hwe-6.2*

ubuntu/linux-hwe-6.5*

ubuntu/linux-intel-iot-realtime*

ubuntu/linux-lowlatency-hwe-5.19*

ubuntu/linux-lowlatency-hwe-6.2*

ubuntu/linux-lowlatency-hwe-6.5*

ubuntu/linux-nvidia-6.2*

ubuntu/linux-nvidia-6.5*

ubuntu/linux-oem-5.17*

ubuntu/linux-oem-6.0*

ubuntu/linux-oem-6.1*

ubuntu/linux-oem-6.5*

ubuntu/linux-oracle-6.5*

ubuntu/linux-realtime*

ubuntu/linux-riscv*

ubuntu/linux-riscv-5.19*

ubuntu/linux-riscv-6.5*

ubuntu/linux-starfive-5.19*

ubuntu/linux-starfive-6.2*

ubuntu/linux-starfive-6.5*

ubuntu/linux-aws-6.14*

ubuntu/linux-aws-6.17*

ubuntu/linux-aws-7.0*

ubuntu/linux-azure-6.11*

ubuntu/linux-azure-6.14*

ubuntu/linux-azure-6.17*

ubuntu/linux-azure-7.0*

ubuntu/linux-azure-fde-6.14*

ubuntu/linux-azure-fde-6.17*

ubuntu/linux-azure-fde-7.0*

ubuntu/linux-azure-nvidia-6.14*

ubuntu/linux-gcp-6.11*

ubuntu/linux-gcp-6.14*

ubuntu/linux-gcp-7.0*

ubuntu/linux-hwe-6.11*

ubuntu/linux-hwe-6.14*

ubuntu/linux-hwe-6.17*

ubuntu/linux-hwe-7.0<7.0.0-42.42~24.04.1

7.0.0-42.42~24.04.1

ubuntu/linux-lowlatency-hwe-6.11*

ubuntu/linux-nvidia-6.11*

ubuntu/linux-nvidia-6.17*

ubuntu/linux-nvidia-7.0*

ubuntu/linux-oem-6.11*

ubuntu/linux-oem-6.14*

ubuntu/linux-oem-6.17*

ubuntu/linux-oem-6.8*

ubuntu/linux-oracle-6.14*

ubuntu/linux-oracle-6.17*

ubuntu/linux-oracle-7.0*

ubuntu/linux-raspi-realtime*

ubuntu/linux-realtime*

ubuntu/linux-riscv*

ubuntu/linux-riscv-6.14*

ubuntu/linux-riscv-6.17*

ubuntu/linux-riscv-7.0<7.0.0-42.42.1~24.04.1

7.0.0-42.42.1~24.04.1

ubuntu/linux-realtime-6.14*

ubuntu/linux-realtime-6.17*

ubuntu/linux<7.0.0-42.42

7.0.0-42.42

ubuntu/linux-aws<7.0.0-1016.17

7.0.0-1016.17

ubuntu/linux-azure*

ubuntu/linux-azure-fde*

ubuntu/linux-gcp<7.0.0-1016.18

7.0.0-1016.18

ubuntu/linux-gke*

ubuntu/linux-ibm<7.0.0-1017.17

7.0.0-1017.17

ubuntu/linux-nvidia*

ubuntu/linux-nvidia-bos*

ubuntu/linux-oem-7.0<7.0.0-1017.17

7.0.0-1017.17

ubuntu/linux-oracle<7.0.0-1015.16

7.0.0-1015.16

ubuntu/linux-raspi*

ubuntu/linux-realtime*

ubuntu/linux-riscv<7.0.0-42.42.1

7.0.0-42.42.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade ubuntu/linux-hwe-7.0 to a version that resolves this vulnerability.
Fixed in 7.0.0-42.42~24.04.1
Upgrade
Upgrade ubuntu/linux-riscv-7.0 to a version that resolves this vulnerability.
Fixed in 7.0.0-42.42.1~24.04.1
Upgrade
Upgrade ubuntu/linux to a version that resolves this vulnerability.
Fixed in 7.0.0-42.42
Upgrade
Upgrade ubuntu/linux-aws to a version that resolves this vulnerability.
Fixed in 7.0.0-1016.17
Upgrade
Upgrade ubuntu/linux-gcp to a version that resolves this vulnerability.
Fixed in 7.0.0-1016.18
Upgrade
Upgrade ubuntu/linux-ibm to a version that resolves this vulnerability.
Fixed in 7.0.0-1017.17
Upgrade
Upgrade ubuntu/linux-oem-7.0 to a version that resolves this vulnerability.
Fixed in 7.0.0-1017.17
Upgrade
Upgrade ubuntu/linux-oracle to a version that resolves this vulnerability.
Fixed in 7.0.0-1015.16
Upgrade
Upgrade ubuntu/linux-riscv to a version that resolves this vulnerability.
Fixed in 7.0.0-42.42.1
Compensating control
Allocate ng_rvu once with devm_kzalloc(), initialize mbox_lock in the same allocation block, and do not re-run mutex_init() on the AF-VF initialization path.
Compensating control
On a failing rvu_mbox_init() type, unwind only that type's mailbox memory instead of freeing all cn20k mailbox DMA or ng_rvu shared by the other mailbox type.
Compensating control
Free cn20k mailbox DMA in the probe error path and in pci_enable_sriov() error paths, not only in rvu_remove().

Event History

Sep 17, 2026

CVE Published

via OSV·05:16 PM

Data Sourced

via OSV·05:16 PM

DescriptionSeverityAffected Software

Frequently Asked Questions

Which systems are most likely to encounter this issue?

Systems using the affected Ubuntu Linux kernel packages and OcteonTX2 AF mailbox handling are relevant. The problematic second initialization occurs when SR-IOV is enabled, after AF-PF mailboxes were initialized during device probe.

What condition triggers the unsafe lifetime and cleanup behavior?

The issue is triggered by repeated rvu_mbox_init() calls: one during probe for AF-PF mailboxes and another when SR-IOV enables AF-VF mailboxes. An AF-VF initialization failure can then unwind shared resources incorrectly while AF-PF mailbox memory remains live.

Are systems that do not use SR-IOV affected by the repeated initialization path?

The described repeated initialization occurs when SR-IOV is enabled for AF-VF mailboxes. Without that second initialization path, the specific AF-VF-related overwrite, mutex reinitialization, and failure-unwind scenario is not described.

What can be done if an updated kernel cannot be deployed immediately?

Avoid enabling SR-IOV on the affected OcteonTX2 setup, since enabling it invokes the AF-VF mailbox initialization path. This does not replace applying the kernel fix.

UBUNTU-CVE-2026-90079: Medium severity ubuntu/linux-hwe-edge vulnerability

Affected Software

Remediation

Event History

Frequently Asked Questions

Which systems are most likely to encounter this issue?

What condition triggers the unsafe lifetime and cleanup behavior?

Are systems that do not use SR-IOV affected by the repeated initialization path?

What can be done if an updated kernel cannot be deployed immediately?

Company

Resources

Contact

Frequently Asked Questions

Which systems are most likely to encounter this issue?

What condition triggers the unsafe lifetime and cleanup behavior?

Are systems that do not use SR-IOV affected by the repeated initialization path?

What can be done if an updated kernel cannot be deployed immediately?