{"schema_version":"1.7.2","id":"OESA-2026-3316","modified":"2026-08-13T13:56:47Z","published":"2026-08-13T13:56:47Z","upstream":["CVE-2026-53392","CVE-2026-53399","CVE-2026-64191","CVE-2026-64266","CVE-2026-64299","CVE-2026-64374","CVE-2026-64388","CVE-2026-64456"],"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\nNFSv4/flexfiles: reject zero filehandle version count\n\nff_layout_alloc_lseg() decodes the filehandle-version array count\nfrom the flexfiles layout body. The value is used as the count for\nkzalloc_objs(), and the current code only rejects NULL.\n\nA zero count yields ZERO_SIZE_PTR, which can be stored in\ndss_info->fh_versions even though later flexfiles paths assume that at\nleast one filehandle version exists.\n\nReject fh_count == 0 before the allocation, matching the existing zero\nversion_count validation in the flexfiles GETDEVICEINFO parser.\n\nA QEMU/KASAN run with a malformed flexfiles layout hit:\n\n  KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n  RIP: 0010:ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750\n  ff_layout_encode_layoutreturn+0x683/0x970\n  nfs4_xdr_enc_layoutreturn+0x278/0x3a0\n  Kernel panic - not syncing: Fatal exception\n\nThe patched kernel rejects the malformed layout without KASAN/oops/panic,\nand a valid fh_count=1 regression still opens, reads, and unmounts cleanly.(CVE-2026-53392)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: release layout stid on setlease failure\n\nnfs4_alloc_stid() publishes the new stid into cl->cl_stateids via\nidr_alloc_cyclic() under cl_lock before returning to\nnfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then\nfails, the error path frees the layout stateid directly with\nkmem_cache_free() without ever calling idr_remove(), leaving the\nIDR slot pointing at freed slab memory. Any subsequent IDR walker\n(states_show, client teardown) dereferences the dangling pointer.\n\nThe correct teardown for an IDR-published stid is nfs4_put_stid(),\nwhich removes the IDR slot under cl_lock, dispatches sc_free\n(nfsd4_free_layout_stateid) to release ls->ls_file via\nnfsd4_close_layout(), and drops the nfs4_file reference in its\ntail.\n\nA second issue blocks that switch: nfsd4_free_layout_stateid()\nunconditionally inspects ls->ls_fence_work via\ndelayed_work_pending() under ls_lock, but\nINIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only\nafter the setlease call. On the setlease-failure path the\ndestructor would touch an uninitialized delayed_work.\n\n    nfsd4_alloc_layout_stateid()\n      nfs4_alloc_stid()           /* idr_alloc_cyclic under cl_lock */\n      nfsd4_layout_setlease()     /* fails */\n        nfs4_put_stid()\n          nfsd4_free_layout_stateid()\n            delayed_work_pending(&ls->ls_fence_work)  /* needs INIT */\n            nfsd4_close_layout()  /* nfsd_file_put(ls->ls_file) */\n          put_nfs4_file()\n\nFix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK\ninitialization above the nfsd4_layout_setlease() call, and replace\nthe manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup\nwith a single nfs4_put_stid(stp).(CVE-2026-53399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: stub: Reject I2C block transfers with invalid length\n\nThe I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0]\nas the transfer length. The existing check only clamps it to avoid\noverrunning the chip->words[256] register array, but does not validate\nit against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union\ni2c_smbus_data.block buffer (34 bytes total). The driver is a\ndevelopment/test tool (CONFIG_I2C_STUB=m, not built by default)\nthat must be loaded with a chip_addr= parameter.\n\nA local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl\nwith I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing\nstub_xfer() to read or write past the end of the union\ni2c_smbus_data.block buffer:\n\n BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223)\n Read of size 1 at addr ffff88800abcfd92 by task exploit/81\n Call Trace:\n  <TASK>\n  stub_xfer (drivers/i2c/i2c-stub.c:223)\n  __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593)\n  i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536)\n  i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391)\n  i2cdev_ioctl (drivers/i2c/i2c-dev.c:478)\n  __x64_sys_ioctl (fs/ioctl.c:583)\n  do_syscall_64 (arch/x86/entry/syscall_64.c:94)\n  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n  </TASK>\n\nThe bug exists because i2c-stub implements .smbus_xfer directly,\nbypassing the I2C_SMBUS_BLOCK_MAX validation in\ni2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same\nfunction correctly validates against I2C_SMBUS_BLOCK_MAX, but the\nI2C_SMBUS_I2C_BLOCK_DATA case does not.\n\nFix by rejecting transfers with data->block[0] == 0 or\ndata->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with\nboth the I2C_SMBUS_BLOCK_DATA case in the same function and the\nI2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().(CVE-2026-64191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: re-lock request before returning from fuse_ref_folio()\n\nfuse_ref_folio() unlocks the request but does not re-lock it before\nreturning. fuse_chan_abort() can end the request and the async end\ncallback (eg fuse_writepage_free()) can free the args while the\nsubsequent copy chain logic after fuse_ref_folio() accesses them,\nleading to use-after-free issues.\n\nFix this by locking the request in fuse_ref_folio() before returning.(CVE-2026-64266)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Prevent out-of-bounds read in glob matching\n\nString event fields are not necessarily NUL-terminated, so the filter\npredicate functions (filter_pred_string(), filter_pred_strloc() and\nfilter_pred_strrelloc()) pass the field length to the regex match\ncallbacks, and the length-aware matchers honour it.\n\nregex_match_glob() was the exception: it ignored the length and called\nglob_match(), which scans the string until it hits a NUL byte. Some\nstring fields are not NUL-terminated. One example is the dynamic char\narray of the xfs_* namespace tracepoints, which is copied without a\ntrailing NUL. For such a field, glob matching reads past the end of\nthe event field, causing a KASAN slab-out-of-bounds read in\nglob_match(), reached via regex_match_glob() and filter_match_preds()\nfrom the xfs_lookup tracepoint.\n\nAdd a length-bounded glob_match_len() and use it from regex_match_glob()\nso glob matching always stops at the field boundary. The matching loop\nis factored into a shared helper so glob_match() keeps its behaviour.(CVE-2026-64299)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT\n\nRT migration is done aggressively. When a CPU schedules out a high\npriority RT task for a lower priority task, it will look to see if there's\nany RT tasks that are waiting to run on another CPU that is of higher\npriority than the task this CPU is about to run. If it finds one, it will\npull that task over to the CPU and allow it to run there instead.\n\nNormally, this pulling is done by looking at the RT overloaded mask (rto)\nwhich contains all the CPUs in the scheduler domain with RT tasks that are\nwaiting to run due to a higher priority RT task currently running on their\nCPU. The CPU that is about to schedule a lower priority task will grab the\nrq lock of the overloaded CPU and move the RT task from that CPU's runqueue\nto the local one and schedule the higher priority RT task.\n\nThis caused issues when a lot of CPUs would schedule a lower priority task\nat the same time. They would all try to grab the same runqueue lock of\nthe CPU with the overloaded RT tasks. Only the first CPU that got in will\nget that task. All the others would wait until they got the runqueue lock\nand see there's nothing to pull and do nothing. On systems with lots of\nCPUs, this caused a large latency (up to 500us) which is beyond what\nPREEMPT_RT is to allow.\n\nThe solution to that was to create an RT_PUSH_IPI logic. When any CPU\nwanted to pull a task, instead of grabbing the runqueue lock of the\noverloaded CPU, it would start by sending an IPI to the overloaded CPU,\nand that IPI handler would have the CPU with the waiting RT task do a push\ninstead. Then that handler would send an IPI to the next CPU with\noverloaded RT tasks, and so on. Note, after the first CPU starts this\nprocess, if another CPU wanted to do a pull, it would see that the process\nhas already begun and would only increment a counter to have the IPIs\ncontinue again.\n\nThe RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause\na new issue with non PREEMPT_RT. Namely, softirqs run in a threaded\ncontext on PREEMPT_RT but they can run in an interrupt context in non-RT.\n\nIf an IPI lands on a CPU that has just woken up multiple RT tasks and the\ncurrent CPU is running a non RT or a low priority RT task, instead of\ndoing a push, it would simply do a schedule on that CPU. But if a softirq\nwas also executing on this CPU, the schedule would need to wait until the\nsoftirq finished. Until then, the CPU would still be considered overloaded\nas there are RT tasks still waiting to run on it.\n\nA live lock occurred on a workload that was doing heavy networking traffic\non a large machine where the softirqs would run 500us out of 750us. And it\nwould also be waking up RT tasks, causing the RT pull logic to be\nconstantly executed.\n\nWhen a softirq triggered on a CPU with RT tasks queued but not running\nyet, and the other CPUs would see this CPU as being overloaded, they would\nsend an IPI over to it. The CPU would notice that the waiting RT tasks are\nof higher priority than the currently running task and simply schedule\nthat CPU instead. But because the softirq was executing, before it could\nschedule, it would receive another IPI to do the same. The amount of IPIs\nwould slow down the currently running softirq so much that before it could\nreturn back to task context, it would execute another softirq never\nallowing the CPU to schedule. This live locked that CPU.\n\nAs RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if\nPREEMPT_RT is not enabled.(CVE-2026-64374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb/client: fix chown/chgrp with SMB3 POSIX Extensions\n\nOwnership (chown) and group (chgrp) modifications were being ignored when\nmounting with SMB3 POSIX Extensions unless CIFS_MOUNT_CIFS_ACL or\nCIFS_MOUNT_MODE_FROM_SID were also explicitly set.\n\nFix this by checking for posix_extensions in cifs_setattr_nounix() when\nupdating UID and GID, ensuring that id_mode_to_cifs_acl() is called to map\nand set the ownership/group information on the server.(CVE-2026-64388)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwrng: virtio: clamp device-reported used.len at copy_data()\n\nrandom_recv_done() stores the device-reported used.len directly into\nvi->data_avail.  copy_data() then indexes vi->data[] using\nvi->data_idx (advanced by previous copy_data() calls) and issues a\nmemcpy() without re-validating either value against the posted\nbuffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32\nor 64).\n\nA malicious or buggy virtio-rng backend can set used.len beyond\nsizeof(vi->data), steering the memcpy() past the end of the inline\narray into adjacent kmalloc-1k slab bytes.  hwrng_fillfn() mixes\nthose bytes into the guest RNG, and guest root can also observe\nthem directly via /dev/hwrng.\n\nConcrete impact is inside the guest:\n\n - Memory-safety / hardening: any virtio-rng backend that\n   over-reports used.len causes the driver to read past vi->data\n   into unrelated slab contents.  hwrng_fillfn() is a kernel thread\n   that runs as soon as the device is probed; no guest userspace\n   interaction is required to first-trigger the OOB.\n\n - Cross-boundary leak (confidential-compute threat model): a\n   malicious hypervisor cooperating with a malicious or compromised\n   guest root userspace can use /dev/hwrng as a leak channel for\n   guest-kernel heap data.  The host sets a large used.len, guest\n   root reads /dev/hwrng, and the returned bytes contain guest\n   kernel slab contents that were adjacent to vi->data.  In\n   practice, confidential-compute guests (SEV-SNP, TDX) usually\n   disable virtio-rng entirely, so this path is narrow, but the\n   fix is still worth carrying because the underlying\n   memory-safety bug contaminates the guest RNG on any host.\n\nKASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend\nhas been patched to report used.len = 0x10000:\n\n  BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0\n  Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52\n  Call Trace:\n   __asan_memcpy+0x23/0x60\n   virtio_read+0x394/0x5d0\n   hwrng_fillfn+0xb2/0x470\n   kthread+0x2cc/0x3a0\n  Allocated by task 1:\n   probe_common+0xa5/0x660\n   virtio_dev_probe+0x549/0xbc0\n  The buggy address belongs to the object at ffff88800ae0b800\n   which belongs to the cache kmalloc-1k of size 1024\n  The buggy address is located 0 bytes to the right of\n   allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)\n\nSame class of bug as commit c04db81cd028 ("net/9p: Fix buffer\noverflow in USB transport layer"), which hardened\nusb9pfs_rx_complete() against unchecked device-reported length in\nthe USB 9p transport.\n\nWith the clamp at point of use and array_index_nospec() in place,\nthe same harness boots cleanly: copy_data() returns zero for the\nbogus report, the device-supplied bytes after data_idx are\ndiscarded, and the driver issues a fresh request.(CVE-2026-64456)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2608.3.0.0385.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","kernel-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","perf-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2608.3.0.0385.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2608.3.0.0385.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","kernel-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","perf-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2608.3.0.0385.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3316"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53392"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53399"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64191"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64266"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64299"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64374"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64388"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64456"}],"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}],"database_specific":{"severity":"Critical"}}