CVE-2026-74296

RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one

7.8 HighFix available

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

RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one

Free the UAR index returned by the hardware.

Attack profile

How easy it is to exploit

Attack vector: Local
Complexity: Low
Privileges needed: Low
User interaction: None

What an attacker can affect

Confidentiality: High
Integrity: High
Availability: High

Exploit likelihood

0.18%Unchanged since Aug 15, 2026

What each source reports

CVE List Score used 7.8

RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one

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

RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one

Free the UAR index returned by the hardware.

Record: CVE-2026-74296
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

EUVDEUVD-2026-59443 7.8

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

RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one

Free the UAR index returned by the hardware.

Record: EUVD-2026-59443
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

GitHub AdvisoriesGHSA-vvjm-q4pr-4r6c 7.8

In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Release the HW...

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

RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one

Free the UAR index returned by the hardware.

Record: GHSA-vvjm-q4pr-4r6c
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

NVD 7.8

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

RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one

Free the UAR index returned by the hardware.

Record: CVE-2026-74296
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVBELL-CVE-2026-74296 7.8

Record: BELL-CVE-2026-74296
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSV 7.8

RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one

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

RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one

Free the UAR index returned by the hardware.

Record: CVE-2026-74296
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

Show 26 moreShow less

OSVDEBIAN-CVE-2026-74296 7.8

In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one Free the UAR index returned by the hardware.

Record: DEBIAN-CVE-2026-74296
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2026-3705 9.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison

The local-vs-remote region comparison loop uses '<=' instead of '<', causing it to read one entry past the valid range of qr_regions. The other loops in the same function correctly use '<'.

Fix the loop condition to use '<' for consistency and correctness.(CVE-2026-53309)

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

ixgbevf: fix use-after-free in VEPA multicast source pruning

ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor:

dev_kfree_skb_irq(skb);
continue;

The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing skb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context.

The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here.

I do not have ixgbevf hardware; the bug was found by static analysis (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags):

BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90)

QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)

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

sctp: validate STALE_COOKIE cause length before reading staleness

When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header:

err   = (struct sctp_errhdr *)(chunk-&gt;skb-&gt;data);
stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));

err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory.

sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded.

The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.(CVE-2026-64551)

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

libceph: fix two unsafe bare decodes in decode_lockers()

decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads:

ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0,…

Record: OESA-2026-3705
CVSS 3.1: 9.8 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2026-3706 9.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:net: af_can: do not leave a dangling sk pointer in can_create()On error can_create() frees the allocated sk object, but sock_init_data()has already attached it to the provided sock object. This will leave adangling sk pointer in the sock object and may cause use-after-free later.(CVE-2024-56603)

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

hdlc_ppp: sync per-proto timers before freeing hdlc state

Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol().

The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free.

Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown.

Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice.

This bug was found by static analysis.(CVE-2026-63803)

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

parport: Fix race between port and client registration

The parport subsystem registers port devices before they are fully initialised, resulting in a race condition where client drivers such as lp can attach to ports that are not completely initialised or even being torn down.

When the port and client drivers are built as modules and loaded around the same time during boot, this occasionally results in a crash. I was able to make this happen reliably in a VM with a PC-style parallel port by patching parport_pc to fail probing:

> --- a/drivers/parport/parport_pc.c > +++ b/drivers/parport/parport_pc.c > @@ -2069,7 +2069,7 @@ static struct parport *__parport_pc_probe_port(unsigned long int base, > if (!p) > goto out3; > > - base_res = request_region(base, 3, p->name); > + base_res = NULL; > if (!base_res) > goto out4; >

and then running:

while true; do
    modprobe lp &amp; modprobe parport_pc
wait
rmmod lp parport_pc
done

for a few seconds.

In the long term I think port registration should be changed to put the call to device_add() inside parport_announce_port(), but since the latter currently cannot fail this will require changing all port drivers.

For now, add a flag to indicate…

Record: OESA-2026-3706
CVSS 3.1: 9.8 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVUBUNTU-CVE-2026-74296 6.9

In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one Free the UAR index returned by the hardware.

Record: UBUNTU-CVE-2026-74296
CVSS 4.0: 6.9 MediumCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-10

OSVopenSUSE-SU-2026:21910-1 No score