kernel-5.14.0-687.17.1.el9_8
エラータID: AXSA:2026-1389:56
リリース日:
2026/07/30 Thursday - 14:20
題名:
kernel-5.14.0-687.17.1.el9_8
影響のあるチャネル:
MIRACLE LINUX 9 for x86_64
Severity:
High
Description:
以下項目について対処しました。
[Security Fix]
- kernel の isotp モジュールには、メモリ領域の解放後利用の問題が
あるため、ローカルの攻撃者により、サービス拒否攻撃 (クラッシュの
発生)、および予期しない動作の発生を可能とする脆弱性が存在します。
(CVE-2026-31474)
- kernel の MPTCP の実装には、メモリ領域の解放後利用の問題が
あるため、近隣のネットワーク上の攻撃者により、サービス拒否攻撃
(DoS)、および任意のコードの実行を可能とする脆弱性が存在します。
(CVE-2026-31669)
- kernel の Bluetooth ホストコントローラーインターフェース同期
機能には、スタックベースのバッファオーバーフローの問題があるため、
ローカルの攻撃者により、情報の漏洩、データ破壊、およびサービス拒否
攻撃を可能とする脆弱性が存在します。(CVE-2026-31772)
- kernel の xen/privcmd には、メモリ領域の二重解放の問題があるため、
ローカルの攻撃者により、システムの不安定化、およびサービス拒否攻撃
を可能とする脆弱性が存在します。(CVE-2026-31787)
- kernel の bnxt_en ドライバには、メモリ領域の解放処理が欠落して
いるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2026-43260)
- kernel の ALSA サブシステムには、メモリ領域の範囲外書き込みの
問題があるため、ローカルの攻撃者により、情報の漏洩、データ破壊、
およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2026-43279)
- kernel の SCSI ドライバには、ローカルの攻撃者により、情報の
漏洩、およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2026-43414)
- kernel の GFS2 ファイルシステムには、メモリ領域の解放後利用の
問題があるため、ローカルの攻撃者により、情報の漏洩、データ破壊、
およびサービス拒否攻撃を可能とする脆弱性が存在します。
(CVE-2026-45984)
- kernel の Bluetooth サブシステムには、メモリ領域の解放後利用の
問題があるため、ローカルの攻撃者により、サービス拒否攻撃、および
任意のコードの実行を可能とする脆弱性が存在します。(CVE-2026-46056)
- kernel の RDMA/mana コンポーネントには、ローカルの攻撃者により、
情報の漏洩、データ破壊、およびサービス拒否攻撃を可能とする脆弱性
が存在します。(CVE-2026-46117)
- kernel の Wi-Fi サブシステムには、メモリ領域の解放後利用、および
メモリ領域の二重解放の問題があるため、近隣のネットワーク上の攻撃者
により、システムの不安定化、および予期しない動作の発生を可能とする
脆弱性が存在します。(CVE-2026-46125)
- kernel の NVMe over TCP の実装には、メモリ領域の二重解放の問題
があるため、ローカルの攻撃者により、メモリ破壊、およびサービス拒否
攻撃 (DoS) を可能とする脆弱性が存在します。(CVE-2026-46135)
- kernel の RDMA/mana コンポーネントには、メモリ領域の範囲外
書き込みの問題があるため、ローカルの攻撃者により、特権昇格、
およびサービス拒否攻撃 (DoS) を可能とする脆弱性が存在します。
(CVE-2026-46145)
- kernel の Wi-Fi サブシステムには、ローカルの攻撃者により、
情報の漏洩、データ破壊、およびサービス拒否攻撃を可能とする脆弱性
が存在します。(CVE-2026-46152)
- kernel の Wi-Fi サブシステムには、メモリ領域の解放後利用の問題
があるため、ローカルの攻撃者により、情報の漏洩、データ破壊、および
サービス拒否攻撃を可能とする脆弱性が存在します。(CVE-2026-46166)
- kernel には、エラーが発生したタスクの終了処理に問題があるため、
ローカルの攻撃者により、サービス拒否攻撃 (クラッシュの発生)、
特権昇格を可能とする脆弱性が存在します。(CVE-2026-46173)
- kernel の pedit サブシステムには、メモリ領域の範囲外書き込みの
問題があるため、ローカルの攻撃者により、特権昇格、およびサービス
拒否攻撃 (クラッシュの発生) を可能とする脆弱性が存在します。
(CVE-2026-46331)
解決策:
パッケージをアップデートしてください。
CVE:
CVE-2026-31474
In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix tx.buf use-after-free in isotp_sendmsg() isotp_sendmsg() uses only cmpxchg() on so->tx.state to serialize access to so->tx.buf. isotp_release() waits for ISOTP_IDLE via wait_event_interruptible() and then calls kfree(so->tx.buf). If a signal interrupts the wait_event_interruptible() inside close() while tx.state is ISOTP_SENDING, the loop exits early and release proceeds to force ISOTP_SHUTDOWN and continues to kfree(so->tx.buf) while sendmsg may still be reading so->tx.buf for the final CAN frame in isotp_fill_dataframe(). The so->tx.buf can be allocated once when the standard tx.buf length needs to be extended. Move the kfree() of this potentially extended tx.buf to sk_destruct time when either isotp_sendmsg() and isotp_release() are done.
In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix tx.buf use-after-free in isotp_sendmsg() isotp_sendmsg() uses only cmpxchg() on so->tx.state to serialize access to so->tx.buf. isotp_release() waits for ISOTP_IDLE via wait_event_interruptible() and then calls kfree(so->tx.buf). If a signal interrupts the wait_event_interruptible() inside close() while tx.state is ISOTP_SENDING, the loop exits early and release proceeds to force ISOTP_SHUTDOWN and continues to kfree(so->tx.buf) while sendmsg may still be reading so->tx.buf for the final CAN frame in isotp_fill_dataframe(). The so->tx.buf can be allocated once when the standard tx.buf length needs to be extended. Move the kfree() of this potentially extended tx.buf to sk_destruct time when either isotp_sendmsg() and isotp_release() are done.
CVE-2026-31669
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache.
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache.
CVE-2026-31772
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix stack buffer overflow in hci_le_big_create_sync hci_le_big_create_sync() uses DEFINE_FLEX to allocate a struct hci_cp_le_big_create_sync on the stack with room for 0x11 (17) BIS entries. However, conn->num_bis can hold up to HCI_MAX_ISO_BIS (31) entries — validated against ISO_MAX_NUM_BIS (0x1f) in the caller hci_conn_big_create_sync(). When conn->num_bis is between 18 and 31, the memcpy that copies conn->bis into cp->bis writes up to 14 bytes past the stack buffer, corrupting adjacent stack memory. This is trivially reproducible: binding an ISO socket with bc_num_bis = ISO_MAX_NUM_BIS (31) and calling listen() will eventually trigger hci_le_big_create_sync() from the HCI command sync worker, causing a KASAN-detectable stack-out-of-bounds write: BUG: KASAN: stack-out-of-bounds in hci_le_big_create_sync+0x256/0x3b0 Write of size 31 at addr ffffc90000487b48 by task kworker/u9:0/71 Fix this by changing the DEFINE_FLEX count from the incorrect 0x11 to HCI_MAX_ISO_BIS, which matches the maximum number of BIS entries that conn->bis can actually carry.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: fix stack buffer overflow in hci_le_big_create_sync hci_le_big_create_sync() uses DEFINE_FLEX to allocate a struct hci_cp_le_big_create_sync on the stack with room for 0x11 (17) BIS entries. However, conn->num_bis can hold up to HCI_MAX_ISO_BIS (31) entries — validated against ISO_MAX_NUM_BIS (0x1f) in the caller hci_conn_big_create_sync(). When conn->num_bis is between 18 and 31, the memcpy that copies conn->bis into cp->bis writes up to 14 bytes past the stack buffer, corrupting adjacent stack memory. This is trivially reproducible: binding an ISO socket with bc_num_bis = ISO_MAX_NUM_BIS (31) and calling listen() will eventually trigger hci_le_big_create_sync() from the HCI command sync worker, causing a KASAN-detectable stack-out-of-bounds write: BUG: KASAN: stack-out-of-bounds in hci_le_big_create_sync+0x256/0x3b0 Write of size 31 at addr ffffc90000487b48 by task kworker/u9:0/71 Fix this by changing the DEFINE_FLEX count from the incorrect 0x11 to HCI_MAX_ISO_BIS, which matches the maximum number of BIS entries that conn->bis can actually carry.
CVE-2026-31787
In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: fix double free via VMA splitting privcmd_vm_ops defines .close (privcmd_close), but neither .may_split nor .open. When userspace does a partial munmap() on a privcmd mapping, the kernel splits the VMA via __split_vma(). Since may_split is NULL, the split is allowed. vm_area_dup() copies vm_private_data (a pages array allocated in alloc_empty_pages()) into the new VMA without any fixup, because there is no .open callback. Both VMAs now point to the same pages array. When the unmapped portion is closed, privcmd_close() calls: - xen_unmap_domain_gfn_range() - xen_free_unpopulated_pages() - kvfree(pages) The surviving VMA still holds the dangling pointer. When it is later destroyed, the same sequence runs again, which leads to a double free. Fix this issue by adding a .may_split callback denying the VMA split. This is XSA-487 / CVE-2026-31787
In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: fix double free via VMA splitting privcmd_vm_ops defines .close (privcmd_close), but neither .may_split nor .open. When userspace does a partial munmap() on a privcmd mapping, the kernel splits the VMA via __split_vma(). Since may_split is NULL, the split is allowed. vm_area_dup() copies vm_private_data (a pages array allocated in alloc_empty_pages()) into the new VMA without any fixup, because there is no .open callback. Both VMAs now point to the same pages array. When the unmapped portion is closed, privcmd_close() calls: - xen_unmap_domain_gfn_range() - xen_free_unpopulated_pages() - kvfree(pages) The surviving VMA still holds the dangling pointer. When it is later destroyed, the same sequence runs again, which leads to a double free. Fix this issue by adding a .may_split callback denying the VMA split. This is XSA-487 / CVE-2026-31787
CVE-2026-43260
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix RSS context delete logic We need to free the corresponding RSS context VNIC in FW everytime an RSS context is deleted in driver. Commit 667ac333dbb7 added a check to delete the VNIC in FW only when netif_running() is true to help delete RSS contexts with interface down. Having that condition will make the driver leak VNICs in FW whenever close() happens with active RSS contexts. On the subsequent open(), as part of RSS context restoration, we will end up trying to create extra VNICs for which we did not make any reservation. FW can fail this request, thereby making us lose active RSS contexts. Suppose an RSS context is deleted already and we try to process a delete request again, then the HWRM functions will check for validity of the request and they simply return if the resource is already freed. So, even for delete-when-down cases, netif_running() check is not necessary. Remove the netif_running() condition check when deleting an RSS context.
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix RSS context delete logic We need to free the corresponding RSS context VNIC in FW everytime an RSS context is deleted in driver. Commit 667ac333dbb7 added a check to delete the VNIC in FW only when netif_running() is true to help delete RSS contexts with interface down. Having that condition will make the driver leak VNICs in FW whenever close() happens with active RSS contexts. On the subsequent open(), as part of RSS context restoration, we will end up trying to create extra VNICs for which we did not make any reservation. FW can fail this request, thereby making us lose active RSS contexts. Suppose an RSS context is deleted already and we try to process a delete request again, then the HWRM functions will check for validity of the request and they simply return if the resource is already freed. So, even for delete-when-down cases, netif_running() check is not necessary. Remove the netif_running() condition check when deleting an RSS context.
CVE-2026-43279
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Add sanity check for OOB writes at silencing At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops.
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Add sanity check for OOB writes at silencing At silencing the playback URB packets in the implicit fb mode before the actual playback, we blindly assume that the received packets fit with the buffer size. But when the setup in the capture stream differs from the playback stream (e.g. due to the USB core limitation of max packet size), such an inconsistency may lead to OOB writes to the buffer, resulting in a crash. For addressing it, add a sanity check of the transfer buffer size at prepare_silent_urb(), and stop the data copy if the received data overflows. Also, report back the transfer error properly from there, too. Note that this doesn't fix the root cause of the playback error itself, but this merely covers the kernel Oops.
CVE-2026-43414
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Completely fix fcport double free In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea.
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Completely fix fcport double free In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference. qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea.
CVE-2026-45984
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix use-after-free in iomap inline data write path The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix use-after-free in iomap inline data write path The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]
CVE-2026-46056
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in SSP passkey handlers hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in SSP passkey handlers hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.
CVE-2026-46117
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Remove user triggerable WARN_ON() in mana_ib_create_qp_rss() Sashiko points out that the user can specify WQs sharing the same CQ as a part of the uAPI and this will trigger the WARN_ON() then go on to corrupt the kernel. Just reject it outright and fail the QP creation.
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Remove user triggerable WARN_ON() in mana_ib_create_qp_rss() Sashiko points out that the user can specify WQs sharing the same CQ as a part of the uAPI and this will trigger the WARN_ON() then go on to corrupt the kernel. Just reject it outright and fail the QP creation.
CVE-2026-46125
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: remove station if connection prep fails If connection preparation fails for MLO connections, then the interface is completely reset to non-MLD. In this case, we must not keep the station since it's related to the link of the vif being removed. Delete an existing station. Any "new_sta" is already being removed, so that doesn't need changes. This fixes a use-after-free/double-free in debugfs if that's enabled, because a vif going from MLD (and to MLD, but that's not relevant here) recreates its entire debugfs.
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: remove station if connection prep fails If connection preparation fails for MLO connections, then the interface is completely reset to non-MLD. In this case, we must not keep the station since it's related to the link of the vif being removed. Delete an existing station. Any "new_sta" is already being removed, so that doesn't need changes. This fixes a use-after-free/double-free in debugfs if that's enabled, because a vif going from MLD (and to MLD, but that's not relevant here) recreates its entire debugfs.
CVE-2026-46135
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 nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.
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 nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.
CVE-2026-46145
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Validate rx_hash_key_len Sashiko points out that rx_hash_key_len comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow.
In the Linux kernel, the following vulnerability has been resolved: RDMA/mana: Validate rx_hash_key_len Sashiko points out that rx_hash_key_len comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow.
CVE-2026-46152
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: drop stray 'static' from fast-RX rx_result ieee80211_invoke_fast_rx() is documented as safe for parallel RX, but its per-invocation rx_result is declared static. Concurrent callers then share one instance and can overwrite each other's result between ieee80211_rx_mesh_data() and the switch on res. That can make a packet that was queued or consumed by ieee80211_rx_mesh_data() fall through into ieee80211_rx_8023(), or make a packet that should continue return as queued. Make res an automatic variable so each invocation keeps its own result.
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: drop stray 'static' from fast-RX rx_result ieee80211_invoke_fast_rx() is documented as safe for parallel RX, but its per-invocation rx_result is declared static. Concurrent callers then share one instance and can overwrite each other's result between ieee80211_rx_mesh_data() and the switch on res. That can make a packet that was queued or consumed by ieee80211_rx_mesh_data() fall through into ieee80211_rx_8023(), or make a packet that should continue return as queued. Make res an automatic variable so each invocation keeps its own result.
CVE-2026-46166
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use safe list iteration in radar detect work The call to ieee80211_dfs_cac_cancel can cause the iterated chanctx to be freed and removed from the list. Guard against this to avoid a slab-use-after-free error.
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use safe list iteration in radar detect work The call to ieee80211_dfs_cac_cancel can cause the iterated chanctx to be freed and removed from the list. Guard against this to avoid a slab-use-after-free error.
CVE-2026-46173
In the Linux kernel, the following vulnerability has been resolved: exit: prevent preemption of oopsing TASK_DEAD task When an already-exiting task oopses, make_task_dead() currently calls do_task_dead() with preemption enabled. That is forbidden: do_task_dead() calls __schedule(), which has a comment saying "WARNING: must be called with preemption disabled!". If an oopsing task is preempted in do_task_dead(), between becoming TASK_DEAD and entering the scheduler explicitly, bad things happen: finish_task_switch() assumes that once the scheduler has switched away from a TASK_DEAD task, the task can never run again and its stack is no longer needed; but that assumption apparently doesn't hold if the dead task was preempted (the SM_PREEMPT case). This means that the scheduler ends up repeatedly dropping references on the dead task's stack, which can lead to use-after-free or double-free of the entire task stack; in other words, two tasks can end up running on the same stack, resulting in various kinds of memory corruption. (This does not just affect "recursively oopsing" tasks; it is enough to oops once during task exit, for example in a file_operations::release handler)
In the Linux kernel, the following vulnerability has been resolved: exit: prevent preemption of oopsing TASK_DEAD task When an already-exiting task oopses, make_task_dead() currently calls do_task_dead() with preemption enabled. That is forbidden: do_task_dead() calls __schedule(), which has a comment saying "WARNING: must be called with preemption disabled!". If an oopsing task is preempted in do_task_dead(), between becoming TASK_DEAD and entering the scheduler explicitly, bad things happen: finish_task_switch() assumes that once the scheduler has switched away from a TASK_DEAD task, the task can never run again and its stack is no longer needed; but that assumption apparently doesn't hold if the dead task was preempted (the SM_PREEMPT case). This means that the scheduler ends up repeatedly dropping references on the dead task's stack, which can lead to use-after-free or double-free of the entire task stack; in other words, two tasks can end up running on the same stack, resulting in various kinds of memory corruption. (This does not just affect "recursively oopsing" tasks; it is enough to oops once during task exit, for example in a file_operations::release handler)
CVE-2026-46331
In the Linux kernel, the following vulnerability has been resolved: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.
In the Linux kernel, the following vulnerability has been resolved: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.
追加情報:
N/A
ダウンロード:
SRPMS
- kernel-5.14.0-687.17.1.el9_8.src.rpm
MD5: 9f093aba006b76a53ba1f285c8571560
SHA-256: efbe8a6622c1472dc7546fd55a722037c7408327f03766d089cec9438c53ac9b
Size: 144.70 MB
Asianux Server 9 for x86_64
- kernel-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: ebe73bbfb63a37fee8774cb334af6ed3
SHA-256: 6ddedbd3a326882f07ed991c5f3bc08b85b8a5da2356c4da52fdecf9ef03d452
Size: 15.14 kB - kernel-abi-stablelists-5.14.0-687.17.1.el9_8.noarch.rpm
MD5: 6ed6ce4f2e2b170aecb59f17830c3f9c
SHA-256: 406e54f8151d00b805923f41394d80ed1116e2d3914a286df4eb564a7d83d25e
Size: 50.43 kB - kernel-core-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 6b2ae66f3e1e0d54bd59c68c113be387
SHA-256: 68a212289092ec519b18fdd7b2eb82dc1925b30ec3dd386753825bd5a951b8ba
Size: 16.33 MB - kernel-cross-headers-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 8355c02ad9ca73e8604f9883112740b7
SHA-256: 8698e29cc4c1072bbc2bea3ab35051328e5f6566bea89e6efe6ea8c75adc45f1
Size: 7.08 MB - kernel-debug-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 151f5b1e8e5bba1bfd9a97807d54a49c
SHA-256: db452f1bdbaeb2265a085dbd3db102f3931e4be2f6eab962c7fcf3bc397ac1f2
Size: 15.23 kB - kernel-debug-core-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 8a1086d6e3ee1a72557448b9175f9075
SHA-256: c8e005d15a717b6fc05d6d5361cf6a281785718afa5ae38ac41b49f284bc2c6e
Size: 30.19 MB - kernel-debug-devel-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: b8451ab420a2c268809ff4bdd7652e80
SHA-256: 4b93696b6346445a4973cc7db328f9cb6b8ac62ddeac17c4a31d01ebdad65ed8
Size: 20.43 MB - kernel-debug-devel-matched-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 4360c0cb4c4bcc3598d3a2b37938a8fa
SHA-256: 5eff19e643cf9655c1a287474b510c8fe3f6173fdeb5cc59f435925ae2028be1
Size: 15.22 kB - kernel-debug-modules-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 409c283c53f599add468892d87fec722
SHA-256: 2278bbf2caecd58df551957c489da69c13dd427e1151334d02fdf48038910724
Size: 69.17 MB - kernel-debug-modules-core-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 253ae9e2d140e0b3ced64c59e715e39e
SHA-256: 1dd69b11878b69de32c6ebc329ce73285b92ae17005f131c616a9688c93943ff
Size: 48.83 MB - kernel-debug-modules-extra-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 06a2c6d6919c8b89343e8aa6d2165835
SHA-256: 60084925246e4f7f1ff506ae1f038ef14f27abb40e94e5562c9e62998e91c3ac
Size: 836.36 kB - kernel-debug-uki-virt-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 27c462ac499cd1d75ec888728eed5a90
SHA-256: e2ec1dd68139bb5cbcea52257f015cf9b724cc447ff30a5831c475ddf4b4a0bc
Size: 87.21 MB - kernel-devel-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 64b41109fb628fe78dc2d60fe898c753
SHA-256: c1454c7202ebbd19af1de73d9d61a9159f9e428d5039a3630223e44e11c6551f
Size: 20.23 MB - kernel-devel-matched-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 6bf3def6a08f75dd9bbd1a4fc23ab19d
SHA-256: 5877d6cb3a5d3f0d0e626ca8f5d5679ddd5d680d14c9e4dd6e092086b97cc392
Size: 15.19 kB - kernel-doc-5.14.0-687.17.1.el9_8.noarch.rpm
MD5: 2318fffd2bd06a41e909400ed1533bbd
SHA-256: 53f4a80240133a16bd8cce345cbec9ddd9f56ad531dc86837b751113937e8b79
Size: 38.00 MB - kernel-headers-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 7be17e98b291ff5ade6da23c65f471a7
SHA-256: a97bc7fe45bef1f6a47eaac5a8b2ce1e76730248079795232b0f032e38591db7
Size: 1.80 MB - kernel-modules-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 4f9de997c0ea81de6af1bcfc96032eaf
SHA-256: 2ed6b07db4e76d9dd0a05839333f06cfdffbf1197f57b593813f89dc7fa9d39e
Size: 39.01 MB - kernel-modules-core-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: c12a3e52ebfab3a8348b9036eeee32c7
SHA-256: 561cf17d2119f44ea52592417ccc8ac77aa06f6ca32f6f1cd12d4d5f558ff3d1
Size: 30.03 MB - kernel-modules-extra-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 42ea211c6dcd179eee04d7a24a40adff
SHA-256: eb6cbdabe4b3f3d7d2d703e384130a4356702852ecceef58f9be71a641e817e9
Size: 463.09 kB - kernel-rt-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 584b85c2c9d41f200cad53fb0d9f45c2
SHA-256: 9983c253d668c9689f0f087371804580e5716ce4635602adc46df30e6568295b
Size: 15.22 kB - kernel-rt-core-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 35146de900f9afc6ac79184ccd2ac11e
SHA-256: ad9cd1a3321ec524cbef89ec4c8b287614e2d2e829f39841912a871f43c51a7a
Size: 16.23 MB - kernel-rt-debug-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: d7e5585cc5986a4c0e7c9965fe3a62db
SHA-256: 927a61e118ad7127a12bf376810cdd74ea5e9c7ebf622d496b4df268dc8c390f
Size: 15.29 kB - kernel-rt-debug-core-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 15fd227f5539525a194679716d7a8ff5
SHA-256: f12287ff9fc763ad2ab3bf6fbf38f657d2b55e34de77a30fe1b39b1a4edd39f0
Size: 17.69 MB - kernel-rt-debug-devel-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 94ea3c96dc73b8ccf39289b4ae620442
SHA-256: 98115519c5aabb62a02f4476d61294d734c537e8085605f4df93e3a62e811ad8
Size: 20.37 MB - kernel-rt-debug-modules-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: c5699cd70bf70a38fc4221c8429106dc
SHA-256: e4ade3ae66a941a84a0d7a0f435a8edbb099bf9ccb1cc7bcfd22538083622f3a
Size: 40.60 MB - kernel-rt-debug-modules-core-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 1521e7daea3696edce74fe9f42978118
SHA-256: 281b14886edac0a77ca9623f1140059d4136f45c9ca8b4aed0915e2b2392b93d
Size: 31.21 MB - kernel-rt-debug-modules-extra-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 0edf4db682e0b97f0ddd6df372579abc
SHA-256: febe5dd4c8d19bb29d07c2f3dba3b0c2c9141c856dbe8c81c21dcc234d18f7ae
Size: 492.33 kB - kernel-rt-devel-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 2d15bfb57fbcd4bd278dff39753e3a8d
SHA-256: 4914c1975f15379f49b5d65bc2fc3a833632788d758ca20796fdcd25c38a6d2f
Size: 20.22 MB - kernel-rt-modules-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 724aacfe7ba1cea29229585e96f8cc74
SHA-256: e12e08f7f53ba4f123f2ba176f8de3340f589c03bcd75cd139f2f299ae7705a8
Size: 39.03 MB - kernel-rt-modules-core-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 67a17c43556e4123759bace7cdd47466
SHA-256: b5ebcbdd26b7d1ca2af1692aa7dc0d9d3747a6d0705d80bf77ccdc506102c71c
Size: 30.10 MB - kernel-rt-modules-extra-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 190f4c83dfc39ad51f3d0a5725e3c418
SHA-256: cdbbb7fa7c4e1757c15abbbb90429db49a26e4b1f496120203cb5b3e158cb2ef
Size: 465.38 kB - kernel-tools-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: cc787ee35a9ad26d506ec1e46f90afb4
SHA-256: 5f496a14d825a18b17f8e71dd47af4e847ba855dc41b5a67791f5615ad689a61
Size: 311.22 kB - kernel-tools-libs-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 8cce97676592853624d3c5dd0e559a6b
SHA-256: a604f276ae29c24e65bc8cfef10a9ba78d71284caa986c1ec4271c14a21a33c6
Size: 27.92 kB - kernel-tools-libs-devel-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: fb36c783069868312faa7e11b2ff685d
SHA-256: 3bad2783edee99de5f7e402814b8d00ee58a6b70c5b6b9c33ae87e741b7156f8
Size: 17.69 kB - kernel-uki-virt-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: a076ce30e6e8492090c8b9500b55d3df
SHA-256: 1a0f3815d870086413660db63697dd344e18e029ab83280b1ddc0ce4633839dc
Size: 65.03 MB - kernel-uki-virt-addons-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: c52302d6d01f80879cecaf25f222b03b
SHA-256: c329330dfc6b00cf96f3317d871257a7fedee11b869ebf24136d00b63cbc33cf
Size: 37.84 kB - libperf-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 351bd765fa26eb0abe9aaa0b6e2bbef5
SHA-256: d68ad6077bd3e686d1c1f31251cbf55d2bc43ca7ef788ea1460bb3ee2343b6f4
Size: 36.24 kB - perf-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 729d10310c7828a8a953b2238653ea53
SHA-256: 0611cec9966f2a75365a26b4086053265fc0d2b682c61d0311b86da9568df80a
Size: 2.43 MB - python3-perf-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: a479fc0153678c362b3cf3ad91cb394d
SHA-256: d13b08b850482cf648a1de6df4f3efccaff6fb31b4a94d628c57c4b684990cfc
Size: 1.60 MB - rtla-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: d3c27195f46794fef9125b7370720a5e
SHA-256: 0bcf0a3bde33a87ea8d31a511eb71fd42f3389a2d1b96bb214dc6ea656e34251
Size: 86.92 kB - rv-5.14.0-687.17.1.el9_8.x86_64.rpm
MD5: 366eee18bc9ad916bab70bb418004b89
SHA-256: d52236cd02de7c023e95391efd0c099ee93b91a0da43840677a5dd5ac84bbd2c
Size: 31.46 kB
English