Use of Uninitialized Resource Affecting kernel-rt-64k-debug package, versions *


Severity

Recommended
low

Based on default assessment until relevant scores are available.

Threat Intelligence

EPSS
0.21% (12th 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-CENTOS10-KERNELRT64KDEBUG-18159455
  • published22 Jul 2026
  • disclosed19 Jul 2026

Introduced: 19 Jul 2026

NewCVE-2026-63934  (opens in a new tab)
CWE-908  (opens in a new tab)

How to fix?

There is no fixed version for Centos:10 kernel-rt-64k-debug.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-rt-64k-debug package and not the kernel-rt-64k-debug package as distributed by Centos. See How to fix? for Centos:10 relevant fixed versions and status.

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

iio: gyro: itg3200: fix i2c read into the wrong stack location

itg3200_read_all_channels() takes __be16 *buf' as a parameter and fills the i2c_msg destination as (char *)&buf'. Since buf' is the parameter (a pointer), &buf' is the address of the local pointer slot on the stack of itg3200_read_all_channels(), not the address of the caller's scan buffer. The (char *) cast hides the type mismatch.

i2c_transfer() therefore writes ITG3200_SCAN_ELEMENTS * sizeof(s16) = 8 bytes into the parameter's stack slot, which is discarded when the function returns. The caller's scan buffer in itg3200_trigger_handler() is never written to, so iio_push_to_buffers_with_timestamp() pushes uninitialised stack contents to userspace via /dev/iio:deviceX every scan -- both a functional bug (no actual gyroscope or temperature data is delivered through the triggered buffer) and an information leak.

The non-buffered read_raw() path is unaffected: it goes through itg3200_read_reg_s16() which uses `&out' on a local s16 value, where that is correct.

Drop the spurious `&' so the i2c read writes into the caller's buffer.