CVE-2026-23377

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

arm64: io: Extract user memory type in ioremap_prot()

The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN:

| Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68

Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().(CVE-2026-23346)

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

ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz

The only user of frag_size field in XDP RxQ info is bpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead of DMA write size. Different assumptions in ice driver configuration lead to negative tailroom.

This allows to trigger kernel panic, when using XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to 6912 and the requested offset to a huge value, e.g. XSK_UMEM__MAX_FRAME_SIZE * 100.

Due to other quirks of the ZC configuration in ice, panic is not observed in ZC mode, but tailroom growing still fails when it should not.

Use fill queue buffer truesize instead of DMA write size in XDP RxQ info. Fix ZC mode too by using the new helper.(CVE-2026-23377)

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

mm/huge_memory: fix folio isn't locked in softleaf_to_folio()

On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows:

CPU0                                             CPU1

deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages

In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags.

This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held.

This is a BUG_ON() before commit 93976a20345b ("mm: eliminate further swapops predicates"), which in merged in v6.19-rc1.

To fix it, add missing smp_rmb() if the softleaf entry…

The Linux Kernel, the operating system core itself.

Security Fix(es):

Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)

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

smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)

In smbd_destroy() we may destroy the memory so we better wait until post_send_credits_work is no longer pending and will never be started again.

I actually just hit the case using rxe:

WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe] ... [ 5305.686979] [ T138] smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687185] [ T138] ? __pfx_smbd_post_recv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 5305.687356] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? _raw_spin_unlock_irqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbd_post_send_credits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? __pfx___schedule+0x10/0x10 [ 5305.687865] [ T138] ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 5305.687875] [ T138] ? queue_delayed_work_on+0x8e/0xa0 [ 5305.687889] [ T138] process_one_work+0x629/0xf80 [ 5305.687908] [ T138] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? __kasan_check_write+0x14/0x30 [ 5305.687933] [ T138] worker_thread+0x87f/0x1570 ...

It means rxe_post_recv was called after rdma_destroy_qp(). This happened because put_receive_buffer() was triggered by ib_drain_qp() and called: queue_work(info->workqueue, &info->post_send_credits_work);(CVE-2025-39932)

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

riscv: Sanitize syscall table indexing under speculation

The syscall number is a user-controlled value used to index into the syscall table. Use array_index_nospec() to clamp this value after the bounds check to prevent speculative out-of-bounds access and subsequent data leakage via cache side channels.(CVE-2025-71203)

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

nvme-fc: release admin tagset if init fails

nvme_fabrics creates an NVMe/FC controller in following path:

nvmf_dev_write()
  -> nvmf_create_ctrl()
    -> nvme_fc_create_ctrl()
      -> nvme_fc_init_ctrl()

nvme_fc_init_ctrl() allocates the admin blk-mq resources right after nvme_add_ctrl() succeeds. If any of the subsequent steps fail (changing the controller state, scheduling connect work, etc.), we jump to the fail_ctrl path, which tears down the controller references but never frees the admin queue/tag set. The leaked blk-mq allocations match the kmemleak report seen during blktests nvme/fc.

Check ctrl->ctrl.admin_tagset in the fail_ctrl path and call nvme_remove_admin_tag_set() when it is set so that all admin queue allocations are reclaimed whenever controller setup aborts.(CVE-2026-23261)

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

arm64: io: Extract user memory type in ioremap_prot()

The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the…

Root has patched CVE-2026-23377 in the linux package for Root:Ubuntu:24.04. Multiple fixed versions available.

In the Linux kernel, the following vulnerability has been resolved: ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz The only user of frag_size field in XDP RxQ info is bpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead of DMA write size. Different assumptions in ice driver configuration lead to negative tailroom. This allows to trigger kernel panic, when using XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to 6912 and the requested offset to a huge value, e.g. XSK_UMEM__MAX_FRAME_SIZE * 100. Due to other quirks of the ZC configuration in ice, panic is not observed in ZC mode, but tailroom growing still fails when it should not. Use fill queue buffer truesize instead of DMA write size in XDP RxQ info. Fix ZC mode too by using the new helper.

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

ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz

The only user of frag_size field in XDP RxQ info is bpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead of DMA write size. Different assumptions in ice driver configuration lead to negative tailroom.

This allows to trigger kernel panic, when using XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to 6912 and the requested offset to a huge value, e.g. XSK_UMEM__MAX_FRAME_SIZE * 100.

Due to other quirks of the ZC configuration in ice, panic is not observed in ZC mode, but tailroom growing still fails when it should not.

Use fill queue buffer truesize instead of DMA write size in XDP RxQ info. Fix ZC mode too by using the new helper.

• nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers
• RDMA/mlx5: Fix unsafe xarray access in implicit ODP handling
• wifi: rtlwifi: pci: wait for firmware loading before releasing memory
• wifi: rtlwifi: fix memory leaks and invalid access at probe error path {CVE-2024-58063}
• tracing: Fix bad hist from corrupting named_triggers list {CVE-2025-21899}
• PM / devfreq: Fix leak in devfreq_dev_release() {CVE-2023-53518}
• net: usb: asix_devices: Fix PHY address mask in MDIO bus initialization {CVE-2025-38725}
• net/sched: Fix backlog accounting in qdisc_dequeue_internal {CVE-2025-37992}
• nfsd: decrease sc_count directly if fail to queue dl_recall {CVE-2025-22025}
• net: usb: asix_devices: add phy_mask for ax88772 mdio bus {CVE-2025-38725}
• nfsd: put dl_stid if fail to queue dl_recall {CVE-2025-22025}
• rtnetlink: add missing netlink_ns_capable() check for peer netns {CVE-2026-31692}
• mm: add smp_rmb() in pfn_swap_entry_to_page() to pair with THP split {CVE-2026-31466}
• net_sched: Flush gso_skb list too during ->change() {CVE-2025-37992}
• io_uring: fix use-after-free of sq->thread in __io_uring_show_fdinfo() {CVE-2025-38106}
• Input: cyapa - add missing input core locking to suspend/resume functions {CVE-2023-52884}
• mtd: rawnand: serialize lock/unlock against other NAND operations {CVE-2026-23434}
• be2net: fix potential memory leak in be_xmit() {CVE-2024-50167}
• net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data {CVE-2024-53058}
• Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet {CVE-2024-55916}
• idpf: detach and close netdevs while handling a reset {CVE-2026-22981}
• ice: fix devlink reload call trace {CVE-2026-23104}
• nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec {CVE-2026-23112}
• bpf: Prevent tailcall infinite loop caused by freplace {CVE-2024-47794}
• crypto: pcrypt - restore callback for non-parallel fallback
• crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY {CVE-2024-56690}
• tracing/histograms: Allow variables to have some modifiers {CVE-2023-53093}
• intel_th: fix device leak on output open() {CVE-2026-23091}
• RDMA/mlx5: Fix implicit ODP hang on parent deregistration
• RDMA/mlx5: Fix implicit ODP use after free {CVE-2025-21714}
• net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping {CVE-2025-38126}
• KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer {CVE-2025-71104}
• i2c: s3c24xx: check the size of the SMBUS message before using it {CVE-2026-31627}
• scsi: qla2xxx: Free sp in error path to fix system crash {CVE-2025-71232}
• nfc: llcp: add missing return after LLCP_CLOSED checks {CVE-2026-31629}
• gfs2: No more self recovery {CVE-2025-38659}
• hugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param() {CVE-2022-50334}
• tracing: Prevent bad count for tracing_cpumask_write {CVE-2024-56763}
• CDC-NCM: avoid overflow in sanity checking {CVE-2022-48938}
• cxl: Fix race of nvdimm_bus object when creating nvdimm objects {CVE-2026-23348}
• KVM: SEV: Protect all of sev_mem_enc_register_region() with kvm->lock {CVE-2026-31592}
• sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting {CVE-2026-23371}
• md/raid1,raid10: don't ignore IO flags {CVE-2025-22125}
• mm: slub: avoid wake up kswapd in set_track_prepare {CVE-2025-39843}
• iommu/vt-d: Disallow dirty tracking if incoherent page walk {CVE-2025-40058}
• backlight: led_bl: Hold led_access lock when calling led_sysfs_disable() {CVE-2025-23144}
• PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1 {CVE-2025-21831}
• drm/amd/display: Add null pointer check for get_first_active_display() {CVE-2025-38362}
• pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()
• pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map {CVE-2022-49832}
• spi: fsl-qspi: Simplify probe error handling using managed API
• spi: fsl-qspi: Fix double cleanup in probe error path
• spi:…

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

ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz

The only user of frag_size field in XDP RxQ info is bpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead of DMA write size. Different assumptions in ice driver configuration lead to negative tailroom.

This allows to trigger kernel panic, when using XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to 6912 and the requested offset to a huge value, e.g. XSK_UMEM__MAX_FRAME_SIZE * 100.

Due to other quirks of the ZC configuration in ice, panic is not observed in ZC mode, but tailroom growing still fails when it should not.

Use fill queue buffer truesize instead of DMA write size in XDP RxQ info. Fix ZC mode too by using the new helper.