{"schema_version":"1.7.2","id":"OESA-2026-3529","modified":"2026-08-30T04:15:01Z","published":"2026-08-30T04:15:01Z","upstream":["CVE-2026-46021","CVE-2026-46033","CVE-2026-46121","CVE-2026-53073","CVE-2026-53148","CVE-2026-53167","CVE-2026-53168","CVE-2026-53195"],"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\nthermal: core: Fix thermal zone governor cleanup issues\n\nIf thermal_zone_device_register_with_trips() fails after adding\na thermal governor to the thermal zone being registered, the\ngovernor is not removed from it as appropriate which may lead to\na memory leak.\n\nIn turn, thermal_zone_device_unregister() calls thermal_set_governor()\nwithout acquiring the thermal zone lock beforehand which may race with\na governor update via sysfs and may lead to a use-after-free in that\ncase.\n\nAddress these issues by adding two thermal_set_governor() calls, one to\nthermal_release() to remove the governor from the given thermal zone,\nand one to the thermal zone registration error path to cover failures\npreceding the thermal zone device registration.(CVE-2026-46021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: authencesn - reject short ahash digests during instance creation\n\nauthencesn requires either a zero authsize or an authsize of at least\n4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of\nhigh-order sequence number data at the end of the authenticated data.\n\nWhile crypto_authenc_esn_setauthsize() already rejects explicit\nnon-zero authsizes in the range 1..3, crypto_authenc_esn_create()\nstill copied auth->digestsize into inst->alg.maxauthsize without\nvalidating it.  The AEAD core then initialized the tfm's default\nauthsize from that value.\n\nAs a result, selecting an ahash with digest size 1..3, such as\ncbcmac(cipher_null), exposed authencesn instances whose default\nauthsize was invalid even though setauthsize() would have rejected the\nsame value.  AF_ALG could then trigger the ESN tail handling with a\ntoo-short tag and hit an out-of-bounds access.\n\nReject authencesn instances whose ahash digest size is in the invalid\nnon-zero range 1..3 so that no tfm can inherit an unsupported default\nauthsize.(CVE-2026-46033)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock\n\nPatch series "mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path".\n\nReads of 'memcg_path' and 'path' files in DAMON sysfs interface could race\nwith their writes, results in use-after-free.  Fix those.\n\n\nThis patch (of 2):\n\ndamon_sysfs_scheme_filter->mmecg_path can be read and written by users,\nvia DAMON sysfs memcg_path file.  It can also be indirectly read, for the\nparameters {on,off}line committing to DAMON.  The reads for parameters\ncommitting are protected by damon_sysfs_lock to avoid the sysfs files\nbeing destroyed while any of the parameters are being read.  But the\nuser-driven direct reads and writes are not protected by any lock, while\nthe write is deallocating the memcg_path-pointing buffer.  As a result,\nthe readers could read the already freed buffer (user-after-free).  Note\nthat the user-reads don't race when the same open file is used by the\nwriter, due to kernfs's open file locking.  Nonetheless, doing the reads\nand writes with separate open files would be common.  Fix it by protecting\nboth the user-direct reads and writes with damon_sysfs_lock.(CVE-2026-46121)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error\n\nWhen hci_register_dev() fails in hci_uart_register_dev()\nHCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu)\nand setting hu->hdev to NULL. This means incoming UART data will reach\nthe protocol-specific recv handler in hci_uart_tty_receive() after\nresources are freed.\n\nClear HCI_UART_PROTO_INIT with a write lock before calling\nhu->proto->close() and setting hu->hdev to NULL. The write lock ensures\nall active readers have completed and no new reader can enter the\nprotocol recv path before resources are freed.\n\nThis allows the protocol-specific recv functions to remove the\n"HCI_UART_REGISTERED" guard without risking a null pointer dereference\nif hci_register_dev() fails.(CVE-2026-53073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Clamp XDomain response data copy to allocation size\n\ntb_xdp_properties_request() derives the per-packet copy length from\nthe response header without checking that it fits in the previously\nallocated data buffer.  A malicious peer can set its length field\nlarger than the declared data_length, causing memcpy to write past\nthe kcalloc allocation.\n\nClamp the per-packet copy length so that the cumulative offset\nnever exceeds data_len.(CVE-2026-53148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios\n\nFUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios\ncan contain uninitialized data.\nSince FUSE_NOTIFY_RETRIEVE is intended to only return data that is already\nin the page cache and not wait for data from the FUSE daemon, treat\n!uptodate folios as if they weren't present.\n\nThis only has security impact on systems that don't enable automatic\nzero-initialization of all page allocations via\nCONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.(CVE-2026-53167)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: reject fuse_notify() pagecache ops on directories\n\nThe operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the\nFUSE daemon to actively write/read pagecache contents.\n\nFor directories with FOPEN_CACHE_DIR, the pagecache is used as\nkernel-internal cache storage, and userspace is not supposed to have\ndirect access to this cache - in particular, fuse_parse_cache() will hit\nWARN_ON() if the cache contains bogus data.\n\nReject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than\nregular files with -EINVAL.(CVE-2026-53168)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()\n\nbuild_i2c_fw_hdr() allocates a fixed-size buffer of\n(16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then\ncopies le16_to_cpu(img_header->Length) bytes into it without\nvalidating that Length fits within the available space after the\nfirmware record header.\n\nimg_header->Length is a __le16 from the firmware file and can be\nup to 65535. check_fw_sanity() validates the total firmware size\nbut not img_header->Length specifically.\n\nFix by rejecting images where img_header->Length exceeds the\navailable destination space.(CVE-2026-53195)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-145.1.23.160.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","kernel-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","perf-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-145.1.23.160.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-145.1.23.160.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","kernel-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","perf-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-145.1.23.160.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3529"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46021"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46033"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46121"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53073"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53148"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53167"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53168"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53195"}],"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}],"database_specific":{"severity":"High"}}