Описание
ELSA-2026-52765: kernel security update (MODERATE)
[4.18.0-553.153.1]
- Update Oracle Linux certificates (Kevin Lyons)
- Disable signing for aarch64 (Ilya Okomin)
- Oracle Linux RHCK Module Signing Key was added to the kernel trusted keys list (olkmod_signing_key.pem) [Orabug: 29539237]
- Update x509.genkey [Orabug: 24817676]
- Conflict with shim-ia32 and shim-x64 <= 15.3-1.0.3
- Remove upstream reference during boot (Kevin Lyons) [Orabug: 34750652]
- Add new Oracle Linux Driver Signing (key 1) certificate [Orabug: 37985772]
[4.18.0-553.154.1]
- iio: event: Fix event FIFO reset race (CKI Backport Bot) [RHEL-223364] {CVE-2026-64496}
- redhat: add kmap.py tool and kernel-kmap-internal package (Rado Vrbovsky)
Обновленные пакеты
Oracle Linux 8
Oracle Linux aarch64
kernel-tools-libs-devel
4.18.0-553.154.1.el8_10
bpftool
4.18.0-553.154.1.el8_10
kernel-cross-headers
4.18.0-553.154.1.el8_10
kernel-headers
4.18.0-553.154.1.el8_10
kernel-tools
4.18.0-553.154.1.el8_10
kernel-tools-libs
4.18.0-553.154.1.el8_10
perf
4.18.0-553.154.1.el8_10
python3-perf
4.18.0-553.154.1.el8_10
Oracle Linux x86_64
kernel-tools-libs-devel
4.18.0-553.154.1.el8_10
bpftool
4.18.0-553.154.1.el8_10
kernel
4.18.0-553.154.1.el8_10
kernel-abi-stablelists
4.18.0-553.154.1.el8_10
kernel-core
4.18.0-553.154.1.el8_10
kernel-cross-headers
4.18.0-553.154.1.el8_10
kernel-debug
4.18.0-553.154.1.el8_10
kernel-debug-core
4.18.0-553.154.1.el8_10
kernel-debug-devel
4.18.0-553.154.1.el8_10
kernel-debug-modules
4.18.0-553.154.1.el8_10
kernel-debug-modules-extra
4.18.0-553.154.1.el8_10
kernel-devel
4.18.0-553.154.1.el8_10
kernel-doc
4.18.0-553.154.1.el8_10
kernel-headers
4.18.0-553.154.1.el8_10
kernel-modules
4.18.0-553.154.1.el8_10
kernel-modules-extra
4.18.0-553.154.1.el8_10
kernel-tools
4.18.0-553.154.1.el8_10
kernel-tools-libs
4.18.0-553.154.1.el8_10
perf
4.18.0-553.154.1.el8_10
python3-perf
4.18.0-553.154.1.el8_10
Связанные CVE
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: iio: event: Fix event FIFO reset race `iio_event_getfd()` creates the event file descriptor with `anon_inode_getfd()`, which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller. The IIO code resets the event FIFO after `anon_inode_getfd()` has returned, but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a `read()` on it as soon as the fd has been installed. This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in parallel with the `kfifo_reset_out()` in `iio_event_getfd()`. The kfifo documentation says that `kfifo_reset_out()` is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as `kfifo_reset()`. ...
In the Linux kernel, the following vulnerability has been resolved: iio: event: Fix event FIFO reset race `iio_event_getfd()` creates the event file descriptor with `anon_inode_getfd()`, which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller. The IIO code resets the event FIFO after `anon_inode_getfd()` has returned, but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a `read()` on it as soon as the fd has been installed. This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in parallel with the `kfifo_reset_out()` in `iio_event_getfd()`. The kfifo documentation says that `kfifo_reset_out()` is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as `kfifo_reset()`. ...
In the Linux kernel, the following vulnerability has been resolved: iio: event: Fix event FIFO reset race `iio_event_getfd()` creates the event file descriptor with `anon_inode_getfd()`, which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller. The IIO code resets the event FIFO after `anon_inode_getfd()` has returned, but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a `read()` on it as soon as the fd has been installed. This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in parallel with the `kfifo_reset_out()` in `iio_event_getfd()`. The kfifo documentation says that `kfifo_reset_out()` is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as `kfifo_reset()`
In the Linux kernel, the following vulnerability has been resolved: i ...