{"id":"OESA-2026-3705","summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison\n\nThe local-vs-remote region comparison loop uses '<=' instead of '<',\ncausing it to read one entry past the valid range of qr_regions.  The\nother loops in the same function correctly use '<'.\n\nFix the loop condition to use '<' for consistency and correctness.(CVE-2026-53309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nixgbevf: fix use-after-free in VEPA multicast source pruning\n\nixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's\nown address (VEPA multicast workaround) by freeing the skb and\ncontinuing to the next descriptor:\n\n    dev_kfree_skb_irq(skb);\n    continue;\n\nThe skb pointer is declared outside the while loop and persists across\niterations.  Because the continue skips the "skb = NULL" reset at the\nbottom of the loop, the next iteration enters the "else if (skb)" path\nand calls ixgbevf_add_rx_frag() on the freed skb, dereferencing\nskb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context.\n\nThe sibling driver iavf already handles this correctly by nulling the\npointer before continuing.  Apply the same pattern here.\n\nI do not have ixgbevf hardware; the bug was found by static analysis\n(scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool\ncorroboration with the highest score in the scan).  The UAF was confirmed\nunder KASAN by loading a test module that reproduces the exact code\npattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags):\n\n  BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000\n  Read of size 8 at addr 000000006163ae78 by task insmod/30\n  freed 208-byte region [000000006163adc0, 000000006163ae90)\n\nQEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF\ndriver does not include the VEPA source pruning path, so a full\nend-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate STALE_COOKIE cause length before reading staleness\n\nWhen an ERROR chunk with a STALE_COOKIE cause is received in the\nCOOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure\nof Staleness that follows the cause header:\n\n\terr   = (struct sctp_errhdr *)(chunk->skb->data);\n\tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));\n\nerr is the first cause in the chunk, not the STALE_COOKIE cause that\ncaused the dispatch, and nothing guarantees the staleness field is\npresent. sctp_walk_errors() only requires a cause to be as long as the\n4-byte header, so for a STALE_COOKIE cause of length 4 the read runs\npast the cause, and for a minimal ERROR chunk past skb->tail. The value\nis echoed to the peer in the Cookie Preservative of the reply INIT,\nleaking uninitialized memory.\n\nsctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so\ncheck its length there and pass it to sctp_sf_do_5_2_6_stale(), which\nreads that cause instead of the first one. A STALE_COOKIE cause too\nshort to hold the staleness field is discarded.\n\nThe read is reachable by any peer that can drive an association into\nCOOKIE_ECHOED, including an unprivileged process using a raw SCTP socket\nin a user and network namespace.(CVE-2026-64551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix two unsafe bare decodes in decode_lockers()\n\ndecode_lockers() in cls_lock_client.c contains two bare decode operations\nthat allow a malicious or compromised OSD to trigger slab-out-of-bounds\nreads:\n\n1. ceph_decode_32(p) at the num_lockers field has no preceding bounds\n   check. ceph_start_decoding() accepts struct_len=0 as valid -- the\n   internal ceph_decode_need(p, end, 0, bad) always passes -- so when an\n   OSD sends struct_len=0, ceph_start_decoding() returns success with\n   p == end. The immediately following bare ceph_decode_32(p) then reads\n   4 bytes past the validated buffer boundary. The garbage value is\n   passed directly to kzalloc_objs() as the locker count.\n\n   The sibling function decode_watchers() in osd_client.c already uses\n   ceph_decode_32_safe() after its own ceph_start_decoding() call.\n   decode_lockers() was the only site using the bare variant.\n\n2. ceph_decode_8(p) after the decode_locker() loop has no preceding\n   bounds check. If an OSD crafts num_lockers such that the loop\n   advances p exactly to end, the subsequent bare ceph_decode_8(p) reads\n   one byte past the validated buffer boundary. The result is passed\n   directly into *type, which is used as a lock type discriminator by\n   callers, giving an OSD-controlled one-byte OOB read with direct\n   influence over the lock type field.\n\nFix both by replacing bare operations with their safe variants:\n  ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers,\n                                           err_inval)\n  ceph_decode_8(p)  -> ceph_decode_8_safe(p, end, *type,\n                                          err_free_lockers)\n\nThe goto targets differ intentionally:\n  err_inval: is a new label returning -EINVAL directly. It is used for\n  the pre-allocation failure path where *lockers is not yet allocated\n  and must not be passed to ceph_free_lockers().\n\n  err_free_lockers: is the existing label. It is used for the\n  post-allocation failure path where *lockers is allocated and must\n  be freed.\n\nret is set to -EINVAL before ceph_decode_8_safe() so that\nerr_free_lockers returns the correct error code on bounds violation.\nWithout this, err_free_lockers would return a stale ret value (0 from\nthe successful decode_locker() loop), silently swallowing the error.\n\n-EINVAL is correct for both failure paths. The data received from the\nOSD is structurally malformed. -ENOMEM would misrepresent the failure\nclass to callers and to stable@ backporters triaging error paths.\n\nAttacker model: a malicious or compromised OSD in a multi-tenant Ceph\ndeployment can trigger this against any kernel client that issues the\nlock.get_info class method (e.g. during RBD exclusive lock acquisition).\n\n[ idryomov: trim changelog, formatting ](CVE-2026-68082)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: Fix possible use after free\n\nIn dma_release_channel(), check chan->device->privatecnt after call\ndma_chan_put(). However, dma_chan_put() call dma_device_put() which could\nrelease the last reference of the device if the DMA provider is already\ngone and hence free it.\n\nFixes it by moving dma_chan_put() after the check.(CVE-2026-72476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Release the HW‑provided UAR index rather than the SW one\n\nFree the UAR index returned by the hardware.(CVE-2026-74296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix undefined shift of user RQ WQE size\n\nset_rq_size() computes the RQ WQE size as "1 << rq_wqe_shift" based on\nthe user-provided rq_wqe_shift, which is only checked to be greater than\n32, so shifts of 32 are still accepted. A shift of 31 also overflows a\nsigned integer, leading to undefined behavior.\n\nUse check_shl_overflow() to compute the RQ WQE size and reject any\ninvalid values.(CVE-2026-74297)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost/net: complete zerocopy ubufs only once\n\nvhost-net initializes one ubuf_info per outstanding zerocopy TX\ndescriptor and hands it to the backend socket.  The networking stack may\nthen clone a zerocopy skb before all skb references are released.  For\nexample, batman-adv fragmentation reaches skb_split(), which calls\nskb_zerocopy_clone() and increments the same ubuf_info refcount.\n\nvhost_zerocopy_complete() currently treats every ubuf callback as a\ncompleted vhost descriptor.  It dereferences ubuf->ctx, writes the\ndescriptor completion state, and drops the vhost_net_ubuf_ref even when\nthe callback only releases a cloned skb reference.  A backend reset can\ntherefore wait for and free the vhost_net_ubuf_ref while another cloned\nskb still carries the same ubuf_info.  A later completion then\ndereferences the freed ubufs pointer.\n\nKASAN reports the stale completion as:\n\n  BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0\n  BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0\n  vhost_zerocopy_complete\n  skb_copy_ubufs\n  __dev_forward_skb2\n  veth_xmit\n\nThe freed object was allocated from vhost_net_ioctl() while setting the\nbackend and freed through kfree_rcu()/kvfree_rcu_bulk after backend\nremoval, while delayed skb completion still reached\nvhost_zerocopy_complete().\n\nHonor the generic ubuf_info refcount before touching vhost state, and run\nthe vhost descriptor completion only for the final ubuf reference.  This\nmatches the msg_zerocopy_complete() ownership rule for cloned zerocopy\nskbs.(CVE-2026-74310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Preserve pointer state for commuted arithmetic\n\nWhen scalar += pointer is handled in adjust_ptr_min_max_vals(), the\ndestination register inherits the pointer state from the source pointer.\nCopying only selected fields is fragile because pointer provenance is\ntracked by several bpf_reg_state fields.\n\nUse the caller's temporary offset register to preserve the scalar operand\nwhile replacing the destination with the full pointer state. This preserves\nthe frame number for PTR_TO_STACK registers and keeps parent identity\nfields consistent.(CVE-2026-74720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: Avoid using invalid osd indices from primary_temp\n\nA corrupted osdmap received from a Ceph monitor or OSD may contain osd\nindices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts\nthat don't exist, i.e., that are greater than max_osd or smaller than\nCEPH_HOMELESS_OSD (-1). These indices are used to create the up and\nacting set in ceph_pg_to_up_acting_osds(), called from calc_target().\nWhile most of these osd indices are checked, the one from primary_temp\nis not. Subsequently, this may lead to calc_target() returning this\n(potentially invalid) index as target osd for a (linger) request.\nBecause the osd_state, osd_weight, and osd_addr arrays only contain\nmax_osd entries (with indices 0 to max_osd -1), this leads to\nout-of-bounds accesses when trying to read values from these arrays.\n\nThis patch fixes the issue by adding a check to get_temp_osds(), so that\nonly valid osd indices from primary_temp are used, and it falls back to\nusing the primary from pg_temp or the up set if it is invalid.\n\n[ idryomov: changelog ](CVE-2026-80558)","modified":"2026-09-13T16:45:23.072091133Z","published":"2026-09-14T16:33:32Z","upstream":["CVE-2026-53309","CVE-2026-64113","CVE-2026-64551","CVE-2026-68082","CVE-2026-72476","CVE-2026-74296","CVE-2026-74297","CVE-2026-74310","CVE-2026-74720","CVE-2026-80558"],"database_specific":{"severity":"Critical"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3705"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53309"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64113"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64551"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68082"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72476"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74296"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74297"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74310"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74720"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-80558"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:20.03-LTS-SP4","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2609.1.0.0389.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","kernel-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","perf-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2609.1.0.0389.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","kernel-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","perf-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2026-3705.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}]}