CVE-2026-23194

rust_binder: correctly handle FDA objects of length zero

State
Published
Severity
Not scored
Published
Feb 14, 2026
Updated
May 11, 2026
Reserved
Jan 13, 2026

Read the record on cve.org

Description

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

rust_binder: correctly handle FDA objects of length zero

Fix a bug where an empty FDA (fd array) object with 0 fds would cause an out-of-bounds error. The previous implementation used `skip == 0` to mean "this is a pointer fixup", but 0 is also the correct skip length for an empty FDA. If the FDA is at the end of the buffer, then this results in an attempt to write 8-bytes out of bounds. This is caught and results in an EINVAL error being returned to userspace.

The pattern of using `skip == 0` as a special value originates from the C-implementation of Binder. As part of fixing this bug, this pattern is replaced with a Rust enum.

I considered the alternate option of not pushing a fixup when the length is zero, but I think it's cleaner to just get rid of the zero-is-special stuff.

The root cause of this bug was diagnosed by Gemini CLI on first try. I used the following prompt:

> There appears to be a bug in @drivers/android/binder/thread.rs where > the Fixups oob bug is triggered with 316 304 316 324. This implies > that we somehow ended up with a fixup where buffer A has a pointer to > buffer B, but the pointer is located at an index in buffer A that is > out of bounds. Please investigate the code to find the bug. You may > compare with @drivers/android/binder.c that implements this correctly.

Scores

The record has no CVSS score.

Weaknesses

The record names no weakness.

Affected Products

ProductVersions
LinuxLinux
  • eafedbc7c050c44744fbdf80bdf3315e860b7513 to before 598fe3ff32e43918ed8a062f55432b3d23e6340cAffected
  • eafedbc7c050c44744fbdf80bdf3315e860b7513 to before 8f589c9c3be539d6c2b393c82940c3783831082fAffected
LinuxLinux
  • 6.18Affected
  • before 6.18Not affected
  • 6.18.10 through 6.18.*Not affected
  • 6.19 and laterNot affected

References

Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.