{ "document":{ "aggregate_severity":{ "namespace":"https://nvd.nist.gov/vuln-metrics/cvss", "text":"High" }, "category":"csaf_vex", "csaf_version":"2.0", "distribution":{ "tlp":{ "label":"WHITE", "url":"https:/www.first.org/tlp/" } }, "lang":"en", "notes":[ { "text":"kernel security update", "category":"general", "title":"Synopsis" }, { "text":"An update for kernel is now available for openEuler-24.03-LTS-SP2", "category":"general", "title":"Summary" }, { "text":"The Linux Kernel, the operating system core itself.\n\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntimers: Fix NULL function pointer race in timer_shutdown_sync()\n\nThere is a race condition between timer_shutdown_sync() and timer\nexpiration that can lead to hitting a WARN_ON in expire_timers().\n\nThe issue occurs when timer_shutdown_sync() clears the timer function\nto NULL while the timer is still running on another CPU. The race\nscenario looks like this:\n\nCPU0\t\t\t\t\tCPU1\n\t\t\t\t\t\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tbase->running_timer = timer;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t[call_timer_fn enter]\n\t\t\t\t\tmod_timer()\n\t\t\t\t\t...\ntimer_shutdown_sync()\nlock_timer_base()\n// For now, will not detach the timer but only clear its function to NULL\nif (base->running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer->function = NULL;\nunlock_timer_base()\n\t\t\t\t\t[call_timer_fn exit]\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\tbase->running_timer = NULL;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t...\n\t\t\t\t\t// Now timer is pending while its function set to NULL.\n\t\t\t\t\t// next timer trigger\n\t\t\t\t\t\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tWARN_ON_ONCE(!fn) // hit\n\t\t\t\t\t...\nlock_timer_base()\n// Now timer will detach\nif (base->running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer->function = NULL;\nunlock_timer_base()\n\nThe problem is that timer_shutdown_sync() clears the timer function\nregardless of whether the timer is currently running. This can leave a\npending timer with a NULL function pointer, which triggers the\nWARN_ON_ONCE(!fn) check in expire_timers().\n\nFix this by only clearing the timer function when actually detaching the\ntimer. If the timer is running, leave the function pointer intact, which is\nsafe because the timer will be properly detached when it finishes running.(CVE-2025-68214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency\n\nUnder high concurrency, A tree-connection object (tcon) is freed on\na disconnect path while another path still holds a reference and later\nexecutes *_put()/write on it.(CVE-2025-68817)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Cap the number of PCR banks\n\ntpm2_get_pcr_allocation() does not cap any upper limit for the number of\nbanks. Cap the limit to eight banks so that out of bounds values coming\nfrom external I/O cause on only limited harm.(CVE-2025-71077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: change all pageblocks migrate type on coalescing\n\nWhen a page is freed it coalesces with a buddy into a higher order page\nwhile possible. When the buddy page migrate type differs, it is expected\nto be updated to match the one of the page being freed.\n\nHowever, only the first pageblock of the buddy page is updated, while the\nrest of the pageblocks are left unchanged.\n\nThat causes warnings in later expand() and other code paths (like below),\nsince an inconsistency between migration type of the list containing the\npage and the page-owned pageblocks migration types is introduced.\n\n[ 308.986589] ------------[ cut here ]------------\n[ 308.987227] page type is 0, passed migratetype is 1 (nr=256)\n[ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270\n[ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E)\n[ 308.987439] Unloaded tainted modules: hmac_s390(E):2\n[ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT\n[ 308.987657] Tainted: [E]=UNSIGNED_MODULE\n[ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0)\n[ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270)\n[ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3\n[ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88\n[ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300\n[ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008\n[ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0\n[ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4\n 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60\n #00000349976fa5fc: af000000\t\tmc\t0,0\n >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498\n 00000349976fa604: b9040026\t\tlgr\t%r2,%r6\n 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906\n 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0\n 00000349976fa614: af000000\t\tmc\t0,0\n[ 308.987734] Call Trace:\n[ 308.987738] [<00000349976fa600>] expand+0x240/0x270\n[ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270)\n[ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940\n[ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0\n[ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40\n[ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0\n[ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400\n[ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220\n[ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0\n[ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0\n[ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240\n[ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210\n[ 308.987804] [<00000349976cb0\n---truncated---(CVE-2025-71134)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: properly keep track of conduit reference\n\nProblem description\n-------------------\n\nDSA has a mumbo-jumbo of reference handling of the conduit net device\nand its kobject which, sadly, is just wrong and doesn't make sense.\n\nThere are two distinct problems.\n\n1. The OF path, which uses of_find_net_device_by_node(), never releases\n the elevated refcount on the conduit's kobject. Nominally, the OF and\n non-OF paths should result in objects having identical reference\n counts taken, and it is already suspicious that\n dsa_dev_to_net_device() has a put_device() call which is missing in\n dsa_port_parse_of(), but we can actually even verify that an issue\n exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command\n \"before\" and \"after\" applying this patch:\n\n(unbind the conduit driver for net device eno2)\necho 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind\n\nwe see these lines in the output diff which appear only with the patch\napplied:\n\nkobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)\nkobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)\n\n2. After we find the conduit interface one way (OF) or another (non-OF),\n it can get unregistered at any time, and DSA remains with a long-lived,\n but in this case stale, cpu_dp->conduit pointer. Holding the net\n device's underlying kobject isn't actually of much help, it just\n prevents it from being freed (but we never need that kobject\n directly). What helps us to prevent the net device from being\n unregistered is the parallel netdev reference mechanism (dev_hold()\n and dev_put()).\n\nActually we actually use that netdev tracker mechanism implicitly on\nuser ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with\nthe DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link().\nBut time still passes at DSA switch probe time between the initial\nof_find_net_device_by_node() code and the user port creation time, time\nduring which the conduit could unregister itself and DSA wouldn't know\nabout it.\n\nSo we have to run of_find_net_device_by_node() under rtnl_lock() to\nprevent that from happening, and release the lock only with the netdev\ntracker having acquired the reference.\n\nDo we need to keep the reference until dsa_unregister_switch() /\ndsa_switch_shutdown()?\n1: Maybe yes. A switch device will still be registered even if all user\n ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not\n make user port errors fatal\"), and the cpu_dp->conduit pointers\n remain valid. I haven't audited all call paths to see whether they\n will actually use the conduit in lack of any user port, but if they\n do, it seems safer to not rely on user ports for that reference.\n2. Definitely yes. We support changing the conduit which a user port is\n associated to, and we can get into a situation where we've moved all\n user ports away from a conduit, thus no longer hold any reference to\n it via the net device tracker. But we shouldn't let it go nonetheless\n - see the next change in relation to dsa_tree_find_first_conduit()\n and LAG conduits which disappear.\n We have to be prepared to return to the physical conduit, so the CPU\n port must explicitly keep another reference to it. This is also to\n say: the user ports and their CPU ports may not always keep a\n reference to the same conduit net device, and both are needed.\n\nAs for the conduit's kobject for the /sys/class/net/ entry, we don't\ncare about it, we can release it as soon as we hold the net device\nobject itself.\n\nHistory and blame attribution\n-----------------------------\n\nThe code has been refactored so many times, it is very difficult to\nfollow and properly attribute a blame, but I'll try to make a short\nhistory which I hope to be correct.\n\nWe have two distinct probing paths:\n- one for OF, introduced in 2016 i\n---truncated---(CVE-2025-71152)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: rtl8150: fix memory leak on usb_submit_urb() failure\n\nIn async_set_registers(), when usb_submit_urb() fails, the allocated\n async_req structure and URB are not freed, causing a memory leak.\n\n The completion callback async_set_reg_cb() is responsible for freeing\n these allocations, but it is only called after the URB is successfully\n submitted and completes (successfully or with error). If submission\n fails, the callback never runs and the memory is leaked.\n\n Fix this by freeing both the URB and the request structure in the error\n path when usb_submit_urb() fails.(CVE-2025-71154)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix bsg_done() causing double free\n\nKernel panic observed on system,\n\n[5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000\n[5353358.825194] #PF: supervisor write access in kernel mode\n[5353358.825195] #PF: error_code(0x0002) - not-present page\n[5353358.825196] PGD 100006067 P4D 0\n[5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI\n[5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1\n[5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025\n[5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10\n[5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246\n[5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000\n[5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000\n[5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000\n[5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090\n[5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000\n[5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000\n[5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0\n[5353358.825221] PKRU: 55555554\n[5353358.825222] Call Trace:\n[5353358.825223] \n[5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df\n[5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df\n[5353358.825232] ? sg_copy_buffer+0xc8/0x110\n[5353358.825236] ? __die_body.cold+0x8/0xd\n[5353358.825238] ? page_fault_oops+0x134/0x170\n[5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110\n[5353358.825244] ? exc_page_fault+0xa8/0x150\n[5353358.825247] ? asm_exc_page_fault+0x22/0x30\n[5353358.825252] ? memcpy_erms+0x6/0x10\n[5353358.825253] sg_copy_buffer+0xc8/0x110\n[5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx]\n[5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx]\n\nMost routines in qla_bsg.c call bsg_done() only for success cases.\nHowever a few invoke it for failure case as well leading to a double\nfree. Validate before calling bsg_done().(CVE-2025-71238)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: avoid kernel-infoleak from struct iw_point\n\nstruct iw_point has a 32bit hole on 64bit arches.\n\nstruct iw_point {\n void __user *pointer; /* Pointer to the data (in user space) */\n __u16 length; /* number of fields or size in bytes */\n __u16 flags; /* Optional params */\n};\n\nMake sure to zero the structure to avoid disclosing 32bits of kernel data\nto user space.(CVE-2026-22978)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: provide locking for v4_end_grace\n\nWriting to v4_end_grace can race with server shutdown and result in\nmemory being accessed after it was freed - reclaim_str_hashtbl in\nparticularly.\n\nWe cannot hold nfsd_mutex across the nfsd4_end_grace() call as that is\nheld while client_tracking_op->init() is called and that can wait for\nan upcall to nfsdcltrack which can write to v4_end_grace, resulting in a\ndeadlock.\n\nnfsd4_end_grace() is also called by the landromat work queue and this\ndoesn't require locking as server shutdown will stop the work and wait\nfor it before freeing anything that nfsd4_end_grace() might access.\n\nHowever, we must be sure that writing to v4_end_grace doesn't restart\nthe work item after shutdown has already waited for it. For this we\nadd a new flag protected with nn->client_lock. It is set only while it\nis safe to make client tracking calls, and v4_end_grace only schedules\nwork while the flag is set with the spinlock held.\n\nSo this patch adds a nfsd_net field \"client_tracking_active\" which is\nset as described. Another field \"grace_end_forced\", is set when\nv4_end_grace is written. After this is set, and providing\nclient_tracking_active is set, the laundromat is scheduled.\nThis \"grace_end_forced\" field bypasses other checks for whether the\ngrace period has finished.\n\nThis resolves a race which can result in use-after-free.(CVE-2026-22980)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: replace overzealous BUG_ON in osdmap_apply_incremental()\n\nIf the osdmap is (maliciously) corrupted such that the incremental\nosdmap epoch is different from what is expected, there is no need to\nBUG. Instead, just declare the incremental osdmap to be invalid.(CVE-2026-22990)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: return the handler error from mon_handle_auth_done()\n\nCurrently any error from ceph_auth_handle_reply_done() is propagated\nvia finish_auth() but isn't returned from mon_handle_auth_done(). This\nresults in higher layers learning that (despite the monitor considering\nus to be successfully authenticated) something went wrong in the\nauthentication phase and reacting accordingly, but msgr2 still trying\nto proceed with establishing the session in the background. In the\ncase of secure mode this can trigger a WARN in setup_crypto() and later\nlead to a NULL pointer dereference inside of prepare_auth_signature().(CVE-2026-22992)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec\n\nauthencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than\nthe minimum expected length, crypto_authenc_esn_decrypt() can advance past\nthe end of the destination scatterlist and trigger a NULL pointer dereference\nin scatterwalk_map_and_copy(), leading to a kernel panic (DoS).\n\nAdd a minimum AAD length check to fail fast on invalid inputs.(CVE-2026-23060)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: fix potential underflow in virtio_transport_get_credit()\n\nThe credit calculation in virtio_transport_get_credit() uses unsigned\narithmetic:\n\n ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt);\n\nIf the peer shrinks its advertised buffer (peer_buf_alloc) while bytes\nare in flight, the subtraction can underflow and produce a large\npositive value, potentially allowing more data to be queued than the\npeer can handle.\n\nReuse virtio_transport_has_space() which already handles this case and\nadd a comment to make it clear why we are doing that.\n\n[Stefano: use virtio_transport_has_space() instead of duplicating the code]\n[Stefano: tweak the commit message](CVE-2026-23069)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregmap: Fix race condition in hwspinlock irqsave routine\n\nPreviously, the address of the shared member '&map->spinlock_flags' was\npassed directly to 'hwspin_lock_timeout_irqsave'. This creates a race\ncondition where multiple contexts contending for the lock could overwrite\nthe shared flags variable, potentially corrupting the state for the\ncurrent lock owner.\n\nFix this by using a local stack variable 'flags' to store the IRQ state\ntemporarily.(CVE-2026-23071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: cap TX credit to local buffer size\n\nThe virtio transports derives its TX credit directly from peer_buf_alloc,\nwhich is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value.\n\nOn the host side this means that the amount of data we are willing to\nqueue for a connection is scaled by a guest-chosen buffer size, rather\nthan the host's own vsock configuration. A malicious guest can advertise\na large buffer and read slowly, causing the host to allocate a\ncorrespondingly large amount of sk_buff memory.\nThe same thing would happen in the guest with a malicious host, since\nvirtio transports share the same code base.\n\nIntroduce a small helper, virtio_transport_tx_buf_size(), that\nreturns min(peer_buf_alloc, buf_alloc), and use it wherever we consume\npeer_buf_alloc.\n\nThis ensures the effective TX window is bounded by both the peer's\nadvertised buffer and our own buf_alloc (already clamped to\nbuffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer\ncannot force the other to queue more data than allowed by its own\nvsock settings.\n\nOn an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with\n32 guest vsock connections advertising 2 GiB each and reading slowly\ndrove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only\nrecovered after killing the QEMU process. That said, if QEMU memory is\nlimited with cgroups, the maximum memory used will be limited.\n\nWith this patch applied:\n\n Before:\n MemFree: ~61.6 GiB\n Slab: ~142 MiB\n SUnreclaim: ~117 MiB\n\n After 32 high-credit connections:\n MemFree: ~61.5 GiB\n Slab: ~178 MiB\n SUnreclaim: ~152 MiB\n\nOnly ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest\nremains responsive.\n\nCompatibility with non-virtio transports:\n\n - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per\n socket based on the local vsk->buffer_* values; the remote side\n cannot enlarge those queues beyond what the local endpoint\n configured.\n\n - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and\n an MTU bound; there is no peer-controlled credit field comparable\n to peer_buf_alloc, and the remote endpoint cannot drive in-flight\n kernel memory above those ring sizes.\n\n - The loopback path reuses virtio_transport_common.c, so it\n naturally follows the same semantics as the virtio transport.\n\nThis change is limited to virtio_transport_common.c and thus affects\nvirtio-vsock, vhost-vsock, and loopback, bringing them in line with the\n\"remote window intersected with local policy\" behaviour that VMCI and\nHyper-V already effectively have.\n\n[Stefano: small adjustments after changing the previous patch]\n[Stefano: tweak the commit message](CVE-2026-23086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbonding: limit BOND_MODE_8023AD to Ethernet devices\n\nBOND_MODE_8023AD makes sense for ARPHRD_ETHER only.\n\nsyzbot reported:\n\n BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline]\n BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118\nRead of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497\n\nCPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full)\nTainted: [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nCall Trace:\n \n dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n check_region_inline mm/kasan/generic.c:-1 [inline]\n kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200\n __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105\n __hw_addr_create net/core/dev_addr_lists.c:63 [inline]\n __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118\n __dev_mc_add net/core/dev_addr_lists.c:868 [inline]\n dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886\n bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180\n do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963\n do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165\n rtnl_changelink net/core/rtnetlink.c:3776 [inline]\n __rtnl_newlink net/core/rtnetlink.c:3935 [inline]\n rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072\n rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958\n netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550\n netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]\n netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344\n netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:742\n ____sys_sendmsg+0x505/0x820 net/socket.c:2592\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646\n __sys_sendmsg+0x164/0x220 net/socket.c:2678\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307\n do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n \n\nThe buggy address belongs to the variable:\n lacpdu_mcast_addr+0x0/0x40(CVE-2026-23099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvlan: Make the addrs_lock be per port\n\nMake the addrs_lock be per port, not per ipvlan dev.\n\nInitial code seems to be written in the assumption,\nthat any address change must occur under RTNL.\nBut it is not so for the case of IPv6. So\n\n1) Introduce per-port addrs_lock.\n\n2) It was needed to fix places where it was forgotten\nto take lock (ipvlan_open/ipvlan_close)\n\nThis appears to be a very minor problem though.\nSince it's highly unlikely that ipvlan_add_addr() will\nbe called on 2 CPU simultaneously. But nevertheless,\nthis could cause:\n\n1) False-negative of ipvlan_addr_busy(): one interface\niterated through all port->ipvlans + ipvlan->addrs\nunder some ipvlan spinlock, and another added IP\nunder its own lock. Though this is only possible\nfor IPv6, since looks like only ipvlan_addr6_event() can be\ncalled without rtnl_lock.\n\n2) Race since ipvlan_ht_addr_add(port) is called under\ndifferent ipvlan->addrs_lock locks\n\nThis should not affect performance, since add/remove IP\nis a rare situation and spinlock is not taken on fast\npaths.(CVE-2026-23103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag\n\nThis is more of a preventive patch to make the code more consistent and\nto prevent possible exploits that employ child qlen manipulations on qfq.\nuse cl_is_active instead of relying on the child qdisc's qlen to determine\nclass activation.(CVE-2026-23105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()\n\nnft_map_catchall_activate() has an inverted element activity check\ncompared to its non-catchall counterpart nft_mapelem_activate() and\ncompared to what is logically required.\n\nnft_map_catchall_activate() is called from the abort path to re-activate\ncatchall map elements that were deactivated during a failed transaction.\nIt should skip elements that are already active (they don't need\nre-activation) and process elements that are inactive (they need to be\nrestored). Instead, the current code does the opposite: it skips inactive\nelements and processes active ones.\n\nCompare the non-catchall activate callback, which is correct:\n\n nft_mapelem_activate():\n if (nft_set_elem_active(ext, iter->genmask))\n return 0; /* skip active, process inactive */\n\nWith the buggy catchall version:\n\n nft_map_catchall_activate():\n if (!nft_set_elem_active(ext, genmask))\n continue; /* skip inactive, process active */\n\nThe consequence is that when a DELSET operation is aborted,\nnft_setelem_data_activate() is never called for the catchall element.\nFor NFT_GOTO verdict elements, this means nft_data_hold() is never\ncalled to restore the chain->use reference count. Each abort cycle\npermanently decrements chain->use. Once chain->use reaches zero,\nDELCHAIN succeeds and frees the chain while catchall verdict elements\nstill reference it, resulting in a use-after-free.\n\nThis is exploitable for local privilege escalation from an unprivileged\nuser via user namespaces + nftables on distributions that enable\nCONFIG_USER_NS and CONFIG_NF_TABLES.\n\nFix by removing the negation so the check matches nft_mapelem_activate():\nskip active elements, process inactive ones.(CVE-2026-23111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nl2tp: avoid one data-race in l2tp_tunnel_del_work()\n\nWe should read sk->sk_socket only when dealing with kernel sockets.\n\nsyzbot reported the following data-race:\n\nBUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release\n\nwrite to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0:\n sk_set_socket include/net/sock.h:2092 [inline]\n sock_orphan include/net/sock.h:2118 [inline]\n sk_common_release+0xae/0x230 net/core/sock.c:4003\n udp_lib_close+0x15/0x20 include/net/udp.h:325\n inet_release+0xce/0xf0 net/ipv4/af_inet.c:437\n __sock_release net/socket.c:662 [inline]\n sock_close+0x6b/0x150 net/socket.c:1455\n __fput+0x29b/0x650 fs/file_table.c:468\n ____fput+0x1c/0x30 fs/file_table.c:496\n task_work_run+0x131/0x1a0 kernel/task_work.c:233\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]\n exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75\n __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]\n syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]\n do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nread to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1:\n l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418\n process_one_work kernel/workqueue.c:3257 [inline]\n process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340\n worker_thread+0x582/0x770 kernel/workqueue.c:3421\n kthread+0x489/0x510 kernel/kthread.c:463\n ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n\nvalue changed: 0xffff88811b818000 -> 0x0000000000000000(CVE-2026-23120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: annotate data-race in ndisc_router_discovery()\n\nsyzbot found that ndisc_router_discovery() could read and write\nin6_dev->ra_mtu without holding a lock [1]\n\nThis looks fine, IFLA_INET6_RA_MTU is best effort.\n\nAdd READ_ONCE()/WRITE_ONCE() to document the race.\n\nNote that we might also reject illegal MTU values\n(mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch.\n\n[1]\nBUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery\n\nread to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1:\n ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558\n ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841\n icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989\n ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438\n ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489\n NF_HOOK include/linux/netfilter.h:318 [inline]\n ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500\n ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590\n dst_input include/net/dst.h:474 [inline]\n ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79\n...\n\nwrite to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0:\n ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559\n ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841\n icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989\n ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438\n ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489\n NF_HOOK include/linux/netfilter.h:318 [inline]\n ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500\n ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590\n dst_input include/net/dst.h:474 [inline]\n ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79\n...\n\nvalue changed: 0x00000000 -> 0xe5400659(CVE-2026-23124)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetdevsim: fix a race issue related to the operation on bpf_bound_progs list\n\nThe netdevsim driver lacks a protection mechanism for operations on the\nbpf_bound_progs list. When the nsim_bpf_create_prog() performs\nlist_add_tail, it is possible that nsim_bpf_destroy_prog() is\nsimultaneously performs list_del. Concurrent operations on the list may\nlead to list corruption and trigger a kernel crash as follows:\n\n[ 417.290971] kernel BUG at lib/list_debug.c:62!\n[ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1\n[ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 417.291007] Workqueue: events bpf_prog_free_deferred\n[ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0\n[ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8\n[ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246\n[ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000\n[ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180\n[ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003\n[ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20\n[ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000\n[ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000\n[ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0\n[ 417.291088] PKRU: 55555554\n[ 417.291091] Call Trace:\n[ 417.291096] \n[ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim]\n[ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80\n[ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0\n[ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0\n[ 417.291178] process_one_work+0x18a/0x3a0\n[ 417.291188] worker_thread+0x27b/0x3a0\n[ 417.291197] ? __pfx_worker_thread+0x10/0x10\n[ 417.291207] kthread+0xe5/0x120\n[ 417.291214] ? __pfx_kthread+0x10/0x10\n[ 417.291221] ret_from_fork+0x31/0x50\n[ 417.291230] ? __pfx_kthread+0x10/0x10\n[ 417.291236] ret_from_fork_asm+0x1a/0x30\n[ 417.291246] \n\nAdd a mutex lock, to prevent simultaneous addition and deletion operations\non the list.(CVE-2026-23126)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: fix dma_free_coherent() pointer\n\ndma_alloc_coherent() allocates a DMA mapped buffer and stores the\naddresses in XXX_unaligned fields. Those should be reused when freeing\nthe buffer rather than the aligned addresses.(CVE-2026-23133)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: reset sparse-read state in osd_fault()\n\nWhen a fault occurs, the connection is abandoned, reestablished, and any\npending operations are retried. The OSD client tracks the progress of a\nsparse-read reply using a separate state machine, largely independent of\nthe messenger's state.\n\nIf a connection is lost mid-payload or the sparse-read state machine\nreturns an error, the sparse-read state is not reset. The OSD client\nwill then interpret the beginning of a new reply as the continuation of\nthe old one. If this makes the sparse-read machinery enter a failure\nstate, it may never recover, producing loops like:\n\n libceph: [0] got 0 extents\n libceph: data len 142248331 != extent len 0\n libceph: osd0 (1)...:6801 socket error on read\n libceph: data len 142248331 != extent len 0\n libceph: osd0 (1)...:6801 socket error on read\n\nTherefore, reset the sparse-read state in osd_fault(), ensuring retries\nstart from a clean state.(CVE-2026-23136)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nof: unittest: Fix memory leak in unittest_data_add()\n\nIn unittest_data_add(), if of_resolve_phandles() fails, the allocated\nunittest_data is not freed, leading to a memory leak.\n\nFix this by using scope-based cleanup helper __free(kfree) for automatic\nresource cleanup. This ensures unittest_data is automatically freed when\nit goes out of scope in error paths.\n\nFor the success path, use retain_and_null_ptr() to transfer ownership\nof the memory to the device tree and prevent double freeing.(CVE-2026-23137)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conncount: update last_gc only when GC has been performed\n\nCurrently last_gc is being updated everytime a new connection is\ntracked, that means that it is updated even if a GC wasn't performed.\nWith a sufficiently high packet rate, it is possible to always bypass\nthe GC, causing the list to grow infinitely.\n\nUpdate the last_gc value only when a GC has been actually performed.(CVE-2026-23139)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix iloc.bh leak in ext4_xattr_inode_update_ref\n\nThe error branch for ext4_xattr_inode_update_ref forget to release the\nrefcount for iloc.bh. Find this when review code.(CVE-2026-23145)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix segmentation of forwarding fraglist GRO\n\nThis patch enhances GSO segment handling by properly checking\nthe SKB_GSO_DODGY flag for frag_list GSO packets, addressing\nlow throughput issues observed when a station accesses IPv4\nservers via hotspots with an IPv6-only upstream interface.\n\nSpecifically, it fixes a bug in GSO segmentation when forwarding\nGRO packets containing a frag_list. The function skb_segment_list\ncannot correctly process GRO skbs that have been converted by XLAT,\nsince XLAT only translates the header of the head skb. Consequently,\nskbs in the frag_list may remain untranslated, resulting in protocol\ninconsistencies and reduced throughput.\n\nTo address this, the patch explicitly sets the SKB_GSO_DODGY flag\nfor GSO packets in XLAT's IPv4/IPv6 protocol translation helpers\n(bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4). This marks GSO\npackets as potentially modified after protocol translation. As a\nresult, GSO segmentation will avoid using skb_segment_list and\ninstead falls back to skb_segment for packets with the SKB_GSO_DODGY\nflag. This ensures that only safe and fully translated frag_list\npackets are processed by skb_segment_list, resolving protocol\ninconsistencies and improving throughput when forwarding GRO packets\nconverted by XLAT.(CVE-2026-23154)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nefivarfs: fix error propagation in efivar_entry_get()\n\nefivar_entry_get() always returns success even if the underlying\n__efivar_entry_get() fails, masking errors.\n\nThis may result in uninitialized heap memory being copied to userspace\nin the efivarfs_file_read() path.\n\nFix it by returning the error from __efivar_entry_get().(CVE-2026-23156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix race in mptcp_pm_nl_flush_addrs_doit()\n\nsyzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id()\nand/or mptcp_pm_nl_is_backup()\n\nRoot cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit()\nwhich is not RCU ready.\n\nlist_splice_init_rcu() can not be called here while holding pernet->lock\nspinlock.\n\nMany thanks to Eulgyu Kim for providing a repro and testing our patches.(CVE-2026-23169)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: TC, delete flows only for existing peers\n\nWhen deleting TC steering flows, iterate only over actual devcom\npeers instead of assuming all possible ports exist. This avoids\ntouching non-existent peers and ensures cleanup is limited to\ndevices the driver is currently connected to.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 133c8a067 P4D 0\n Oops: Oops: 0002 [#1] SMP\n CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core]\n Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49\n RSP: 0018:ff11000143867528 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000\n RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0\n RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002\n R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78\n R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0\n FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0\n Call Trace:\n \n mlx5e_tc_del_flow+0x46/0x270 [mlx5_core]\n mlx5e_flow_put+0x25/0x50 [mlx5_core]\n mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core]\n tc_setup_cb_reoffload+0x20/0x80\n fl_reoffload+0x26f/0x2f0 [cls_flower]\n ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]\n ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]\n tcf_block_playback_offloads+0x9e/0x1c0\n tcf_block_unbind+0x7b/0xd0\n tcf_block_setup+0x186/0x1d0\n tcf_block_offload_cmd.isra.0+0xef/0x130\n tcf_block_offload_unbind+0x43/0x70\n __tcf_block_put+0x85/0x160\n ingress_destroy+0x32/0x110 [sch_ingress]\n __qdisc_destroy+0x44/0x100\n qdisc_graft+0x22b/0x610\n tc_get_qdisc+0x183/0x4d0\n rtnetlink_rcv_msg+0x2d7/0x3d0\n ? rtnl_calcit.isra.0+0x100/0x100\n netlink_rcv_skb+0x53/0x100\n netlink_unicast+0x249/0x320\n ? __alloc_skb+0x102/0x1f0\n netlink_sendmsg+0x1e3/0x420\n __sock_sendmsg+0x38/0x60\n ____sys_sendmsg+0x1ef/0x230\n ? copy_msghdr_from_user+0x6c/0xa0\n ___sys_sendmsg+0x7f/0xc0\n ? ___sys_recvmsg+0x8a/0xc0\n ? __sys_sendto+0x119/0x180\n __sys_sendmsg+0x61/0xb0\n do_syscall_64+0x55/0x640\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7f35238bb764\n Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55\n RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764\n RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003\n RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20\n R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790\n R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780(CVE-2026-23173)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: aloop: Fix racy access at PCM trigger\n\nThe PCM trigger callback of aloop driver tries to check the PCM state\nand stop the stream of the tied substream in the corresponding cable.\nSince both check and stop operations are performed outside the cable\nlock, this may result in UAF when a program attempts to trigger\nfrequently while opening/closing the tied stream, as spotted by\nfuzzers.\n\nFor addressing the UAF, this patch changes two things:\n- It covers the most of code in loopback_check_format() with\n cable->lock spinlock, and add the proper NULL checks. This avoids\n already some racy accesses.\n- In addition, now we try to check the state of the capture PCM stream\n that may be stopped in this function, which was the major pain point\n leading to UAF.(CVE-2026-23191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Don't clobber irqfd routing type when deassigning irqfd\n\nWhen deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's\nrouting entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86\nand arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to\nhandle a concurrent routing update, verify that the irqfd is still active\nbefore consuming the routing information. As evidenced by the x86 and\narm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),\nclobbering the entry type without notifying arch code is surprising and\nerror prone.\n\nAs a bonus, checking that the irqfd is active provides a convenient\nlocation for documenting _why_ KVM must not consume the routing entry for\nan irqfd that is in the process of being deassigned: once the irqfd is\ndeleted from the list (which happens *before* the eventfd is detached), it\nwill no longer receive updates via kvm_irq_routing_update(), and so KVM\ncould deliver an event using stale routing information (relative to\nKVM_SET_GSI_ROUTING returning to userspace).\n\nAs an even better bonus, explicitly checking for the irqfd being active\nfixes a similar bug to the one the clobbering is trying to prevent: if an\nirqfd is deactivated, and then its routing is changed,\nkvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing()\n(because the irqfd isn't in the list). And so if the irqfd is in bypass\nmode, IRQs will continue to be posted using the old routing information.\n\nAs for kvm_arch_irq_bypass_del_producer(), clobbering the routing type\nresults in KVM incorrectly keeping the IRQ in bypass mode, which is\nespecially problematic on AMD as KVM tracks IRQs that are being posted to\na vCPU in a list whose lifetime is tied to the irqfd.\n\nWithout the help of KASAN to detect use-after-free, the most common\nsympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to\nthe memory for irqfd structure being re-allocated and zeroed, resulting\nin irqfd->irq_bypass_data being NULL when read by\navic_update_iommu_vcpu_affinity():\n\n BUG: kernel NULL pointer dereference, address: 0000000000000018\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test\n Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE\n Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025\n RIP: 0010:amd_iommu_update_ga+0x19/0xe0\n Call Trace:\n \n avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd]\n __avic_vcpu_load+0xf4/0x130 [kvm_amd]\n kvm_arch_vcpu_load+0x89/0x210 [kvm]\n vcpu_load+0x30/0x40 [kvm]\n kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm]\n kvm_vcpu_ioctl+0x571/0x6a0 [kvm]\n __se_sys_ioctl+0x6d/0xb0\n do_syscall_64+0x6f/0x9d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x46893b\n \n ---[ end trace 0000000000000000 ]---\n\nIf AVIC is inhibited when the irfd is deassigned, the bug will manifest as\nlist corruption, e.g. on the next irqfd assignment.\n\n list_add corruption. next->prev should be prev (ffff8d474d5cd588),\n but was 0000000000000000. (next=ffff8d8658f86530).\n ------------[ cut here ]------------\n kernel BUG at lib/list_debug.c:31!\n Oops: invalid opcode: 0000 [#1] SMP\n CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test\n Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE\n Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025\n RIP: 0010:__list_add_valid_or_report+0x97/0xc0\n Call Trace:\n \n avic_pi_update_irte+0x28e/0x2b0 [kvm_amd]\n kvm_pi_update_irte+0xbf/0x190 [kvm]\n kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm]\n irq_bypass_register_consumer+0xcd/0x170 [irqbypa\n---truncated---(CVE-2026-23198)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_u32: use skb_header_pointer_careful()\n\nskb_header_pointer() does not fully validate negative @offset values.\n\nUse skb_header_pointer_careful() instead.\n\nGangMin Kim provided a report and a repro fooling u32_classify():\n\nBUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0\nnet/sched/cls_u32.c:221(CVE-2026-23204)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Prevent excessive number of frames\n\nIn this case, the user constructed the parameters with maxpacksize 40\nfor rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer\nsize for each data URB is maxpacksize * packets, which in this example\nis 40 * 6 = 240; When the user performs a write operation to send audio\ndata into the ALSA PCM playback stream, the calculated number of frames\nis packsize[0] * packets = 264, which exceeds the allocated URB buffer\nsize, triggering the out-of-bounds (OOB) issue reported by syzbot [1].\n\nAdded a check for the number of single data URB frames when calculating\nthe number of frames to prevent [1].\n\n[1]\nBUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487\nWrite of size 264 at addr ffff88804337e800 by task syz.0.17/5506\nCall Trace:\n copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487\n prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611\n prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333(CVE-2026-23208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbonding: annotate data-races around slave->last_rx\n\nslave->last_rx and slave->target_last_arp_rx[...] can be read and written\nlocklessly. Add READ_ONCE() and WRITE_ONCE() annotations.\n\nsyzbot reported:\n\nBUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validate\n\nwrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1:\n bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335\n bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533\n __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039\n __netif_receive_skb_one_core net/core/dev.c:6150 [inline]\n __netif_receive_skb+0x59/0x270 net/core/dev.c:6265\n netif_receive_skb_internal net/core/dev.c:6351 [inline]\n netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410\n...\n\nwrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0:\n bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335\n bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533\n __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039\n __netif_receive_skb_one_core net/core/dev.c:6150 [inline]\n __netif_receive_skb+0x59/0x270 net/core/dev.c:6265\n netif_receive_skb_internal net/core/dev.c:6351 [inline]\n netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410\n br_netif_receive_skb net/bridge/br_input.c:30 [inline]\n NF_HOOK include/linux/netfilter.h:318 [inline]\n...\n\nvalue changed: 0x0000000100005365 -> 0x0000000100005366(CVE-2026-23212)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: fix use-after-free in driver_override_show()\n\nThe driver_override_show() function reads the driver_override string\nwithout holding the device_lock. However, driver_override_store() uses\ndriver_set_override(), which modifies and frees the string while holding\nthe device_lock.\n\nThis can result in a concurrent use-after-free if the string is freed\nby the store function while being read by the show function.\n\nFix this by holding the device_lock around the read operation.(CVE-2026-23221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: split cached_fid bitfields to avoid shared-byte RMW races\n\nis_open, has_lease and on_list are stored in the same bitfield byte in\nstruct cached_fid but are updated in different code paths that may run\nconcurrently. Bitfield assignments generate byte read–modify–write\noperations (e.g. `orb $mask, addr` on x86_64), so updating one flag can\nrestore stale values of the others.\n\nA possible interleaving is:\n CPU1: load old byte (has_lease=1, on_list=1)\n CPU2: clear both flags (store 0)\n CPU1: RMW store (old | IS_OPEN) -> reintroduces cleared bits\n\nTo avoid this class of races, convert these flags to separate bool\nfields.(CVE-2026-23230)", "category":"general", "title":"Description" }, { "text":"An update for kernel is now available for openEuler-22.03-LTS-SP4/openEuler-24.03-LTS-SP2/openEuler-22.03-LTS-SP3.\n\nopenEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.", "category":"general", "title":"Topic" }, { "text":"High", "category":"general", "title":"Severity" }, { "text":"kernel", "category":"general", "title":"Affected Component" } ], "publisher":{ "issuing_authority":"openEuler security committee", "name":"openEuler", "namespace":"https://www.openeuler.org", "contact_details":"openeuler-security@openeuler.org", "category":"vendor" }, "references":[ { "summary":"openEuler-SA-2026-1833", "category":"self", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" }, { "summary":"CVE-2025-68214", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-68214&packageName=kernel" }, { "summary":"CVE-2025-68817", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-68817&packageName=kernel" }, { "summary":"CVE-2025-71077", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-71077&packageName=kernel" }, { "summary":"CVE-2025-71134", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-71134&packageName=kernel" }, { "summary":"CVE-2025-71152", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-71152&packageName=kernel" }, { "summary":"CVE-2025-71154", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-71154&packageName=kernel" }, { "summary":"CVE-2025-71238", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2025-71238&packageName=kernel" }, { "summary":"CVE-2026-22978", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-22978&packageName=kernel" }, { "summary":"CVE-2026-22980", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-22980&packageName=kernel" }, { "summary":"CVE-2026-22990", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-22990&packageName=kernel" }, { "summary":"CVE-2026-22992", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-22992&packageName=kernel" }, { "summary":"CVE-2026-23060", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23060&packageName=kernel" }, { "summary":"CVE-2026-23069", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23069&packageName=kernel" }, { "summary":"CVE-2026-23071", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23071&packageName=kernel" }, { "summary":"CVE-2026-23086", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23086&packageName=kernel" }, { "summary":"CVE-2026-23099", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23099&packageName=kernel" }, { "summary":"CVE-2026-23103", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23103&packageName=kernel" }, { "summary":"CVE-2026-23105", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23105&packageName=kernel" }, { "summary":"CVE-2026-23111", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23111&packageName=kernel" }, { "summary":"CVE-2026-23120", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23120&packageName=kernel" }, { "summary":"CVE-2026-23124", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23124&packageName=kernel" }, { "summary":"CVE-2026-23126", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23126&packageName=kernel" }, { "summary":"CVE-2026-23133", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23133&packageName=kernel" }, { "summary":"CVE-2026-23136", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23136&packageName=kernel" }, { "summary":"CVE-2026-23137", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23137&packageName=kernel" }, { "summary":"CVE-2026-23139", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23139&packageName=kernel" }, { "summary":"CVE-2026-23145", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23145&packageName=kernel" }, { "summary":"CVE-2026-23154", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23154&packageName=kernel" }, { "summary":"CVE-2026-23156", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23156&packageName=kernel" }, { "summary":"CVE-2026-23169", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23169&packageName=kernel" }, { "summary":"CVE-2026-23173", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23173&packageName=kernel" }, { "summary":"CVE-2026-23191", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23191&packageName=kernel" }, { "summary":"CVE-2026-23198", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23198&packageName=kernel" }, { "summary":"CVE-2026-23204", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23204&packageName=kernel" }, { "summary":"CVE-2026-23208", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23208&packageName=kernel" }, { "summary":"CVE-2026-23212", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23212&packageName=kernel" }, { "summary":"CVE-2026-23221", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23221&packageName=kernel" }, { "summary":"CVE-2026-23230", "category":"self", "url":"https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2026-23230&packageName=kernel" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68214" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68817" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71077" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71134" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71152" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71154" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71238" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-22978" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-22980" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-22990" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-22992" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23060" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23069" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23071" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23086" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23099" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23103" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23105" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23111" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23120" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23124" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23126" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23133" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23136" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23137" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23139" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23145" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23154" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23156" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23169" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23173" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23191" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23198" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23204" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23208" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23212" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23221" }, { "summary":"nvd cve", "category":"external", "url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23230" }, { "summary":"openEuler-SA-2026-1833 vex file", "category":"self", "url":"https://repo.openeuler.org/security/data/csaf/advisories/2026/csaf-openeuler-sa-2026-1833.json" } ], "title":"An update for kernel is now available for openEuler-24.03-LTS-SP2", "tracking":{ "initial_release_date":"2026-04-03T20:35:50+08:00", "revision_history":[ { "date":"2026-04-03T20:35:50+08:00", "summary":"Initial", "number":"1.0.0" } ], "generator":{ "date":"2026-04-03T20:35:50+08:00", "engine":{ "name":"openEuler CSAF Tool V1.0" } }, "current_release_date":"2026-04-03T20:35:50+08:00", "id":"openEuler-SA-2026-1833", "version":"1.0.0", "status":"final" } }, "product_tree":{ "branches":[ { "name":"openEuler", "category":"vendor", "branches":[ { "name":"openEuler", "branches":[ { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"openEuler-24.03-LTS-SP2", "name":"openEuler-24.03-LTS-SP2" }, "name":"openEuler-24.03-LTS-SP2", "category":"product_version" } ], "category":"product_name" }, { "name":"aarch64", "branches":[ { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"bpftool-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"bpftool-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"bpftool-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"kernel-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"kernel-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"kernel-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"kernel-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-headers-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"kernel-headers-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"kernel-headers-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-source-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"kernel-source-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"kernel-source-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-tools-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"kernel-tools-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"kernel-tools-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"perf-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"perf-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"perf-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"python3-perf-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"python3-perf-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"python3-perf-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "name":"python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm" }, "name":"python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "category":"product_version" } ], "category":"architecture" }, { "name":"x86_64", "branches":[ { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"bpftool-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"bpftool-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"bpftool-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"kernel-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"kernel-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"kernel-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"kernel-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-headers-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"kernel-headers-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"kernel-headers-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-source-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"kernel-source-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"kernel-source-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-tools-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"kernel-tools-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"kernel-tools-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"perf-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"perf-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"perf-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"python3-perf-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"python3-perf-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"python3-perf-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" }, { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "name":"python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm" }, "name":"python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "category":"product_version" } ], "category":"architecture" }, { "name":"src", "branches":[ { "product":{ "product_identification_helper":{ "cpe":"cpe:/a:openEuler:openEuler:24.03-LTS-SP2" }, "product_id":"kernel-6.6.0-145.0.0.141.oe2403sp2.src.rpm", "name":"kernel-6.6.0-145.0.0.141.oe2403sp2.src.rpm" }, "name":"kernel-6.6.0-145.0.0.141.oe2403sp2.src.rpm", "category":"product_version" } ], "category":"architecture" } ] } ], "relationships":[ { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"bpftool-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:bpftool-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"bpftool-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"kernel-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"kernel-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-headers-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-headers-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"kernel-headers-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-source-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-source-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"kernel-source-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-tools-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-tools-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"kernel-tools-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"perf-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:perf-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"perf-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"python3-perf-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:python3-perf-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"python3-perf-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64", "name":"python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"bpftool-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:bpftool-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"bpftool-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"kernel-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"kernel-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-headers-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-headers-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"kernel-headers-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-source-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-source-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"kernel-source-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-tools-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-tools-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"kernel-tools-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"perf-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:perf-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"perf-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"python3-perf-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:python3-perf-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"python3-perf-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64", "name":"python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64 as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" }, { "relates_to_product_reference":"openEuler-24.03-LTS-SP2", "product_reference":"kernel-6.6.0-145.0.0.141.oe2403sp2.src.rpm", "full_product_name":{ "product_id":"openEuler-24.03-LTS-SP2:kernel-6.6.0-145.0.0.141.oe2403sp2.src", "name":"kernel-6.6.0-145.0.0.141.oe2403sp2.src as a component of openEuler-24.03-LTS-SP2" }, "category":"default_component_of" } ] }, "vulnerabilities":[ { "cve":"CVE-2025-68214", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\ntimers: Fix NULL function pointer race in timer_shutdown_sync()\n\nThere is a race condition between timer_shutdown_sync() and timer\nexpiration that can lead to hitting a WARN_ON in expire_timers().\n\nThe issue occurs when timer_shutdown_sync() clears the timer function\nto NULL while the timer is still running on another CPU. The race\nscenario looks like this:\n\nCPU0\t\t\t\t\tCPU1\n\t\t\t\t\t\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tbase->running_timer = timer;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t[call_timer_fn enter]\n\t\t\t\t\tmod_timer()\n\t\t\t\t\t...\ntimer_shutdown_sync()\nlock_timer_base()\n// For now, will not detach the timer but only clear its function to NULL\nif (base->running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer->function = NULL;\nunlock_timer_base()\n\t\t\t\t\t[call_timer_fn exit]\n\t\t\t\t\tlock_timer_base()\n\t\t\t\t\tbase->running_timer = NULL;\n\t\t\t\t\tunlock_timer_base()\n\t\t\t\t\t...\n\t\t\t\t\t// Now timer is pending while its function set to NULL.\n\t\t\t\t\t// next timer trigger\n\t\t\t\t\t\n\t\t\t\t\texpire_timers()\n\t\t\t\t\tWARN_ON_ONCE(!fn) // hit\n\t\t\t\t\t...\nlock_timer_base()\n// Now timer will detach\nif (base->running_timer != timer)\n\tret = detach_if_pending(timer, base, true);\nif (shutdown)\n\ttimer->function = NULL;\nunlock_timer_base()\n\nThe problem is that timer_shutdown_sync() clears the timer function\nregardless of whether the timer is currently running. This can leave a\npending timer with a NULL function pointer, which triggers the\nWARN_ON_ONCE(!fn) check in expire_timers().\n\nFix this by only clearing the timer function when actually detaching the\ntimer. If the timer is running, leave the function pointer intact, which is\nsafe because the timer will be properly detached when it finishes running.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":[ "openEuler-24.03-LTS-SP2:bpftool-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:kernel-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:kernel-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:kernel-headers-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:kernel-source-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:kernel-tools-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:perf-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:python3-perf-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.aarch64", "openEuler-24.03-LTS-SP2:bpftool-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:bpftool-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:kernel-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:kernel-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:kernel-debugsource-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:kernel-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:kernel-extra-modules-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:kernel-headers-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:kernel-source-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:kernel-tools-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:kernel-tools-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:kernel-tools-devel-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:perf-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:python3-perf-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:python3-perf-debuginfo-6.6.0-145.0.0.141.oe2403sp2.x86_64", "openEuler-24.03-LTS-SP2:kernel-6.6.0-145.0.0.141.oe2403sp2.src" ] }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":4.7, "vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2025-68214" }, { "cve":"CVE-2025-68817", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency\n\nUnder high concurrency, A tree-connection object (tcon) is freed on\na disconnect path while another path still holds a reference and later\nexecutes *_put()/write on it.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.8, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2025-68817" }, { "cve":"CVE-2025-71077", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Cap the number of PCR banks\n\ntpm2_get_pcr_allocation() does not cap any upper limit for the number of\nbanks. Cap the limit to eight banks so that out of bounds values coming\nfrom external I/O cause on only limited harm.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2025-71077" }, { "cve":"CVE-2025-71134", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: change all pageblocks migrate type on coalescing\n\nWhen a page is freed it coalesces with a buddy into a higher order page\nwhile possible. When the buddy page migrate type differs, it is expected\nto be updated to match the one of the page being freed.\n\nHowever, only the first pageblock of the buddy page is updated, while the\nrest of the pageblocks are left unchanged.\n\nThat causes warnings in later expand() and other code paths (like below),\nsince an inconsistency between migration type of the list containing the\npage and the page-owned pageblocks migration types is introduced.\n\n[ 308.986589] ------------[ cut here ]------------\n[ 308.987227] page type is 0, passed migratetype is 1 (nr=256)\n[ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270\n[ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E)\n[ 308.987439] Unloaded tainted modules: hmac_s390(E):2\n[ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT\n[ 308.987657] Tainted: [E]=UNSIGNED_MODULE\n[ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0)\n[ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270)\n[ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3\n[ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88\n[ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300\n[ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008\n[ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0\n[ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4\n 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60\n #00000349976fa5fc: af000000\t\tmc\t0,0\n >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498\n 00000349976fa604: b9040026\t\tlgr\t%r2,%r6\n 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906\n 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0\n 00000349976fa614: af000000\t\tmc\t0,0\n[ 308.987734] Call Trace:\n[ 308.987738] [<00000349976fa600>] expand+0x240/0x270\n[ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270)\n[ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940\n[ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0\n[ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40\n[ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0\n[ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400\n[ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220\n[ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0\n[ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0\n[ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240\n[ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210\n[ 308.987804] [<00000349976cb0\n---truncated---", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2025-71134" }, { "cve":"CVE-2025-71152", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: properly keep track of conduit reference\n\nProblem description\n-------------------\n\nDSA has a mumbo-jumbo of reference handling of the conduit net device\nand its kobject which, sadly, is just wrong and doesn't make sense.\n\nThere are two distinct problems.\n\n1. The OF path, which uses of_find_net_device_by_node(), never releases\n the elevated refcount on the conduit's kobject. Nominally, the OF and\n non-OF paths should result in objects having identical reference\n counts taken, and it is already suspicious that\n dsa_dev_to_net_device() has a put_device() call which is missing in\n dsa_port_parse_of(), but we can actually even verify that an issue\n exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command\n \"before\" and \"after\" applying this patch:\n\n(unbind the conduit driver for net device eno2)\necho 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind\n\nwe see these lines in the output diff which appear only with the patch\napplied:\n\nkobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)\nkobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)\n\n2. After we find the conduit interface one way (OF) or another (non-OF),\n it can get unregistered at any time, and DSA remains with a long-lived,\n but in this case stale, cpu_dp->conduit pointer. Holding the net\n device's underlying kobject isn't actually of much help, it just\n prevents it from being freed (but we never need that kobject\n directly). What helps us to prevent the net device from being\n unregistered is the parallel netdev reference mechanism (dev_hold()\n and dev_put()).\n\nActually we actually use that netdev tracker mechanism implicitly on\nuser ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with\nthe DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link().\nBut time still passes at DSA switch probe time between the initial\nof_find_net_device_by_node() code and the user port creation time, time\nduring which the conduit could unregister itself and DSA wouldn't know\nabout it.\n\nSo we have to run of_find_net_device_by_node() under rtnl_lock() to\nprevent that from happening, and release the lock only with the netdev\ntracker having acquired the reference.\n\nDo we need to keep the reference until dsa_unregister_switch() /\ndsa_switch_shutdown()?\n1: Maybe yes. A switch device will still be registered even if all user\n ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not\n make user port errors fatal\"), and the cpu_dp->conduit pointers\n remain valid. I haven't audited all call paths to see whether they\n will actually use the conduit in lack of any user port, but if they\n do, it seems safer to not rely on user ports for that reference.\n2. Definitely yes. We support changing the conduit which a user port is\n associated to, and we can get into a situation where we've moved all\n user ports away from a conduit, thus no longer hold any reference to\n it via the net device tracker. But we shouldn't let it go nonetheless\n - see the next change in relation to dsa_tree_find_first_conduit()\n and LAG conduits which disappear.\n We have to be prepared to return to the physical conduit, so the CPU\n port must explicitly keep another reference to it. This is also to\n say: the user ports and their CPU ports may not always keep a\n reference to the same conduit net device, and both are needed.\n\nAs for the conduit's kobject for the /sys/class/net/ entry, we don't\ncare about it, we can release it as soon as we hold the net device\nobject itself.\n\nHistory and blame attribution\n-----------------------------\n\nThe code has been refactored so many times, it is very difficult to\nfollow and properly attribute a blame, but I'll try to make a short\nhistory which I hope to be correct.\n\nWe have two distinct probing paths:\n- one for OF, introduced in 2016 i\n---truncated---", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.8, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2025-71152" }, { "cve":"CVE-2025-71154", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: rtl8150: fix memory leak on usb_submit_urb() failure\n\nIn async_set_registers(), when usb_submit_urb() fails, the allocated\n async_req structure and URB are not freed, causing a memory leak.\n\n The completion callback async_set_reg_cb() is responsible for freeing\n these allocations, but it is only called after the URB is successfully\n submitted and completes (successfully or with error). If submission\n fails, the callback never runs and the memory is leaked.\n\n Fix this by freeing both the URB and the request structure in the error\n path when usb_submit_urb() fails.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2025-71154" }, { "cve":"CVE-2025-71238", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix bsg_done() causing double free\n\nKernel panic observed on system,\n\n[5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000\n[5353358.825194] #PF: supervisor write access in kernel mode\n[5353358.825195] #PF: error_code(0x0002) - not-present page\n[5353358.825196] PGD 100006067 P4D 0\n[5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI\n[5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1\n[5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025\n[5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10\n[5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246\n[5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000\n[5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000\n[5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000\n[5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090\n[5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000\n[5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000\n[5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0\n[5353358.825221] PKRU: 55555554\n[5353358.825222] Call Trace:\n[5353358.825223] \n[5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df\n[5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df\n[5353358.825232] ? sg_copy_buffer+0xc8/0x110\n[5353358.825236] ? __die_body.cold+0x8/0xd\n[5353358.825238] ? page_fault_oops+0x134/0x170\n[5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110\n[5353358.825244] ? exc_page_fault+0xa8/0x150\n[5353358.825247] ? asm_exc_page_fault+0x22/0x30\n[5353358.825252] ? memcpy_erms+0x6/0x10\n[5353358.825253] sg_copy_buffer+0xc8/0x110\n[5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx]\n[5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx]\n\nMost routines in qla_bsg.c call bsg_done() only for success cases.\nHowever a few invoke it for failure case as well leading to a double\nfree. Validate before calling bsg_done().", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.8, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2025-71238" }, { "cve":"CVE-2026-22978", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: avoid kernel-infoleak from struct iw_point\n\nstruct iw_point has a 32bit hole on 64bit arches.\n\nstruct iw_point {\n void __user *pointer; /* Pointer to the data (in user space) */\n __u16 length; /* number of fields or size in bytes */\n __u16 flags; /* Optional params */\n};\n\nMake sure to zero the structure to avoid disclosing 32bits of kernel data\nto user space.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"LOW", "baseScore":3.3, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Low", "category":"impact" } ], "title":"CVE-2026-22978" }, { "cve":"CVE-2026-22980", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: provide locking for v4_end_grace\n\nWriting to v4_end_grace can race with server shutdown and result in\nmemory being accessed after it was freed - reclaim_str_hashtbl in\nparticularly.\n\nWe cannot hold nfsd_mutex across the nfsd4_end_grace() call as that is\nheld while client_tracking_op->init() is called and that can wait for\nan upcall to nfsdcltrack which can write to v4_end_grace, resulting in a\ndeadlock.\n\nnfsd4_end_grace() is also called by the landromat work queue and this\ndoesn't require locking as server shutdown will stop the work and wait\nfor it before freeing anything that nfsd4_end_grace() might access.\n\nHowever, we must be sure that writing to v4_end_grace doesn't restart\nthe work item after shutdown has already waited for it. For this we\nadd a new flag protected with nn->client_lock. It is set only while it\nis safe to make client tracking calls, and v4_end_grace only schedules\nwork while the flag is set with the spinlock held.\n\nSo this patch adds a nfsd_net field \"client_tracking_active\" which is\nset as described. Another field \"grace_end_forced\", is set when\nv4_end_grace is written. After this is set, and providing\nclient_tracking_active is set, the laundromat is scheduled.\nThis \"grace_end_forced\" field bypasses other checks for whether the\ngrace period has finished.\n\nThis resolves a race which can result in use-after-free.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.8, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2026-22980" }, { "cve":"CVE-2026-22990", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: replace overzealous BUG_ON in osdmap_apply_incremental()\n\nIf the osdmap is (maliciously) corrupted such that the incremental\nosdmap epoch is different from what is expected, there is no need to\nBUG. Instead, just declare the incremental osdmap to be invalid.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-22990" }, { "cve":"CVE-2026-22992", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: return the handler error from mon_handle_auth_done()\n\nCurrently any error from ceph_auth_handle_reply_done() is propagated\nvia finish_auth() but isn't returned from mon_handle_auth_done(). This\nresults in higher layers learning that (despite the monitor considering\nus to be successfully authenticated) something went wrong in the\nauthentication phase and reacting accordingly, but msgr2 still trying\nto proceed with establishing the session in the background. In the\ncase of secure mode this can trigger a WARN in setup_crypto() and later\nlead to a NULL pointer dereference inside of prepare_auth_signature().", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-22992" }, { "cve":"CVE-2026-23060", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec\n\nauthencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than\nthe minimum expected length, crypto_authenc_esn_decrypt() can advance past\nthe end of the destination scatterlist and trigger a NULL pointer dereference\nin scatterwalk_map_and_copy(), leading to a kernel panic (DoS).\n\nAdd a minimum AAD length check to fail fast on invalid inputs.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23060" }, { "cve":"CVE-2026-23069", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: fix potential underflow in virtio_transport_get_credit()\n\nThe credit calculation in virtio_transport_get_credit() uses unsigned\narithmetic:\n\n ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt);\n\nIf the peer shrinks its advertised buffer (peer_buf_alloc) while bytes\nare in flight, the subtraction can underflow and produce a large\npositive value, potentially allowing more data to be queued than the\npeer can handle.\n\nReuse virtio_transport_has_space() which already handles this case and\nadd a comment to make it clear why we are doing that.\n\n[Stefano: use virtio_transport_has_space() instead of duplicating the code]\n[Stefano: tweak the commit message]", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23069" }, { "cve":"CVE-2026-23071", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nregmap: Fix race condition in hwspinlock irqsave routine\n\nPreviously, the address of the shared member '&map->spinlock_flags' was\npassed directly to 'hwspin_lock_timeout_irqsave'. This creates a race\ncondition where multiple contexts contending for the lock could overwrite\nthe shared flags variable, potentially corrupting the state for the\ncurrent lock owner.\n\nFix this by using a local stack variable 'flags' to store the IRQ state\ntemporarily.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":4.7, "vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23071" }, { "cve":"CVE-2026-23086", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: cap TX credit to local buffer size\n\nThe virtio transports derives its TX credit directly from peer_buf_alloc,\nwhich is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value.\n\nOn the host side this means that the amount of data we are willing to\nqueue for a connection is scaled by a guest-chosen buffer size, rather\nthan the host's own vsock configuration. A malicious guest can advertise\na large buffer and read slowly, causing the host to allocate a\ncorrespondingly large amount of sk_buff memory.\nThe same thing would happen in the guest with a malicious host, since\nvirtio transports share the same code base.\n\nIntroduce a small helper, virtio_transport_tx_buf_size(), that\nreturns min(peer_buf_alloc, buf_alloc), and use it wherever we consume\npeer_buf_alloc.\n\nThis ensures the effective TX window is bounded by both the peer's\nadvertised buffer and our own buf_alloc (already clamped to\nbuffer_max_size via SO_VM_SOCKETS_BUFFER_MAX_SIZE), so a remote peer\ncannot force the other to queue more data than allowed by its own\nvsock settings.\n\nOn an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with\n32 guest vsock connections advertising 2 GiB each and reading slowly\ndrove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only\nrecovered after killing the QEMU process. That said, if QEMU memory is\nlimited with cgroups, the maximum memory used will be limited.\n\nWith this patch applied:\n\n Before:\n MemFree: ~61.6 GiB\n Slab: ~142 MiB\n SUnreclaim: ~117 MiB\n\n After 32 high-credit connections:\n MemFree: ~61.5 GiB\n Slab: ~178 MiB\n SUnreclaim: ~152 MiB\n\nOnly ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest\nremains responsive.\n\nCompatibility with non-virtio transports:\n\n - VMCI uses the AF_VSOCK buffer knobs to size its queue pairs per\n socket based on the local vsk->buffer_* values; the remote side\n cannot enlarge those queues beyond what the local endpoint\n configured.\n\n - Hyper-V's vsock transport uses fixed-size VMBus ring buffers and\n an MTU bound; there is no peer-controlled credit field comparable\n to peer_buf_alloc, and the remote endpoint cannot drive in-flight\n kernel memory above those ring sizes.\n\n - The loopback path reuses virtio_transport_common.c, so it\n naturally follows the same semantics as the virtio transport.\n\nThis change is limited to virtio_transport_common.c and thus affects\nvirtio-vsock, vhost-vsock, and loopback, bringing them in line with the\n\"remote window intersected with local policy\" behaviour that VMCI and\nHyper-V already effectively have.\n\n[Stefano: small adjustments after changing the previous patch]\n[Stefano: tweak the commit message]", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23086" }, { "cve":"CVE-2026-23099", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: limit BOND_MODE_8023AD to Ethernet devices\n\nBOND_MODE_8023AD makes sense for ARPHRD_ETHER only.\n\nsyzbot reported:\n\n BUG: KASAN: global-out-of-bounds in __hw_addr_create net/core/dev_addr_lists.c:63 [inline]\n BUG: KASAN: global-out-of-bounds in __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118\nRead of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497\n\nCPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full)\nTainted: [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nCall Trace:\n \n dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n check_region_inline mm/kasan/generic.c:-1 [inline]\n kasan_check_range+0x2b0/0x2c0 mm/kasan/generic.c:200\n __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105\n __hw_addr_create net/core/dev_addr_lists.c:63 [inline]\n __hw_addr_add_ex+0x25d/0x760 net/core/dev_addr_lists.c:118\n __dev_mc_add net/core/dev_addr_lists.c:868 [inline]\n dev_mc_add+0xa1/0x120 net/core/dev_addr_lists.c:886\n bond_enslave+0x2b8b/0x3ac0 drivers/net/bonding/bond_main.c:2180\n do_set_master+0x533/0x6d0 net/core/rtnetlink.c:2963\n do_setlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165\n rtnl_changelink net/core/rtnetlink.c:3776 [inline]\n __rtnl_newlink net/core/rtnetlink.c:3935 [inline]\n rtnl_newlink+0x161c/0x1c90 net/core/rtnetlink.c:4072\n rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6958\n netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2550\n netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]\n netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344\n netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:742\n ____sys_sendmsg+0x505/0x820 net/socket.c:2592\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646\n __sys_sendmsg+0x164/0x220 net/socket.c:2678\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0x1dc/0x560 arch/x86/entry/syscall_32.c:307\n do_fast_syscall_32+0x34/0x80 arch/x86/entry/syscall_32.c:332\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n \n\nThe buggy address belongs to the variable:\n lacpdu_mcast_addr+0x0/0x40", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.1, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2026-23099" }, { "cve":"CVE-2026-23103", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nipvlan: Make the addrs_lock be per port\n\nMake the addrs_lock be per port, not per ipvlan dev.\n\nInitial code seems to be written in the assumption,\nthat any address change must occur under RTNL.\nBut it is not so for the case of IPv6. So\n\n1) Introduce per-port addrs_lock.\n\n2) It was needed to fix places where it was forgotten\nto take lock (ipvlan_open/ipvlan_close)\n\nThis appears to be a very minor problem though.\nSince it's highly unlikely that ipvlan_add_addr() will\nbe called on 2 CPU simultaneously. But nevertheless,\nthis could cause:\n\n1) False-negative of ipvlan_addr_busy(): one interface\niterated through all port->ipvlans + ipvlan->addrs\nunder some ipvlan spinlock, and another added IP\nunder its own lock. Though this is only possible\nfor IPv6, since looks like only ipvlan_addr6_event() can be\ncalled without rtnl_lock.\n\n2) Race since ipvlan_ht_addr_add(port) is called under\ndifferent ipvlan->addrs_lock locks\n\nThis should not affect performance, since add/remove IP\nis a rare situation and spinlock is not taken on fast\npaths.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23103" }, { "cve":"CVE-2026-23105", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag\n\nThis is more of a preventive patch to make the code more consistent and\nto prevent possible exploits that employ child qlen manipulations on qfq.\nuse cl_is_active instead of relying on the child qdisc's qlen to determine\nclass activation.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23105" }, { "cve":"CVE-2026-23111", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()\n\nnft_map_catchall_activate() has an inverted element activity check\ncompared to its non-catchall counterpart nft_mapelem_activate() and\ncompared to what is logically required.\n\nnft_map_catchall_activate() is called from the abort path to re-activate\ncatchall map elements that were deactivated during a failed transaction.\nIt should skip elements that are already active (they don't need\nre-activation) and process elements that are inactive (they need to be\nrestored). Instead, the current code does the opposite: it skips inactive\nelements and processes active ones.\n\nCompare the non-catchall activate callback, which is correct:\n\n nft_mapelem_activate():\n if (nft_set_elem_active(ext, iter->genmask))\n return 0; /* skip active, process inactive */\n\nWith the buggy catchall version:\n\n nft_map_catchall_activate():\n if (!nft_set_elem_active(ext, genmask))\n continue; /* skip inactive, process active */\n\nThe consequence is that when a DELSET operation is aborted,\nnft_setelem_data_activate() is never called for the catchall element.\nFor NFT_GOTO verdict elements, this means nft_data_hold() is never\ncalled to restore the chain->use reference count. Each abort cycle\npermanently decrements chain->use. Once chain->use reaches zero,\nDELCHAIN succeeds and frees the chain while catchall verdict elements\nstill reference it, resulting in a use-after-free.\n\nThis is exploitable for local privilege escalation from an unprivileged\nuser via user namespaces + nftables on distributions that enable\nCONFIG_USER_NS and CONFIG_NF_TABLES.\n\nFix by removing the negation so the check matches nft_mapelem_activate():\nskip active elements, process inactive ones.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.8, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2026-23111" }, { "cve":"CVE-2026-23120", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nl2tp: avoid one data-race in l2tp_tunnel_del_work()\n\nWe should read sk->sk_socket only when dealing with kernel sockets.\n\nsyzbot reported the following data-race:\n\nBUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release\n\nwrite to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0:\n sk_set_socket include/net/sock.h:2092 [inline]\n sock_orphan include/net/sock.h:2118 [inline]\n sk_common_release+0xae/0x230 net/core/sock.c:4003\n udp_lib_close+0x15/0x20 include/net/udp.h:325\n inet_release+0xce/0xf0 net/ipv4/af_inet.c:437\n __sock_release net/socket.c:662 [inline]\n sock_close+0x6b/0x150 net/socket.c:1455\n __fput+0x29b/0x650 fs/file_table.c:468\n ____fput+0x1c/0x30 fs/file_table.c:496\n task_work_run+0x131/0x1a0 kernel/task_work.c:233\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]\n exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75\n __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]\n syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]\n do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nread to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1:\n l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418\n process_one_work kernel/workqueue.c:3257 [inline]\n process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340\n worker_thread+0x582/0x770 kernel/workqueue.c:3421\n kthread+0x489/0x510 kernel/kthread.c:463\n ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n\nvalue changed: 0xffff88811b818000 -> 0x0000000000000000", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23120" }, { "cve":"CVE-2026-23124", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: annotate data-race in ndisc_router_discovery()\n\nsyzbot found that ndisc_router_discovery() could read and write\nin6_dev->ra_mtu without holding a lock [1]\n\nThis looks fine, IFLA_INET6_RA_MTU is best effort.\n\nAdd READ_ONCE()/WRITE_ONCE() to document the race.\n\nNote that we might also reject illegal MTU values\n(mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) in a future patch.\n\n[1]\nBUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery\n\nread to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1:\n ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558\n ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841\n icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989\n ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438\n ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489\n NF_HOOK include/linux/netfilter.h:318 [inline]\n ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500\n ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590\n dst_input include/net/dst.h:474 [inline]\n ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79\n...\n\nwrite to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0:\n ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559\n ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841\n icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989\n ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438\n ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489\n NF_HOOK include/linux/netfilter.h:318 [inline]\n ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500\n ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590\n dst_input include/net/dst.h:474 [inline]\n ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79\n...\n\nvalue changed: 0x00000000 -> 0xe5400659", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23124" }, { "cve":"CVE-2026-23126", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetdevsim: fix a race issue related to the operation on bpf_bound_progs list\n\nThe netdevsim driver lacks a protection mechanism for operations on the\nbpf_bound_progs list. When the nsim_bpf_create_prog() performs\nlist_add_tail, it is possible that nsim_bpf_destroy_prog() is\nsimultaneously performs list_del. Concurrent operations on the list may\nlead to list corruption and trigger a kernel crash as follows:\n\n[ 417.290971] kernel BUG at lib/list_debug.c:62!\n[ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1\n[ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[ 417.291007] Workqueue: events bpf_prog_free_deferred\n[ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0\n[ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8\n[ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246\n[ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000\n[ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180\n[ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003\n[ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20\n[ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000\n[ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000\n[ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0\n[ 417.291088] PKRU: 55555554\n[ 417.291091] Call Trace:\n[ 417.291096] \n[ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim]\n[ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80\n[ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0\n[ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0\n[ 417.291178] process_one_work+0x18a/0x3a0\n[ 417.291188] worker_thread+0x27b/0x3a0\n[ 417.291197] ? __pfx_worker_thread+0x10/0x10\n[ 417.291207] kthread+0xe5/0x120\n[ 417.291214] ? __pfx_kthread+0x10/0x10\n[ 417.291221] ret_from_fork+0x31/0x50\n[ 417.291230] ? __pfx_kthread+0x10/0x10\n[ 417.291236] ret_from_fork_asm+0x1a/0x30\n[ 417.291246] \n\nAdd a mutex lock, to prevent simultaneous addition and deletion operations\non the list.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":4.7, "vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23126" }, { "cve":"CVE-2026-23133", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: fix dma_free_coherent() pointer\n\ndma_alloc_coherent() allocates a DMA mapped buffer and stores the\naddresses in XXX_unaligned fields. Those should be reused when freeing\nthe buffer rather than the aligned addresses.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23133" }, { "cve":"CVE-2026-23136", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: reset sparse-read state in osd_fault()\n\nWhen a fault occurs, the connection is abandoned, reestablished, and any\npending operations are retried. The OSD client tracks the progress of a\nsparse-read reply using a separate state machine, largely independent of\nthe messenger's state.\n\nIf a connection is lost mid-payload or the sparse-read state machine\nreturns an error, the sparse-read state is not reset. The OSD client\nwill then interpret the beginning of a new reply as the continuation of\nthe old one. If this makes the sparse-read machinery enter a failure\nstate, it may never recover, producing loops like:\n\n libceph: [0] got 0 extents\n libceph: data len 142248331 != extent len 0\n libceph: osd0 (1)...:6801 socket error on read\n libceph: data len 142248331 != extent len 0\n libceph: osd0 (1)...:6801 socket error on read\n\nTherefore, reset the sparse-read state in osd_fault(), ensuring retries\nstart from a clean state.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23136" }, { "cve":"CVE-2026-23137", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nof: unittest: Fix memory leak in unittest_data_add()\n\nIn unittest_data_add(), if of_resolve_phandles() fails, the allocated\nunittest_data is not freed, leading to a memory leak.\n\nFix this by using scope-based cleanup helper __free(kfree) for automatic\nresource cleanup. This ensures unittest_data is automatically freed when\nit goes out of scope in error paths.\n\nFor the success path, use retain_and_null_ptr() to transfer ownership\nof the memory to the device tree and prevent double freeing.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23137" }, { "cve":"CVE-2026-23139", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conncount: update last_gc only when GC has been performed\n\nCurrently last_gc is being updated everytime a new connection is\ntracked, that means that it is updated even if a GC wasn't performed.\nWith a sufficiently high packet rate, it is possible to always bypass\nthe GC, causing the list to grow infinitely.\n\nUpdate the last_gc value only when a GC has been actually performed.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23139" }, { "cve":"CVE-2026-23145", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix iloc.bh leak in ext4_xattr_inode_update_ref\n\nThe error branch for ext4_xattr_inode_update_ref forget to release the\nrefcount for iloc.bh. Find this when review code.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23145" }, { "cve":"CVE-2026-23154", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix segmentation of forwarding fraglist GRO\n\nThis patch enhances GSO segment handling by properly checking\nthe SKB_GSO_DODGY flag for frag_list GSO packets, addressing\nlow throughput issues observed when a station accesses IPv4\nservers via hotspots with an IPv6-only upstream interface.\n\nSpecifically, it fixes a bug in GSO segmentation when forwarding\nGRO packets containing a frag_list. The function skb_segment_list\ncannot correctly process GRO skbs that have been converted by XLAT,\nsince XLAT only translates the header of the head skb. Consequently,\nskbs in the frag_list may remain untranslated, resulting in protocol\ninconsistencies and reduced throughput.\n\nTo address this, the patch explicitly sets the SKB_GSO_DODGY flag\nfor GSO packets in XLAT's IPv4/IPv6 protocol translation helpers\n(bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4). This marks GSO\npackets as potentially modified after protocol translation. As a\nresult, GSO segmentation will avoid using skb_segment_list and\ninstead falls back to skb_segment for packets with the SKB_GSO_DODGY\nflag. This ensures that only safe and fully translated frag_list\npackets are processed by skb_segment_list, resolving protocol\ninconsistencies and improving throughput when forwarding GRO packets\nconverted by XLAT.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23154" }, { "cve":"CVE-2026-23156", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nefivarfs: fix error propagation in efivar_entry_get()\n\nefivar_entry_get() always returns success even if the underlying\n__efivar_entry_get() fails, masking errors.\n\nThis may result in uninitialized heap memory being copied to userspace\nin the efivarfs_file_read() path.\n\nFix it by returning the error from __efivar_entry_get().", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.8, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2026-23156" }, { "cve":"CVE-2026-23169", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix race in mptcp_pm_nl_flush_addrs_doit()\n\nsyzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id()\nand/or mptcp_pm_nl_is_backup()\n\nRoot cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit()\nwhich is not RCU ready.\n\nlist_splice_init_rcu() can not be called here while holding pernet->lock\nspinlock.\n\nMany thanks to Eulgyu Kim for providing a repro and testing our patches.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":4.7, "vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23169" }, { "cve":"CVE-2026-23173", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: TC, delete flows only for existing peers\n\nWhen deleting TC steering flows, iterate only over actual devcom\npeers instead of assuming all possible ports exist. This avoids\ntouching non-existent peers and ensures cleanup is limited to\ndevices the driver is currently connected to.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 133c8a067 P4D 0\n Oops: Oops: 0002 [#1] SMP\n CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core]\n Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49\n RSP: 0018:ff11000143867528 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000\n RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0\n RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002\n R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78\n R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0\n FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0\n Call Trace:\n \n mlx5e_tc_del_flow+0x46/0x270 [mlx5_core]\n mlx5e_flow_put+0x25/0x50 [mlx5_core]\n mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core]\n tc_setup_cb_reoffload+0x20/0x80\n fl_reoffload+0x26f/0x2f0 [cls_flower]\n ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]\n ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]\n tcf_block_playback_offloads+0x9e/0x1c0\n tcf_block_unbind+0x7b/0xd0\n tcf_block_setup+0x186/0x1d0\n tcf_block_offload_cmd.isra.0+0xef/0x130\n tcf_block_offload_unbind+0x43/0x70\n __tcf_block_put+0x85/0x160\n ingress_destroy+0x32/0x110 [sch_ingress]\n __qdisc_destroy+0x44/0x100\n qdisc_graft+0x22b/0x610\n tc_get_qdisc+0x183/0x4d0\n rtnetlink_rcv_msg+0x2d7/0x3d0\n ? rtnl_calcit.isra.0+0x100/0x100\n netlink_rcv_skb+0x53/0x100\n netlink_unicast+0x249/0x320\n ? __alloc_skb+0x102/0x1f0\n netlink_sendmsg+0x1e3/0x420\n __sock_sendmsg+0x38/0x60\n ____sys_sendmsg+0x1ef/0x230\n ? copy_msghdr_from_user+0x6c/0xa0\n ___sys_sendmsg+0x7f/0xc0\n ? ___sys_recvmsg+0x8a/0xc0\n ? __sys_sendto+0x119/0x180\n __sys_sendmsg+0x61/0xb0\n do_syscall_64+0x55/0x640\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7f35238bb764\n Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55\n RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764\n RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003\n RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20\n R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790\n R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23173" }, { "cve":"CVE-2026-23191", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: aloop: Fix racy access at PCM trigger\n\nThe PCM trigger callback of aloop driver tries to check the PCM state\nand stop the stream of the tied substream in the corresponding cable.\nSince both check and stop operations are performed outside the cable\nlock, this may result in UAF when a program attempts to trigger\nfrequently while opening/closing the tied stream, as spotted by\nfuzzers.\n\nFor addressing the UAF, this patch changes two things:\n- It covers the most of code in loopback_check_format() with\n cable->lock spinlock, and add the proper NULL checks. This avoids\n already some racy accesses.\n- In addition, now we try to check the state of the capture PCM stream\n that may be stopped in this function, which was the major pain point\n leading to UAF.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.0, "vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2026-23191" }, { "cve":"CVE-2026-23198", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Don't clobber irqfd routing type when deassigning irqfd\n\nWhen deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's\nrouting entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86\nand arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to\nhandle a concurrent routing update, verify that the irqfd is still active\nbefore consuming the routing information. As evidenced by the x86 and\narm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),\nclobbering the entry type without notifying arch code is surprising and\nerror prone.\n\nAs a bonus, checking that the irqfd is active provides a convenient\nlocation for documenting _why_ KVM must not consume the routing entry for\nan irqfd that is in the process of being deassigned: once the irqfd is\ndeleted from the list (which happens *before* the eventfd is detached), it\nwill no longer receive updates via kvm_irq_routing_update(), and so KVM\ncould deliver an event using stale routing information (relative to\nKVM_SET_GSI_ROUTING returning to userspace).\n\nAs an even better bonus, explicitly checking for the irqfd being active\nfixes a similar bug to the one the clobbering is trying to prevent: if an\nirqfd is deactivated, and then its routing is changed,\nkvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing()\n(because the irqfd isn't in the list). And so if the irqfd is in bypass\nmode, IRQs will continue to be posted using the old routing information.\n\nAs for kvm_arch_irq_bypass_del_producer(), clobbering the routing type\nresults in KVM incorrectly keeping the IRQ in bypass mode, which is\nespecially problematic on AMD as KVM tracks IRQs that are being posted to\na vCPU in a list whose lifetime is tied to the irqfd.\n\nWithout the help of KASAN to detect use-after-free, the most common\nsympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to\nthe memory for irqfd structure being re-allocated and zeroed, resulting\nin irqfd->irq_bypass_data being NULL when read by\navic_update_iommu_vcpu_affinity():\n\n BUG: kernel NULL pointer dereference, address: 0000000000000018\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test\n Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE\n Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025\n RIP: 0010:amd_iommu_update_ga+0x19/0xe0\n Call Trace:\n \n avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd]\n __avic_vcpu_load+0xf4/0x130 [kvm_amd]\n kvm_arch_vcpu_load+0x89/0x210 [kvm]\n vcpu_load+0x30/0x40 [kvm]\n kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm]\n kvm_vcpu_ioctl+0x571/0x6a0 [kvm]\n __se_sys_ioctl+0x6d/0xb0\n do_syscall_64+0x6f/0x9d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x46893b\n \n ---[ end trace 0000000000000000 ]---\n\nIf AVIC is inhibited when the irfd is deassigned, the bug will manifest as\nlist corruption, e.g. on the next irqfd assignment.\n\n list_add corruption. next->prev should be prev (ffff8d474d5cd588),\n but was 0000000000000000. (next=ffff8d8658f86530).\n ------------[ cut here ]------------\n kernel BUG at lib/list_debug.c:31!\n Oops: invalid opcode: 0000 [#1] SMP\n CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test\n Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE\n Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025\n RIP: 0010:__list_add_valid_or_report+0x97/0xc0\n Call Trace:\n \n avic_pi_update_irte+0x28e/0x2b0 [kvm_amd]\n kvm_pi_update_irte+0xbf/0x190 [kvm]\n kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm]\n irq_bypass_register_consumer+0xcd/0x170 [irqbypa\n---truncated---", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23198" }, { "cve":"CVE-2026-23204", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_u32: use skb_header_pointer_careful()\n\nskb_header_pointer() does not fully validate negative @offset values.\n\nUse skb_header_pointer_careful() instead.\n\nGangMin Kim provided a report and a repro fooling u32_classify():\n\nBUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0\nnet/sched/cls_u32.c:221", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.1, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2026-23204" }, { "cve":"CVE-2026-23208", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Prevent excessive number of frames\n\nIn this case, the user constructed the parameters with maxpacksize 40\nfor rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer\nsize for each data URB is maxpacksize * packets, which in this example\nis 40 * 6 = 240; When the user performs a write operation to send audio\ndata into the ALSA PCM playback stream, the calculated number of frames\nis packsize[0] * packets = 264, which exceeds the allocated URB buffer\nsize, triggering the out-of-bounds (OOB) issue reported by syzbot [1].\n\nAdded a check for the number of single data URB frames when calculating\nthe number of frames to prevent [1].\n\n[1]\nBUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487\nWrite of size 264 at addr ffff88804337e800 by task syz.0.17/5506\nCall Trace:\n copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487\n prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611\n prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.8, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2026-23208" }, { "cve":"CVE-2026-23212", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: annotate data-races around slave->last_rx\n\nslave->last_rx and slave->target_last_arp_rx[...] can be read and written\nlocklessly. Add READ_ONCE() and WRITE_ONCE() annotations.\n\nsyzbot reported:\n\nBUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validate\n\nwrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1:\n bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335\n bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533\n __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039\n __netif_receive_skb_one_core net/core/dev.c:6150 [inline]\n __netif_receive_skb+0x59/0x270 net/core/dev.c:6265\n netif_receive_skb_internal net/core/dev.c:6351 [inline]\n netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410\n...\n\nwrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0:\n bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335\n bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533\n __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039\n __netif_receive_skb_one_core net/core/dev.c:6150 [inline]\n __netif_receive_skb+0x59/0x270 net/core/dev.c:6265\n netif_receive_skb_internal net/core/dev.c:6351 [inline]\n netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410\n br_netif_receive_skb net/bridge/br_input.c:30 [inline]\n NF_HOOK include/linux/netfilter.h:318 [inline]\n...\n\nvalue changed: 0x0000000100005365 -> 0x0000000100005366", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":4.7, "vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23212" }, { "cve":"CVE-2026-23221", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: fix use-after-free in driver_override_show()\n\nThe driver_override_show() function reads the driver_override string\nwithout holding the device_lock. However, driver_override_store() uses\ndriver_set_override(), which modifies and frees the string while holding\nthe device_lock.\n\nThis can result in a concurrent use-after-free if the string is freed\nby the store function while being read by the show function.\n\nFix this by holding the device_lock around the read operation.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"HIGH", "baseScore":7.8, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"High", "category":"impact" } ], "title":"CVE-2026-23221" }, { "cve":"CVE-2026-23230", "notes":[ { "text":"In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: split cached_fid bitfields to avoid shared-byte RMW races\n\nis_open, has_lease and on_list are stored in the same bitfield byte in\nstruct cached_fid but are updated in different code paths that may run\nconcurrently. Bitfield assignments generate byte read–modify–write\noperations (e.g. `orb $mask, addr` on x86_64), so updating one flag can\nrestore stale values of the others.\n\nA possible interleaving is:\n CPU1: load old byte (has_lease=1, on_list=1)\n CPU2: clear both flags (store 0)\n CPU1: RMW store (old | IS_OPEN) -> reintroduces cleared bits\n\nTo avoid this class of races, convert these flags to separate bool\nfields.", "category":"description", "title":"Vulnerability Description" } ], "product_status":{ "fixed":{"$ref":"$.vulnerabilities[0].product_status.fixed"} }, "remediations":[ { "product_ids":{"$ref":"$.vulnerabilities[0].product_status.fixed"}, "details":"kernel security update", "category":"vendor_fix", "url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1833" } ], "scores":[ { "cvss_v3":{ "baseSeverity":"MEDIUM", "baseScore":5.5, "vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version":"3.1" }, "products":{"$ref":"$.vulnerabilities[0].product_status.fixed"} } ], "threats":[ { "details":"Medium", "category":"impact" } ], "title":"CVE-2026-23230" } ] }