kernel-5.14.0-687.64.1.el9_8
エラータID: AXSA:2026-2261:117
The kernel packages contain the Linux kernel, the core of any Linux operating system.
Security Fix(es):
* kernel: sctp: stream: fully roll back denied add-stream state (CVE-2026-52929)
* kernel: ipv6: sit: reload inner IPv6 header after GSO offloads (CVE-2026-53228)
* kernel: ipvs: clear the svc scheduler ptr early on edit (CVE-2026-53270)
* kernel: spi: fsl-lpspi: terminate the RX channel on TX prepare failure path (CVE-2026-64303)
* kernel: mptcp: pm: userspace: fix use-after-free in get_local_id (CVE-2026-68169)
* kernel: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE (CVE-2026-72083)
* kernel: tipc: require net admin for TIPCv2 netlink mutators (CVE-2026-74283)
* kernel: Bluetooth: mgmt: fix UAF in pair command cancellation (CVE-2026-74510)
* kernel: packet: use consistent hard_header_len in non-ring send paths (CVE-2026-74582)
* kernel: mptcp: options: reset DSS fields in case of unexpected size (CVE-2026-80586)
* kernel: entry: Fix seccomp bypass after ptrace with TSYNC (CVE-2026-89603)
* kernel: scsi: target: iscsi: Reserve a terminator byte for the login payload (CVE-2026-90011)
* kernel: virtio-fs: avoid double-free on failed queue setup (CVE-2026-93827)
* kernel: smb: client: bound dirent name against end of SMB response in cifs_filldir (CVE-2026-93787)
* kernel: xfrm: hold net_device reference under RCU in bundle creation (CVE-2026-98364)
* kernel: ipv4: free inet_opt and ireq_opt after an RCU grace period (CVE-2026-98432)
* kernel: KVM: arm64: Transfer the hyp stack pages out of the host stage-2 (CVE-2026-98466)
* kernel: nvmet-auth: fix out-of-bounds write in nvmet_auth_challenge() (CVE-2026-98725)
* kernel: ZDI-CAN-33367: Linux Kernel skbuff skb_zerocopy Improper Ownership Management Local Privilege Escalation Vulnerability ()
Bug Fix(es) and Enhancement(s):
* kernel panic in percpu_counter_add_batch() via submit_bio_noacct() due to NULL pointer (JIRA:RHEL-250378)
* ipv4: ip_gre: make ipgre_header() robust (rhel-9.8.z) (JIRA:RHEL-271127)
* ip6_gre: make ip6gre_header() robust (rhel-9.8.z) (JIRA:RHEL-271130)
* Backport "sched: The newidle balance regression" series to rhel 9.8 [rhel-9.8.z] (JIRA:RHEL-288067)
* RHEL is missing support for conntrack zone filtering in dump/delete requests (9.10) [rhel-9.8.z] (JIRA:RHEL-291352)
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.
CVE-2026-52929
In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.
CVE-2026-53228
In the Linux kernel, the following vulnerability has been resolved: ipv6: sit: reload inner IPv6 header after GSO offloads ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb.
CVE-2026-53270
In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.
CVE-2026-64303
In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: terminate the RX channel on TX prepare failure path When dmaengine_prep_slave_sg() fails for the TX channel, the error path terminates the TX DMA channel but leaves the RX channel running. Since the RX channel was already submitted and issued prior to preparing the TX descriptor, returning -EINVAL causes the SPI core to unmap the DMA buffers while the RX DMA engine continues writing to them, leading to potential memory corruption or use-after-free. Terminate the RX channel before returning on the TX prepare failure path.
CVE-2026-68169
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a "not found" sentinel.
CVE-2026-72083
In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing "if (buf) transport_kunmap_data_sg(cmd)" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.
CVE-2026-74283
In the Linux kernel, the following vulnerability has been resolved: tipc: require net admin for TIPCv2 netlink mutators TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable. The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers). A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.
CVE-2026-74510
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix UAF in pair command cancellation The pairing completion and authentication failure callbacks look up the pending MGMT_OP_PAIR_DEVICE command by walking hdev->mgmt_pending. The lookup returned a command that was still linked on the shared pending list, without keeping mgmt_pending_lock held for the later dereference and removal. A concurrent MGMT_OP_CANCEL_PAIR_DEVICE request can remove and free the same pending command before the callback uses it. The reverse race is also possible when cancel_pair_device() gets a command from pending_find() and a callback removes it before the cancel path dereferences it. This can lead to a use-after-free and a second list_del(). Make the pairing lookup helpers transfer ownership of the pending command by removing it from hdev->mgmt_pending while holding mgmt_pending_lock. The callbacks and cancel path then complete the command and free it directly, so racing paths cannot find or free the same command again. Take a temporary hci_conn reference in cancel_pair_device() because the command completion drops the reference stored in the pending command.
CVE-2026-74582
In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.
CVE-2026-80586
In the Linux kernel, the following vulnerability has been resolved: mptcp: options: reset DSS fields in case of unexpected size A remote peer could send a malformed DSS with a wrong size, followed by another DSS or MPC + Data. In this case, the first suboption will be ignored, but leaving some fields written, which could lead to inconsistency or access uninitialized data. Explicitly reset the fields that could have been modified in case of unexpected size.
CVE-2026-89603
REJECTED
CVE-2026-90011
In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where padding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.
CVE-2026-93787
In the Linux kernel, the following vulnerability has been resolved: smb: client: bound dirent name against end of SMB response in cifs_filldir cifs_filldir() copies the entry name out of an SMB1 TRANS2_FIND_FIRST / FIND_NEXT response using a length (de.namelen) supplied by the server. The kmalloc'd SMB response buffer is bounded, but nothing checks that de.name + de.namelen still lies inside that buffer before the eventual filldir64() -> verify_dirent_name() -> memchr() reads namelen bytes. A hostile SMB1 server that returns an oversized FileNameLength in a directory entry therefore causes memchr() to read past the end of the response slab buffer. Reachable from any user who can list a directory on a CIFS mount served by an attacker-controlled server (getdents64() on the mounted directory): BUG: KASAN: slab-out-of-bounds in memchr+0x71/0x80 Read of size 1 at addr ffff88800e0640cc by task poc/115 Call Trace: dump_stack_lvl+0x64/0x80 print_report+0xce/0x620 kasan_report+0xec/0x120 memchr+0x71/0x80 filldir64+0x4c/0x6a0 cifs_filldir.constprop.0+0x9bb/0x1e00 cifs_readdir+0x2101/0x3380 iterate_dir+0x19c/0x520 __x64_sys_getdents64+0x126/0x210 do_syscall_64+0x107/0x5a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Pass the end-of-response pointer down to cifs_filldir() and reject entries whose name would extend past that boundary. This bug was discovered by Artiphishell's vTriage pipeline, which generated a userspace reproducer (an emulated hostile SMB1 server plus a getdents64() client) that reliably triggers the KASAN report on an unpatched kernel. The fix below was drafted with the Claude coding assistant; a userspace reproducer is available on request.
CVE-2026-93827
In the Linux kernel, the following vulnerability has been resolved: virtio-fs: avoid double-free on failed queue setup virtio_fs_setup_vqs() allocates fs->vqs and fs->mq_map before calling virtio_find_vqs(). If virtio_find_vqs() fails, the error path frees both pointers and returns an error to virtio_fs_probe(). virtio_fs_probe() then drops the last kobject reference, and virtio_fs_ktype_release() frees fs->vqs and fs->mq_map again. This leaves dangling pointers in struct virtio_fs and can trigger a double-free during probe failure cleanup. Set fs->vqs and fs->mq_map to NULL immediately after kfree() in the virtio_fs_setup_vqs() error path so that the later kobject release sees an uninitialized state and kfree(NULL) becomes harmless. This can be reproduced when a broken virtio-fs device advertises more request queues than the transport actually provides. In that case virtio_find_vqs() fails while setting up the extra queue, and the probe path reaches the double-free cleanup sequence.
CVE-2026-98364
In the Linux kernel, the following vulnerability has been resolved: xfrm: hold net_device reference under RCU in bundle creation xfrm_bundle_create() and xfrm_create_dummy_bundle() read dst->dev into a local pointer without taking a device reference, then pass it to xfrm_fill_dst(). A concurrent RTM_DELLINK replaces dst->dev via dst_dev_put() and frees the old net_device, causing a use-after-free when xfrm6_fill_dst() later dereferences the stale dev pointer. BUG: KASAN: slab-use-after-free in xfrm6_fill_dst+0x82c/0x860 (net/ipv6/xfrm6_policy.c:86 netdev_hold()) Read of size 8 at addr ffff8880142fe588 by task exploit/153 Call Trace: xfrm6_fill_dst+0x82c/0x860 xfrm_resolve_and_create_bundle+0x21d4/0x2bd0 xfrm_lookup_with_ifid+0x485/0x1640 ip6_dst_lookup_flow+0x19b/0x1e0 udpv6_sendmsg+0x1443/0x2dd0 Fix this by reading dst->dev via dst_dev_rcu() and keeping the RCU read-side critical section active until xfrm_fill_dst() has taken the required device references.
CVE-2026-98432
In the Linux kernel, the following vulnerability has been resolved: ipv4: free inet_opt and ireq_opt after an RCU grace period tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the child socket (newinet->inet_opt) without copying it. Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcp_check_req(). tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt under rcu_read_lock() only, and ip_build_and_send_pkt() and ip_options_build() then read opt->optlen twice. Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and inet_csk_reqsk_queue_drop() calls timer_delete_sync() before the child can be freed. Since commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table"), request sockets are processed without holding the listener lock, so nothing prevents the child socket from being freed while the SYNACK is still being built. TCP child sockets do not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt with a plain kfree(), leading to a use-after-free in ip_options_build(). A similar issue exists with request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program). reqsk_timer_handler() clones the request socket with inet_reqsk_clone(), so that the old request socket and its clone share the same ireq_opt, then reqsk_migrate_reset() clears the pointer in the old one. Another cpu holding a reference on the old request socket can still be using these options (sending a SYNACK, or creating a child in tcp_v4_syn_recv_sock()) when the clone is freed, and tcp_v4_reqsk_destructor() also uses a plain kfree(). Readers already use RCU, and other paths replacing inet_opt (do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use kfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor() as well. IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock() duplicates the options. tcp_v6_reqsk_destructor() has the same migration issue with ipv6_opt, which is only set by CALIPSO. This will be addressed in a separate patch.
CVE-2026-98466
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Transfer the hyp stack pages out of the host stage-2 fix_host_ownership() walks only the linear-map alias of each memblock region, and the per-CPU hyp stack, mapped in the private VA range for its guard page, has none. Walk each stack's VA range with the same walker.
CVE-2026-98725
In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: fix out-of-bounds write in nvmet_auth_challenge() nvmet_auth_challenge() receives its output buffer as a void pointer. sizeof(*d) therefore evaluates to one with GCC and undercounts the fixed challenge header by 15 bytes. A short AUTH_RECEIVE buffer can pass the check before the challenge is copied past the end of its allocation. Use the typed challenge pointer when calculating the response size. BUG: KASAN: slab-out-of-bounds in nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569) Write of size 32 by task kworker/1:1H/64 Workqueue: nvmet_tcp_wq nvmet_tcp_io_work Call Trace: nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569) nvmet_tcp_try_recv_pdu (drivers/nvme/target/tcp.c:1119 drivers/nvme/target/tcp.c:1243) nvmet_tcp_io_work (drivers/nvme/target/tcp.c:1350 drivers/nvme/target/tcp.c:1382 drivers/nvme/target/tcp.c:1445) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address is located 16 bytes inside of allocated 33-byte region [ffff888000554e80, ffff888000554ea1) Kernel panic - not syncing: KASAN: panic_on_warn set ...
Update packages.
In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.
In the Linux kernel, the following vulnerability has been resolved: ipv6: sit: reload inner IPv6 header after GSO offloads ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb header to be reloaded after the call. If the later skb_realloc_headroom() branch is not taken, SIT uses the stale iph6 pointer to read the inner hop limit and DS field. That can read from a freed skb head after the old head's remaining clone is released. Reload iph6 after the offload helper succeeds and before subsequent reads from the inner IPv6 header. Keep the existing reload after skb_realloc_headroom(), since that branch can also replace the skb.
In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.
In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: terminate the RX channel on TX prepare failure path When dmaengine_prep_slave_sg() fails for the TX channel, the error path terminates the TX DMA channel but leaves the RX channel running. Since the RX channel was already submitted and issued prior to preparing the TX descriptor, returning -EINVAL causes the SPI core to unmap the DMA buffers while the RX DMA engine continues writing to them, leading to potential memory corruption or use-after-free. Terminate the RX channel before returning on the TX prepare failure path.
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: userspace: fix use-after-free in get_local_id In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] <IRQ> [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a "not found" sentinel.
In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing "if (buf) transport_kunmap_data_sg(cmd)" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.
In the Linux kernel, the following vulnerability has been resolved: tipc: require net admin for TIPCv2 netlink mutators TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable. The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers). A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix UAF in pair command cancellation The pairing completion and authentication failure callbacks look up the pending MGMT_OP_PAIR_DEVICE command by walking hdev->mgmt_pending. The lookup returned a command that was still linked on the shared pending list, without keeping mgmt_pending_lock held for the later dereference and removal. A concurrent MGMT_OP_CANCEL_PAIR_DEVICE request can remove and free the same pending command before the callback uses it. The reverse race is also possible when cancel_pair_device() gets a command from pending_find() and a callback removes it before the cancel path dereferences it. This can lead to a use-after-free and a second list_del(). Make the pairing lookup helpers transfer ownership of the pending command by removing it from hdev->mgmt_pending while holding mgmt_pending_lock. The callbacks and cancel path then complete the command and free it directly, so racing paths cannot find or free the same command again. Take a temporary hci_conn reference in cancel_pair_device() because the command completion drops the reference stored in the pending command.
In the Linux kernel, the following vulnerability has been resolved: packet: use consistent hard_header_len in non-ring send paths packet_snd() reads dev->hard_header_len multiple times while allocating and constructing an skb. Device reconfiguration can change this value concurrently, for example through bonding device type changes. For SOCK_RAW, packet_snd() can save a larger value in reserve and later allocate headroom using a smaller value. Moving skb->data back by reserve then places it before skb->head, and the following copy from userspace can attempt an out-of-bounds write. packet_sendmsg_spkt() has the same issue because it calculates its reservation and header offset from separate reads before dropping the RCU read lock to allocate the skb. Add LL_RESERVED_SPACE_EX() for callers that already saved a header length. Read hard_header_len once in packet_snd() and use it for allocation and construction. In packet_sendmsg_spkt(), preserve the allocation-time value through the device lookup retry. The separate SOCK_DGRAM consistency problem between hard_header_len and header_ops->create is not addressed here.
In the Linux kernel, the following vulnerability has been resolved: mptcp: options: reset DSS fields in case of unexpected size A remote peer could send a malformed DSS with a wrong size, followed by another DSS or MPC + Data. In this case, the first suboption will be ignored, but leaving some fields written, which could lead to inconsistency or access uninitialized data. Explicitly reset the fields that could have been modified in case of unexpected size.
In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Reserve a terminator byte for the login payload iscsi_target_check_login_request() rejects a login PDU whose DataSegmentLength exceeds MAX_KEY_VALUE_PAIRS, but the test is '>' and login->req_buf is allocated with exactly MAX_KEY_VALUE_PAIRS bytes. Since iscsit_get_login_rx() receives payload_length + padding bytes, where padding = ((-payload_length) & 3); any payload_length from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator. The buffer is subsequently consumed as a C string. In the CHAP path chap_check_algorithm() calls kstrdup(a_str), and extract_param() calls strstr(in_buf, pattern) followed by strlen_semi(), none of which take a length. convert_null_to_semi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsi_login_zero_tsih_s2() rewrites AuthMethod to None and the CHAP path is never entered. Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAX_KEY_VALUE_PAIRS bytes, so the buffer is always terminated.
In the Linux kernel, the following vulnerability has been resolved: smb: client: bound dirent name against end of SMB response in cifs_filldir cifs_filldir() copies the entry name out of an SMB1 TRANS2_FIND_FIRST / FIND_NEXT response using a length (de.namelen) supplied by the server. The kmalloc'd SMB response buffer is bounded, but nothing checks that de.name + de.namelen still lies inside that buffer before the eventual filldir64() -> verify_dirent_name() -> memchr() reads namelen bytes. A hostile SMB1 server that returns an oversized FileNameLength in a directory entry therefore causes memchr() to read past the end of the response slab buffer. Reachable from any user who can list a directory on a CIFS mount served by an attacker-controlled server (getdents64() on the mounted directory): BUG: KASAN: slab-out-of-bounds in memchr+0x71/0x80 Read of size 1 at addr ffff88800e0640cc by task poc/115 Call Trace: dump_stack_lvl+0x64/0x80 print_report+0xce/0x620 kasan_report+0xec/0x120 memchr+0x71/0x80 filldir64+0x4c/0x6a0 cifs_filldir.constprop.0+0x9bb/0x1e00 cifs_readdir+0x2101/0x3380 iterate_dir+0x19c/0x520 __x64_sys_getdents64+0x126/0x210 do_syscall_64+0x107/0x5a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Pass the end-of-response pointer down to cifs_filldir() and reject entries whose name would extend past that boundary. This bug was discovered by Artiphishell's vTriage pipeline, which generated a userspace reproducer (an emulated hostile SMB1 server plus a getdents64() client) that reliably triggers the KASAN report on an unpatched kernel. The fix below was drafted with the Claude coding assistant; a userspace reproducer is available on request.
N/A
SRPMS
- kernel-5.14.0-687.64.1.el9_8.src.rpm
MD5: d67ba6bcd17c1055cc490884084d79e7
SHA-256: a1e755956711ed1aefea5b31cd29f5815f5a25068a017da6ba7801f10514aacd
Size: 145.89 MB
Asianux Server 9 for x86_64
- kernel-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 01e71566b4e2685c5ff120f018af9e75
SHA-256: c3f2eef430c29fee6ba1d47f79086afb46748aede133d5e0ca3f5533e59a06b3
Size: 1.06 MB - kernel-abi-stablelists-5.14.0-687.64.1.el9_8.noarch.rpm
MD5: cdc556242a78bb59d13b4527ffe29060
SHA-256: dd0947845e49e28c73bedd3ddc32febe687c8104ff0a82db53edcea66e7e4131
Size: 1.09 MB - kernel-core-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: ff8c8e3ffd5c9c0797420a45d11e20fe
SHA-256: fc08e68a5802801d28cfda9add99b39ce66210f8b70186ca8d64f0d3bee85522
Size: 17.39 MB - kernel-cross-headers-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 1f34262bc300cadf5ca6850126b3f01f
SHA-256: 36b61ff1ee1d9bf5a8cd456ef6d4fa53dcb49ef01a40240d37e6ccf6222606cd
Size: 8.12 MB - kernel-debug-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: c00f9519524572d1e7205edbff95ade0
SHA-256: c816d5a08f7ccee7c6df03c650daf61babd55b9af5a8c61143f7436fe0033f0e
Size: 1.06 MB - kernel-debug-core-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 698d437675abd80460a83124f06eaee4
SHA-256: 6d77e62339d6b3bdc9c151fdd2d0163dedcf55c6f7fbd8d1c210e6fd8320ac45
Size: 31.26 MB - kernel-debug-devel-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: ceef959792b670a9c82a36e48e5fc58c
SHA-256: b54ee52334e22dc1d0f8e1676f902d6a9fbda0a5f3c51944b53c05ee0cf57f35
Size: 21.49 MB - kernel-debug-devel-matched-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: ec7f3e9019b9ac37ef7646eb5a836a6b
SHA-256: 1dd4684333c007bcf9b8ca14c0f7a47c7da70bce3ca0e500019a108be4b11a83
Size: 1.06 MB - kernel-debug-modules-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 9c8b2ad543abca7f7cee1b33422b056b
SHA-256: dca2e12a34d95a744f8a2867245f6e6c7bd30e54cbaaf8843935e3b2703a1f71
Size: 70.27 MB - kernel-debug-modules-core-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: fe5ff6302a252e10d07f84973dee28d9
SHA-256: 9e044a8fcd2355dbe6edc01888c3c18ab98a54fd0385b529f61e8ceaaff1b681
Size: 49.99 MB - kernel-debug-modules-extra-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 224020a1f323d5ac446930ac9897fb7d
SHA-256: 7a778b2a85c4ab235b5fc689e8e62602e96a847a8c7c355721206abd4b2cc873
Size: 1.86 MB - kernel-debug-uki-virt-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 1c97538c74dba735e87249611ddacfe6
SHA-256: 7fba72316483e6735b23ae748fcfb557bb16e007f0772f8dd8ba9fa96929be2d
Size: 88.22 MB - kernel-devel-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: c7f983075221fcd3a9c5197db6e19ff5
SHA-256: 95bfeaf3dd1bbadb336fac98081e1ffb265fe1aa3fe7c3892f9a674ea6e4864f
Size: 21.29 MB - kernel-devel-matched-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 2e056fe4b44beaf8f05ecc79dce037ee
SHA-256: 93ddbb7ac924f63873da97e3f992f631ee044f71c05a7a7e414e9e653d93520e
Size: 1.06 MB - kernel-doc-5.14.0-687.64.1.el9_8.noarch.rpm
MD5: 120486e3adda785ae753b31f88918549
SHA-256: a9f1ff76b43e11e8f8203a73d12909e4d7ce4b612eedb278034ce42f717ef5f3
Size: 39.08 MB - kernel-headers-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 96f0a3b2419411b5be79f81a3da62969
SHA-256: 9677e5e60f364a2bab59cf698eb501db57493db3b97fa9cfc656b6a4cb7a8aad
Size: 2.85 MB - kernel-modules-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 28411fc104e8a35081d2c6a4b1a3cedd
SHA-256: 264f3f32a23703ac4827bb773e9c1b95921528bed4f4818cce8aed9bef076919
Size: 40.06 MB - kernel-modules-core-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 0a93f8a26777e9fe9cf78fafc9b1b414
SHA-256: fa0028af372d7735b020e14300f91aa82158a381ccd096423755cad9ff856a33
Size: 31.13 MB - kernel-modules-extra-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: e4b7c5b9869a64461fe006711a7fdedc
SHA-256: 60e32949e2d44b7301fc5b708590006cfb9f245a9ffa75626549ca352760bc88
Size: 1.50 MB - kernel-rt-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: d0e37d3b77d5914c370e6e17497f4ea5
SHA-256: 022a905083f6b5b1988255869eb701dc35c2202e47fdd5dd527382cbe5b0c4e3
Size: 1.06 MB - kernel-rt-core-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: fe64f538778b4f24b67951e4d3614787
SHA-256: cccf9ecb68c1bd49d1ffb69b850c2c5540d42283e6f20980aed9d83f4386e392
Size: 17.29 MB - kernel-rt-debug-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: dabd36b5fab93e60ca145f47e7c4f6c4
SHA-256: 789a937678948873346fa46b9275c208a14e318f5736090bb3c86ebee90e4818
Size: 1.06 MB - kernel-rt-debug-core-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 26f3d13cb381e29c7f10431af4170640
SHA-256: c2a8ef5d0a9e5df7820c1904c4d2ca982b36507369bd77f0f9c2270f5947af20
Size: 18.75 MB - kernel-rt-debug-devel-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 9e7152ce9fedc7cadcddbcb59cca6ab7
SHA-256: a871b737441051a6e6a52c8eb333bfdeebc5e6283e32c8425aa79d446ca4b4f0
Size: 21.42 MB - kernel-rt-debug-modules-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 71e93b56120c2287ba48b4b5b102b641
SHA-256: c0aea0d9063cb2202997fa05d7b51a2507855fa04bc108aeb86d5e07190bc515
Size: 41.63 MB - kernel-rt-debug-modules-core-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 5435dce55901ff8f901a6896729e9e4b
SHA-256: be1b5ab7c6bdc18bbad53a8df95fff4362ddc2675c5d0cf8ee956016c0046d2b
Size: 32.31 MB - kernel-rt-debug-modules-extra-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: f95c0c434b08243a448a8eb5f4c9e379
SHA-256: 931c6eb3236690d4a15944df0854f9036f6f5de740dfc7ad5fb31725751ea7fa
Size: 1.53 MB - kernel-rt-devel-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 2a47efbb1ed8fa82af9a79ac3ebfe543
SHA-256: 0fbb0d852914f7b260fc749dd815c5a0ce4a16f7deb5e55edb90dcb2b670e157
Size: 21.27 MB - kernel-rt-modules-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 528eeabb605e92968e263d46437e1b2a
SHA-256: a4f112e6223a4e95d528d4d728e64fa8d5db4031f97aeafca3b98f5c8c835295
Size: 40.11 MB - kernel-rt-modules-core-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: a1eebd66ae929bf2f4a6eabe9b6703bc
SHA-256: 1e647052deb2c9781ceeb67bb191f6563b42ebff274f953c31c70ec9d2d9c3d7
Size: 31.22 MB - kernel-rt-modules-extra-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 320bde83f2b9d5c50430053195ec6241
SHA-256: d5ec41a62e9bb502931a6c4f5983f8ba1c1cca909365be0691537621e702f2fd
Size: 1.50 MB - kernel-tools-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 0f4a640e10129729c90a5737c346a28e
SHA-256: 46775c34a3875b932e075801180bd668bbcd25f818ba150a92a8576f55fb318c
Size: 1.35 MB - kernel-tools-libs-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 372cef0b3419df3ea7d3b76eeaa78ac9
SHA-256: c5662b82ad623d835e7022e8d422a135ea193b6679886d1e8376e2065d743a60
Size: 1.07 MB - kernel-tools-libs-devel-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 1f69fab26a73d631db5e864a232e2886
SHA-256: 25245658106940991a65e617775d80b41c16738608d27e848dd69f3c0f589419
Size: 1.06 MB - kernel-uki-virt-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: d209d6ea7f795cdd12cbac9c19e97696
SHA-256: 71c502fe9a56a34482fc49e3b2bdbe6f4e58c4c4a82040af91edd976eaeaccbf
Size: 66.09 MB - kernel-uki-virt-addons-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 7431019da101a02caf46650bf7eda064
SHA-256: 7ef587ff13aac96a5b72181f7a1297d01cf64f1962d170c1a943785f08824a1f
Size: 1.08 MB - libperf-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: d19a5bde1a0bcf56b56d6e1d10917599
SHA-256: c622dbcd6a5182a894b8d7b8d1fc8a5138f3b0375e5b3247494100a99d25f472
Size: 1.08 MB - perf-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 3891267e5a205aaa5212cbc07737a93a
SHA-256: 226ffd94bf5d367f04d048a8477145af7f95af8fd14bfbb77c5d2a56e2c19b4f
Size: 3.47 MB - python3-perf-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 0f7c4b313f20084f76f766e3f2f08620
SHA-256: eca79f31c53eecdd2dfd00f40e691bc971f7af239ee37f07bcb4ae89d0ec7856
Size: 2.65 MB - rtla-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: ffe8f849d4c5e05d69ed2aac9f262a3d
SHA-256: 46b990ecf54c241d2459695b6e7007858f29612406f22a46a13374c87d870936
Size: 1.13 MB - rv-5.14.0-687.64.1.el9_8.x86_64.rpm
MD5: 858cde5ad1eccd9a0d048671ae26f408
SHA-256: 5b6a8dda69b5fb2d4cf0494150cbef49843a6d82a4a822ddba58b174e33725ad
Size: 1.08 MB