{"schema_version":"1.7.2","id":"OESA-2026-2871","modified":"2026-07-06T06:31:31Z","published":"2026-07-06T06:31:31Z","upstream":["CVE-2026-31414","CVE-2026-31453","CVE-2026-31455","CVE-2026-43112","CVE-2026-43153","CVE-2026-43158","CVE-2026-43350","CVE-2026-43365","CVE-2026-46135","CVE-2026-46149","CVE-2026-46227","CVE-2026-52946","CVE-2026-53037","CVE-2026-53071"],"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\nnetfilter: nf_conntrack_expect: use expect->helper\n\nUse expect->helper in ctnetlink and /proc to dump the helper name.\nUsing nfct_help() without holding a reference to the master conntrack\nis unsafe.\n\nUse exp->master->helper in ctnetlink path if userspace does not provide\nan explicit helper when creating an expectation to retain the existing\nbehaviour. The ctnetlink expectation path holds the reference on the\nmaster conntrack and nf_conntrack_expect lock and the nfnetlink glue\npath refers to the master ct that is attached to the skb.(CVE-2026-31414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: avoid dereferencing log items after push callbacks\n\nAfter xfsaild_push_item() calls iop_push(), the log item may have been\nfreed if the AIL lock was dropped during the push. Background inode\nreclaim or the dquot shrinker can free the log item while the AIL lock\nis not held, and the tracepoints in the switch statement dereference\nthe log item after iop_push() returns.\n\nFix this by capturing the log item type, flags, and LSN before calling\nxfsaild_push_item(), and introducing a new xfs_ail_push_class trace\nevent class that takes these pre-captured values and the ailp pointer\ninstead of the log item pointer.(CVE-2026-31453)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: stop reclaim before pushing AIL during unmount\n\nThe unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while\nbackground reclaim and inodegc are still running. This is broken\nindependently of any use-after-free issues - background reclaim and\ninodegc should not be running while the AIL is being pushed during\nunmount, as inodegc can dirty and insert inodes into the AIL during the\nflush, and background reclaim can race to abort and free dirty inodes.\n\nReorder xfs_unmount_flush_inodes() to stop inodegc and cancel background\nreclaim before pushing the AIL. Stop inodegc before cancelling\nm_reclaim_work because the inodegc worker can re-queue m_reclaim_work\nvia xfs_inodegc_set_reclaimable.(CVE-2026-31455)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath\n\nWhen cifs_sanitize_prepath is called with an empty string or a string\ncontaining only delimiters (e.g., "/"), the current logic attempts to\ncheck *(cursor2 - 1) before cursor2 has advanced. This results in an\nout-of-bounds read.\n\nThis patch adds an early exit check after stripping prepended\ndelimiters. If no path content remains, the function returns NULL.\n\nThe bug was identified via manual audit and verified using a\nstandalone test case compiled with AddressSanitizer, which\ntriggered a SEGV on affected inputs.(CVE-2026-43112)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: remove xfs_attr_leaf_hasname\n\nThe calling convention of xfs_attr_leaf_hasname() is problematic, because\nit returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer\nwhen xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a\nnon-NULL buffer pointer for an already released buffer when\nxfs_attr3_leaf_lookup_int fails with other error values.\n\nFix this by simply open coding xfs_attr_leaf_hasname in the callers, so\nthat the buffer release code is done by each caller of\nxfs_attr3_leaf_read.(CVE-2026-43153)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: fix freemap adjustments when adding xattrs to leaf blocks\n\nxfs/592 and xfs/794 both trip this assertion in the leaf block freemap\nadjustment code after ~20 minutes of running on my test VMs:\n\n ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t)\n\t\t\t\t\t+ xfs_attr3_leaf_hdr_size(leaf));\n\nUpon enabling quite a lot more debugging code, I narrowed this down to\nfsstress trying to set a local extended attribute with namelen=3 and\nvaluelen=71.  This results in an entry size of 80 bytes.\n\nAt the start of xfs_attr3_leaf_add_work, the freemap looks like this:\n\ni 0 base 448 size 0 rhs 448 count 46\ni 1 base 388 size 132 rhs 448 count 46\ni 2 base 2120 size 4 rhs 448 count 46\nfirstused = 520\n\nwhere "rhs" is the first byte past the end of the leaf entry array.\nThis is inconsistent -- the entries array ends at byte 448, but\nfreemap[1] says there's free space starting at byte 388!\n\nBy the end of the function, the freemap is in worse shape:\n\ni 0 base 456 size 0 rhs 456 count 47\ni 1 base 388 size 52 rhs 456 count 47\ni 2 base 2120 size 4 rhs 456 count 47\nfirstused = 440\n\nImportant note: 388 is not aligned with the entries array element size\nof 8 bytes.\n\nBased on the incorrect freemap, the name area starts at byte 440, which\nis below the end of the entries array!  That's why the assertion\ntriggers and the filesystem shuts down.\n\nHow did we end up here?  First, recall from the previous patch that the\nfreemap array in an xattr leaf block is not intended to be a\ncomprehensive map of all free space in the leaf block.  In other words,\nit's perfectly legal to have a leaf block with:\n\n * 376 bytes in use by the entries array\n * freemap[0] has [base = 376, size = 8]\n * freemap[1] has [base = 388, size = 1500]\n * the space between 376 and 388 is free, but the freemap stopped\n   tracking that some time ago\n\nIf we add one xattr, the entries array grows to 384 bytes, and\nfreemap[0] becomes [base = 384, size = 0].  So far, so good.  But if we\nadd a second xattr, the entries array grows to 392 bytes, and freemap[0]\ngets pushed up to [base = 392, size = 0].  This is bad, because\nfreemap[1] hasn't been updated, and now the entries array and the free\nspace claim the same space.\n\nThe fix here is to adjust all freemap entries so that none of them\ncollide with the entries array.  Note that this fix relies on commit\n2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and\nthe previous patch that resets zero length freemap entries to have\nbase = 0.(CVE-2026-43158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: require a full NFS mode SID before reading mode bits\n\nparse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS\nmode SID and reads sid.sub_auth[2] to recover the mode bits.\n\nThat assumes the ACE carries three subauthorities, but compare_sids()\nonly compares min(a, b) subauthorities.  A malicious server can return\nan ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still\nmatches sid_unix_NFS_mode and then drives the sub_auth[2] read four\nbytes past the end of the ACE.\n\nRequire num_subauth >= 3 before treating the ACE as an NFS mode SID.\nThis keeps the fix local to the special-SID mode path without changing\ncompare_sids() semantics for the rest of cifsacl.(CVE-2026-43350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: fix undersized l_iclog_roundoff values\n\nIf the superblock doesn't list a log stripe unit, we set the incore log\nroundoff value to 512.  This leads to corrupt logs and unmountable\nfilesystems in generic/617 on a disk with 4k physical sectors...\n\nXFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c\nXFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197.\nXFS (sda1): failed to locate log tail\nXFS (sda1): log mount/recovery failed: error -74\nXFS (sda1): log mount failed\nXFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c\nXFS (sda1): Ending clean mount\n\n...on the current xfsprogs for-next which has a broken mkfs.  xfs_info\nshows this...\n\nmeta-data=/dev/sda1              isize=512    agcount=4, agsize=644992 blks\n         =                       sectsz=4096  attr=2, projid32bit=1\n         =                       crc=1        finobt=1, sparse=1, rmapbt=1\n         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1\n         =                       exchange=1   metadir=1\ndata     =                       bsize=4096   blocks=2579968, imaxpct=25\n         =                       sunit=0      swidth=0 blks\nnaming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=1\nlog      =internal log           bsize=4096   blocks=16384, version=2\n         =                       sectsz=4096  sunit=0 blks, lazy-count=1\nrealtime =none                   extsz=4096   blocks=0, rtextents=0\n         =                       rgcount=0    rgsize=268435456 extents\n         =                       zoned=0      start=0 reserved=0\n\n...observe that the log section has sectsz=4096 sunit=0, which means\nthat the roundoff factor is 512, not 4096 as you'd expect.  We should\nfix mkfs not to generate broken filesystems, but anyone can fuzz the\nondisk superblock so we should be more cautious.  I think the inadequate\nlogic predates commit a6a65fef5ef8d0, but that's clearly going to\nrequire a different backport.(CVE-2026-43365)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fix race between ICReq handling and queue teardown\n\nnvmet_tcp_handle_icreq() updates queue->state after sending an\nInitialization Connection Response (ICResp), but it does so without\nserializing against target-side queue teardown.\n\nIf an NVMe/TCP host sends an Initialization Connection Request\n(ICReq) and immediately closes the connection, target-side teardown\nmay start in softirq context before io_work drains the already\nbuffered ICReq. In that case, nvmet_tcp_schedule_release_queue()\nsets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue\nreference under state_lock.\n\nIf io_work later processes that ICReq, nvmet_tcp_handle_icreq() can\nstill overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the\nDISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and\nallows a later socket state change to re-enter teardown and issue a\nsecond kref_put() on an already released queue.\n\nThe ICResp send failure path has the same problem. If teardown has\nalready moved the queue to DISCONNECTING, a send error can still\noverwrite the state with NVMET_TCP_Q_FAILED, again reopening the\nwindow for a second teardown path to drop the queue reference.\n\nFix this by serializing both post-send state transitions with\nstate_lock and bailing out if teardown has already started.\n\nUse -ESHUTDOWN as an internal sentinel for that bail-out path rather\nthan propagating it as a transport error like -ECONNRESET. Keep\nnvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before\nhonoring that sentinel so receive-side parsing stays quiesced until the\nexisting release path completes.(CVE-2026-46135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show()\n\ntarget_tg_pt_gp_members_show() formats LUN paths with snprintf() into a\n256-byte stack buffer, then will memcpy() cur_len bytes from that\nbuffer.  snprintf() returns the length the output would have had, which\ncan exceed the buffer size when the fabric WWN is long because iSCSI IQN\nnames can be up to 223 bytes.  The check at the memcpy() site only\nguards the destination page write, not the source read, so memcpy() will\nread past the stack buffer and copy adjacent stack contents to the sysfs\nreader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic()\nwill be triggered.\n\nCommit 27e06650a5ea ("scsi: target: target_core_configfs: Add length\ncheck to avoid buffer overflow") added the same bound to the\ntarget_lu_gp_members_show() but the tg_pt_gp variant was missed so\nresolve that here.(CVE-2026-46149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL\n\nThe SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with\nlist_for_each_entry_safe(), which caches the next entry in @tmp before\nthe loop body runs.  The body calls sctp_sendmsg_to_asoc(), which may\ndrop the socket lock inside sctp_wait_for_sndbuf().\n\nWhile the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the\nassociation cached in @tmp, migrating it to a new endpoint via\nsctp_sock_migrate() (list_del_init() + list_add_tail() to\nnewep->asocs), and optionally close the new socket which frees the\nassociation via kfree_rcu().  The cached @tmp can also be freed by a\nnetwork ABORT for that association, processed in softirq while the\nlock is dropped.\n\nsctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock\nvia the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing\nrevalidates @tmp.  After a successful return, the iterator advances to\nthe stale @tmp, yielding either a use-after-free (if the peeled socket\nwas closed) or a list-walk onto the new endpoint's list head (type\nconfusion of &newep->asocs as a struct sctp_association *).\n\nBoth are reachable from CapEff=0; the type-confusion path gives\ncontrolled indirect call via the outqueue.sched->init_sid pointer.\n\nFix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc()\nreturns.  @asoc is known to still be on ep->asocs at that point: the\nonly callers that list_del an association from ep->asocs are\nsctp_association_free() (which sets asoc->base.dead) and\nsctp_assoc_migrate() (which changes asoc->base.sk), and\nsctp_wait_for_sndbuf() checks both under the lock before any\nsuccessful return; a tripped check propagates as err < 0 and the loop\nbails before the re-derive.\n\nThe SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the\nloop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so\nthe @tmp cached by list_for_each_entry_safe() still covers the\nlock-held free that ba59fb027307 ("sctp: walk the list of asoc\nsafely") was added for.(CVE-2026-46227)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling\n\nA SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in\nsend_sigio() and send_sigurg() when a process group receives a signal.\n\nWhen FASYNC is configured for a process group (PIDTYPE_PGID), both\nfunctions use read_lock(&tasklist_lock) to traverse the task list.\nHowever, they are frequently called from softirq context:\n- send_sigio() via input_inject_event -> kill_fasync\n- send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)\n\nThe deadlock is caused by the rwlock writer fairness mechanism:\n1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait().\n2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in\n   fork() or exit() and spins, which blocks all new readers.\n3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).\n4. The softirq calls send_sigurg() and attempts to acquire\n   read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.\n\nSince PID hashing and do_each_pid_task() traversals are already\nRCU-protected, the read_lock on tasklist_lock is no longer strictly\nrequired for safe traversal. Fix this by replacing tasklist_lock with\nrcu_read_lock(), aligning the process group signaling path with the\nsingle-PID path. This also mitigates a potential remote denial of\nservice vector via TCP URG packets.\n\nLockdep splat:\n=====================================================\nWARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected\n[...]\nChain exists of:\n  &dev->event_lock --> &f_owner->lock --> tasklist_lock\n\nPossible interrupt unsafe locking scenario:\n       CPU0                    CPU1\n       ----                    ----\n  lock(tasklist_lock);\n                           local_irq_disable();\n                           lock(&dev->event_lock);\n                           lock(&f_owner->lock);\n  <Interrupt>\n    lock(&dev->event_lock);\n\n*** DEADLOCK ***(CVE-2026-52946)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: usbhid: fix deadlock in hid_post_reset()\n\nYou can build a USB device that includes a HID component\nand a storage or UAS component. The components can be reset\nonly together. That means that hid_pre_reset() and hid_post_reset()\nare in the block IO error handling. Hence no memory allocation\nused in them may do block IO because the IO can deadlock\non the mutex held while resetting a device and calling the\ninterface drivers.\nUse GFP_NOIO for all allocations in them.(CVE-2026-53037)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp\n\nl2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding\nl2cap_chan_lock(). Every other l2cap_chan_del() caller in the file\nacquires the lock first. A remote BLE device can send a crafted\nL2CAP ECRED reconfiguration response to corrupt the channel list\nwhile another thread is iterating it.\n\nAdd l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(),\nand l2cap_chan_unlock() and l2cap_chan_put() after, matching the\npattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().(CVE-2026-53071)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-321.0.0.223.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","kernel-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","perf-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-321.0.0.223.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-321.0.0.223.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","kernel-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","perf-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-321.0.0.223.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2871"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31414"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31453"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-31455"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43112"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43153"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43158"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43350"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43365"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46135"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46149"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46227"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-52946"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53037"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53071"}],"database_specific":{"severity":"Critical"}}