CVE-2026-31411 Affecting kernel-uek-modules-usb package, versions <0:6.12.0-202.76.4.1.el10uek


Severity

Recommended
high

Based on Oracle Linux security rating.

Threat Intelligence

EPSS
0.04% (11th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-ORACLE10-KERNELUEKMODULESUSB-16693137
  • published14 May 2026
  • disclosed8 Apr 2026

Introduced: 8 Apr 2026

CVE-2026-31411  (opens in a new tab)

How to fix?

Upgrade Oracle:10 kernel-uek-modules-usb to version 0:6.12.0-202.76.4.1.el10uek or higher.
This issue was patched in ELSA-2026-50260.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-uek-modules-usb package and not the kernel-uek-modules-usb package as distributed by Oracle. See How to fix? for Oracle:10 relevant fixed versions and status.

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

net: atm: fix crash due to unvalidated vcc pointer in sigd_send()

Reproducer available at 1.

The ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged:

int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0);
ioctl(fd, ATMSIGD_CTRL);  // become ATM signaling daemon
struct msghdr msg = { .msg_iov = &amp;iov, ... };
*(unsigned long *)(buf + 4) = 0xdeadbeef;  // fake vcc pointer
sendmsg(fd, &amp;msg, 0);  // kernel dereferences 0xdeadbeef

In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigd_enq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values.

Fix this by introducing find_get_vcc() which validates the pointer by searching through vcc_hash (similar to how sigd_close() iterates over all VCCs), and acquires a reference via sock_hold() if found.

Since struct atm_vcc embeds struct sock as its first member, they share the same lifetime. Therefore using sock_hold/sock_put is sufficient to keep the vcc alive while it is being used.

Note that there may be a race with sigd_close() which could mark the vcc with various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns. However, sock_hold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety.

CVSS Base Scores

version 3.1