CVE-2021-22555

Published Jul 7, 2021

Last updated 6 months ago

Overview

Description
A heap out-of-bounds write affecting Linux since v2.6.19-rc1 was discovered in net/netfilter/x_tables.c. This allows an attacker to gain privileges or cause a DoS (via heap memory corruption) through user name space
Source
cve-coordination@google.com
NVD status
Analyzed
Products
c400_firmware, c250_firmware, h410c_firmware, h300s_firmware, h500s_firmware, h700s_firmware, h410s_firmware, linux_kernel, fabric_operating_system, fas_8300_firmware, fas_8700_firmware, aff_a400_firmware, aff_a250_firmware, aff_500f_firmware, h610c_firmware, h610s_firmware, h615c_firmware, cloud_backup, hci_management_node, solidfire, solidfire_baseboard_management_controller

Risk scores

CVSS 3.1

Type
Primary
Base score
7.8
Impact score
5.9
Exploitability score
1.8
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Severity
HIGH

CVSS 2.0

Type
Primary
Base score
4.6
Impact score
6.4
Exploitability score
3.9
Vector string
AV:L/AC:L/Au:N/C:P/I:P/A:P

Known exploits

Data from CISA

Vulnerability name
Linux Kernel Heap Out-of-Bounds Write Vulnerability
Exploit added on
Oct 6, 2025
Exploit action due
Oct 27, 2025
Required action
Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.

Weaknesses

cve-coordination@google.com
CWE-787
nvd@nist.gov
CWE-787

Social media

Hype score
Not currently trending

Configurations

  1. In the Linux kernel, the following vulnerability has been resolved: Input: uinput - fix circular locking dependency with ff-core A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge)CVE-2026-31667

References

Sources include official advisories and independent security research.