{"schema_version":"1.7.2","id":"OESA-2026-2868","modified":"2026-07-06T06:29:45Z","published":"2026-07-06T06:29:45Z","upstream":["CVE-2026-23346","CVE-2026-23377","CVE-2026-31466","CVE-2026-31508","CVE-2026-43323","CVE-2026-43448"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: io: Extract user memory type in ioremap_prot()\n\nThe only caller of ioremap_prot() outside of the generic ioremap()\nimplementation is generic_access_phys(), which passes a 'pgprot_t' value\ndetermined from the user mapping of the target 'pfn' being accessed by\nthe kernel. On arm64, the 'pgprot_t' contains all of the non-address\nbits from the pte, including the permission controls, and so we end up\nreturning a new user mapping from ioremap_prot() which faults when\naccessed from the kernel on systems with PAN:\n\n  | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000\n  | ...\n  | Call trace:\n  |   __memcpy_fromio+0x80/0xf8\n  |   generic_access_phys+0x20c/0x2b8\n  |   __access_remote_vm+0x46c/0x5b8\n  |   access_remote_vm+0x18/0x30\n  |   environ_read+0x238/0x3e8\n  |   vfs_read+0xe4/0x2b0\n  |   ksys_read+0xcc/0x178\n  |   __arm64_sys_read+0x4c/0x68\n\nExtract only the memory type from the user 'pgprot_t' in ioremap_prot()\nand assert that we're being passed a user mapping, to protect us against\nany changes in future that may require additional handling. To avoid\nfalsely flagging users of ioremap(), provide our own ioremap() macro\nwhich simply wraps __ioremap_prot().(CVE-2026-23346)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz\n\nThe only user of frag_size field in XDP RxQ info is\nbpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead\nof DMA write size. Different assumptions in ice driver configuration lead\nto negative tailroom.\n\nThis allows to trigger kernel panic, when using\nXDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to\n6912 and the requested offset to a huge value, e.g.\nXSK_UMEM__MAX_FRAME_SIZE * 100.\n\nDue to other quirks of the ZC configuration in ice, panic is not observed\nin ZC mode, but tailroom growing still fails when it should not.\n\nUse fill queue buffer truesize instead of DMA write size in XDP RxQ info.\nFix ZC mode too by using the new helper.(CVE-2026-23377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: fix folio isn't locked in softleaf_to_folio()\n\nOn arm64 server, we found folio that get from migration entry isn't locked\nin softleaf_to_folio().  This issue triggers when mTHP splitting and\nzap_nonpresent_ptes() races, and the root cause is lack of memory barrier\nin softleaf_to_folio().  The race is as follows:\n\n\tCPU0                                             CPU1\n\ndeferred_split_scan()                              zap_nonpresent_ptes()\n  lock folio\n  split_folio()\n    unmap_folio()\n      change ptes to migration entries\n    __split_folio_to_order()                         softleaf_to_folio()\n      set flags(including PG_locked) for tail pages    folio = pfn_folio(softleaf_to_pfn(entry))\n      smp_wmb()                                        VM_WARN_ON_ONCE(!folio_test_locked(folio))\n      prep_compound_page() for tail pages\n\nIn __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages\nare visible before the tail page becomes non-compound.  smp_wmb() should\nbe paired with smp_rmb() in softleaf_to_folio(), which is missed.  As a\nresult, if zap_nonpresent_ptes() accesses migration entry that stores tail\npfn, softleaf_to_folio() may see the updated compound_head of tail page\nbefore page->flags.\n\nThis issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio()\nbecause of the race between folio split and zap_nonpresent_ptes()\nleading to a folio incorrectly undergoing modification without a folio\nlock being held.\n\nThis is a BUG_ON() before commit 93976a20345b ("mm: eliminate further\nswapops predicates"), which in merged in v6.19-rc1.\n\nTo fix it, add missing smp_rmb() if the softleaf entry is migration entry\nin softleaf_to_folio() and softleaf_to_page().\n\n[(CVE-2026-31466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: Avoid releasing netdev before teardown completes\n\nThe patch cited in the Fixes tag below changed the teardown code for\nOVS ports to no longer unconditionally take the RTNL. After this change,\nthe netdev_destroy() callback can proceed immediately to the call_rcu()\ninvocation if the IFF_OVS_DATAPATH flag is already cleared on the\nnetdev.\n\nThe ovs_netdev_detach_dev() function clears the flag before completing\nthe unregistration, and if it gets preempted after clearing the flag (as\ncan happen on an -rt kernel), netdev_destroy() can complete and the\ndevice can be freed before the unregistration completes. This leads to a\nsplat like:\n\n[  998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI\n[  998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT\n[  998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025\n[  998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0\n[  998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90\n[  998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246\n[  998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000\n[  998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05\n[  998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000\n[  998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006\n[  998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000\n[  998.393931] FS:  00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000\n[  998.393936] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0\n[  998.393944] PKRU: 55555554\n[  998.393946] Call Trace:\n[  998.393949]  <TASK>\n[  998.393952]  ? show_trace_log_lvl+0x1b0/0x2f0\n[  998.393961]  ? show_trace_log_lvl+0x1b0/0x2f0\n[  998.393975]  ? dp_device_event+0x41/0x80 [openvswitch]\n[  998.394009]  ? __die_body.cold+0x8/0x12\n[  998.394016]  ? die_addr+0x3c/0x60\n[  998.394027]  ? exc_general_protection+0x16d/0x390\n[  998.394042]  ? asm_exc_general_protection+0x26/0x30\n[  998.394058]  ? dev_set_promiscuity+0x8d/0xa0\n[  998.394066]  ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch]\n[  998.394092]  dp_device_event+0x41/0x80 [openvswitch]\n[  998.394102]  notifier_call_chain+0x5a/0xd0\n[  998.394106]  unregister_netdevice_many_notify+0x51b/0xa60\n[  998.394110]  rtnl_dellink+0x169/0x3e0\n[  998.394121]  ? rt_mutex_slowlock.constprop.0+0x95/0xd0\n[  998.394125]  rtnetlink_rcv_msg+0x142/0x3f0\n[  998.394128]  ? avc_has_perm_noaudit+0x69/0xf0\n[  998.394130]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n[  998.394132]  netlink_rcv_skb+0x50/0x100\n[  998.394138]  netlink_unicast+0x292/0x3f0\n[  998.394141]  netlink_sendmsg+0x21b/0x470\n[  998.394145]  ____sys_sendmsg+0x39d/0x3d0\n[  998.394149]  ___sys_sendmsg+0x9a/0xe0\n[  998.394156]  __sys_sendmsg+0x7a/0xd0\n[  998.394160]  do_syscall_64+0x7f/0x170\n[  998.394162]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  998.394165] RIP: 0033:0x7fad61bf4724\n[  998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89\n[  998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n[  998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724\n[  998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003\n[  998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f\n[  998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2\n---truncated---(CVE-2026-31508)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/fair: Fix zero_vruntime tracking fix\n\nJohn reported that stress-ng-yield could make his machine unhappy and\nmanaged to bisect it to commit b3d99f43c72b ("sched/fair: Fix\nzero_vruntime tracking").\n\nThe combination of yield and that commit was specific enough to\nhypothesize the following scenario:\n\nSuppose we have 2 runnable tasks, both doing yield. Then one will be\neligible and one will not be, because the average position must be in\nbetween these two entities.\n\nTherefore, the runnable task will be eligible, and be promoted a full\nslice (all the tasks do is yield after all). This causes it to jump over\nthe other task and now the other task is eligible and current is no\nlonger. So we schedule.\n\nSince we are runnable, there is no {de,en}queue. All we have is the\n__{en,de}queue_entity() from {put_prev,set_next}_task(). But per the\nfingered commit, those two no longer move zero_vruntime.\n\nAll that moves zero_vruntime are tick and full {de,en}queue.\n\nThis means, that if the two tasks playing leapfrog can reach the\ncritical speed to reach the overflow point inside one tick's worth of\ntime, we're up a creek.\n\nAdditionally, when multiple cgroups are involved, there is no guarantee\nthe tick will in fact hit every cgroup in a timely manner. Statistically\nspeaking it will, but that same statistics does not rule out the\npossibility of one cgroup not getting a tick for a significant amount of\ntime -- however unlikely.\n\nTherefore, just like with the yield() case, force an update at the end\nof every slice. This ensures the update is never more than a single\nslice behind and the whole thing is within 2 lag bounds as per the\ncomment on entity_key().(CVE-2026-43323)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-pci: Fix race bug in nvme_poll_irqdisable()\n\nIn the following scenario, pdev can be disabled between (1) and (3) by\n(2). This sets pdev->msix_enabled = 0. Then, pci_irq_vector() will\nreturn MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2).\nThis causes IRQ warning because it tries to enable INTx IRQ that has\nnever been disabled before.\n\nTo fix this, save IRQ number into a local variable and ensure\ndisable_irq() and enable_irq() operate on the same IRQ number.  Even if\npci_free_irq_vectors() frees the IRQ concurrently, disable_irq() and\nenable_irq() on a stale IRQ number is still valid and safe, and the\ndepth accounting reamins balanced.\n\ntask 1:\nnvme_poll_irqdisable()\n  disable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(1)\n  enable_irq(pci_irq_vector(pdev, nvmeq->cq_vector))  ...(3)\n\ntask 2:\nnvme_reset_work()\n  nvme_dev_disable()\n    pdev->msix_enable = 0;  ...(2)\n\ncrash log:\n\n------------[ cut here ]------------\nUnbalanced enable for IRQ 10\nWARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26\nModules linked in:\nCPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: kblockd blk_mq_timeout_work\nRIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753\nCode: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9\nRSP: 0018:ffffc900001bf550 EFLAGS: 00010046\nRAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90\nRDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0\nRBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001\nR10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000\nR13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293\nFS:  0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0\nCall Trace:\n <TASK>\n enable_irq+0x121/0x1e0 kernel/irq/manage.c:797\n nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494\n nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744\n blk_mq_rq_timed_out block/blk-mq.c:1653 [inline]\n blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721\n bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292\n __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline]\n sbitmap_for_each_set include/linux/sbitmap.h:290 [inline]\n bt_for_each block/blk-mq-tag.c:324 [inline]\n blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536\n blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763\n process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257\n process_scheduled_works kernel/workqueue.c:3340 [inline]\n worker_thread+0x65c/0xe60 kernel/workqueue.c:3421\n kthread+0x41a/0x930 kernel/kthread.c:463\n ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n </TASK>\nirq event stamp: 74478\nhardirqs last  enabled at (74477): [<ffffffffb5720a9c>] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline]\nhardirqs last  enabled at (74477): [<ffffffffb5720a9c>] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202\nhardirqs last disabled at (74478): [<ffffffffb57207b5>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]\nhardirqs last disabled at (74478): [<ffffffffb57207b5>] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162\nsoftirqs last  enabled at (74304): [<ffffffffb1e9466c>] __do_softirq kernel/softirq.c:656 [inline]\nsoftirqs last  enabled at (74304): [<ffffffffb1e9466c>] invoke_softirq kernel/softirq.c:496 [inline]\nsoftirqs last  enabled at (74304): [<ffffffffb1e9466c>] __irq_exit_rcu+0xdc/0x120\n---truncated---(CVE-2026-43448)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.1.17.155.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","kernel-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","perf-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.1.17.155.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-145.1.17.155.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","kernel-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","perf-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.1.17.155.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2868"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23346"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23377"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31466"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31508"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43323"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43448"}],"database_specific":{"severity":"High"}}