Affected: AlmaLinux:8: bpftool, AlmaLinux:8: kernel, AlmaLinux:8: kernel-abi-stablelists, AlmaLinux:8: kernel-core, AlmaLinux:8: kernel-cross-headers, AlmaLinux:8: kernel-debug, AlmaLinux:8: kernel-debug-core, AlmaLinux:8: kernel-debug-devel, AlmaLinux:8: kernel-debug-modules, AlmaLinux:8: kernel-debug-modules-extra and 15 more

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: Linux kernel: Use-after-free in bonding driver leads to denial of service (CVE-2026-31419) * kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation (CVE-2026-31488) * kernel: net: mana: fix use-after-free in add_adev() error path (CVE-2026-43056) * kernel: ALSA: usb-audio: Add sanity check for OOB writes at silencing (CVE-2026-43279) * kernel: net/sched: act_pedit: extend the writable skb range per key (CVE-2026-46331) * kernel: ALSA: aloop: Fix peer runtime UAF during format-change stop (CVE-2026-46090) * kernel: RDMA/mana: Validate rx_hash_key_len (CVE-2026-46145) * kernel: nvmet-tcp: fix race between ICReq handling and queue teardown (CVE-2026-46135)

Bug Fix(es) and Enhancement(s):

* AlmaLinux8 RT kernel panic in replenish_dl_entity() caused by stale DEADLINE PI state during rt_mutex de-boosting (JIRA:AlmaLinux-178520)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Affected: Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

Important: kernel security, bug fix, and enhancement update

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

nvmet-tcp: fix race between ICReq handling and queue teardown

nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown.

If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock.

If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue.

The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference.

Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started.

Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET…

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

nvmet-tcp: fix race between ICReq handling and queue teardown

nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown.

If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock.

If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue.

The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference.

Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started.

Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET…

Affected: openEuler:22.03-LTS-SP4: kernel

The Linux Kernel, the operating system core itself. Security Fix(es):

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

netfilter: nf_conntrack_expect: use expect->helper

Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe.

Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.(CVE-2026-31414)

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

xfs: avoid dereferencing log items after push callbacks

After xfsaild_push_item() calls iop_push(), the log item may have been freed if the AIL lock was dropped during the push. Background inode reclaim or the dquot shrinker can free the log item while the AIL lock is not held, and the tracepoints in the switch statement dereference the log item after iop_push() returns.

Fix this by capturing the log item type, flags, and LSN before calling xfsaild_push_item(), and introducing a new xfs_ail_push_class trace event class that takes these pre-captured values and the ailp pointer instead of the log item pointer.(CVE-2026-31453)

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

xfs: stop recl…

kernel: Linux kernel: Use-after-free in bonding driver leads to denial of service kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation kernel: net: mana: fix use-after-free in add_adev() error path kernel: ALSA: usb-audio: Add sanity check for OOB writes at silencing kernel: ALSA: aloop: Fix peer runtime UAF during format-change stop kernel: nvmet-tcp: fix race between ICReq handling and queue teardown kernel: RDMA/mana: Validate rx_hash_key_len kernel: net/sched: act_pedit: extend the writable skb range per key

Affected: Rocky Linux:8: kernel

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

* kernel: Linux kernel: Use-after-free in bonding driver leads to denial of service (CVE-2026-31419)

* kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation (CVE-2026-31488)

* kernel: net: mana: fix use-after-free in add_adev() error path (CVE-2026-43056)

* kernel: ALSA: usb-audio: Add sanity check for OOB writes at silencing (CVE-2026-43279)

* kernel: net/sched: act_pedit: extend the writable skb range per key (CVE-2026-46331)

* kernel: ALSA: aloop: Fix peer runtime UAF during format-change stop (CVE-2026-46090)

* kernel: RDMA/mana: Validate rx_hash_key_len (CVE-2026-46145)

* kernel: nvmet-tcp: fix race between ICReq handling and queue teardown (CVE-2026-46135)

Bug Fix(es) and Enhancement(s):

* Rocky Linux8 RT kernel panic in replenish_dl_entity() caused by stale DEADLINE PI state during rt_mutex de-boosting (JIRA:Rocky Linux-178520)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Security update for the Linux Kernel

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 222 more

In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock. If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue. The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference. Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started. Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep…

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.