GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2026-2871 (CVE-2026-31414)

Vulnerability from osv_openeuler – Published: 2026-07-06 11:11 – Updated: 2026-08-06 11:11 – Source website
VLAI
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_conntrack_expect: use expect->helper

Use expect->helper in ctnetlink and /proc to dump the helper name. Using nfct_help() without holding a reference to the master conntrack is unsafe.

Use exp->master->helper in ctnetlink path if userspace does not provide an explicit helper when creating an expectation to retain the existing behaviour. The ctnetlink expectation path holds the reference on the master conntrack and nf_conntrack_expect lock and the nfnetlink glue path refers to the master ct that is attached to the skb.(CVE-2026-31414)

In the Linux kernel, the following vulnerability has been resolved:

xfs: avoid dereferencing log items after push callbacks

After xfsaild_push_item() calls iop_push(), the log item may have been freed if the AIL lock was dropped during the push. Background inode reclaim or the dquot shrinker can free the log item while the AIL lock is not held, and the tracepoints in the switch statement dereference the log item after iop_push() returns.

Fix this by capturing the log item type, flags, and LSN before calling xfsaild_push_item(), and introducing a new xfs_ail_push_class trace event class that takes these pre-captured values and the ailp pointer instead of the log item pointer.(CVE-2026-31453)

In the Linux kernel, the following vulnerability has been resolved:

xfs: stop reclaim before pushing AIL during unmount

The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while background reclaim and inodegc are still running. This is broken independently of any use-after-free issues - background reclaim and inodegc should not be running while the AIL is being pushed during unmount, as inodegc can dirty and insert inodes into the AIL during the flush, and background reclaim can race to abort and free dirty inodes.

Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background reclaim before pushing the AIL. Stop inodegc before cancelling m_reclaim_work because the inodegc worker can re-queue m_reclaim_work via xfs_inodegc_set_reclaimable.(CVE-2026-31455)

In the Linux kernel, the following vulnerability has been resolved:

fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath

When cifs_sanitize_prepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check *(cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read.

This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL.

The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.(CVE-2026-43112)

In the Linux kernel, the following vulnerability has been resolved:

xfs: remove xfs_attr_leaf_hasname

The calling convention of xfs_attr_leaf_hasname() is problematic, because it returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer when xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a non-NULL buffer pointer for an already released buffer when xfs_attr3_leaf_lookup_int fails with other error values.

Fix this by simply open coding xfs_attr_leaf_hasname in the callers, so that the buffer release code is done by each caller of xfs_attr3_leaf_read.(CVE-2026-43153)

In the Linux kernel, the following vulnerability has been resolved:

xfs: fix freemap adjustments when adding xattrs to leaf blocks

xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs:

ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf));

Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes.

At the start of xfs_attr3_leaf_add_work, the freemap looks like this:

i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520

where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388!

By the end of the function, the freemap is in worse shape:

i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440

Important note: 388 is not aligned with the entries array element size of 8 bytes.

Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down.

How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with:

  • 376 bytes in use by the entries array
  • freemap[0] has [base = 376, size = 8]
  • freemap[1] has [base = 388, size = 1500]
  • the space between 376 and 388 is free, but the freemap stopped tracking that some time ago

If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space.

The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0.(CVE-2026-43158)

In the Linux kernel, the following vulnerability has been resolved:

smb: client: require a full NFS mode SID before reading mode bits

parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits.

That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE.

Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl.(CVE-2026-43350)

In the Linux kernel, the following vulnerability has been resolved:

xfs: fix undersized l_iclog_roundoff values

If the superblock doesn't list a log stripe unit, we set the incore log roundoff value to 512. This leads to corrupt logs and unmountable filesystems in generic/617 on a disk with 4k physical sectors...

XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197. XFS (sda1): failed to locate log tail XFS (sda1): log mount/recovery failed: error -74 XFS (sda1): log mount failed XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Ending clean mount

...on the current xfsprogs for-next which has a broken mkfs. xfs_info shows this...

meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0

...observe that the log section has sectsz=4096 sunit=0, which means that the roundoff factor is 512, not 4096 as you'd expect. We should fix mkfs not to generate broken filesystems, but anyone can fuzz the ondisk superblock so we should be more cautious. I think the inadequate logic predates commit a6a65fef5ef8d0, but that's clearly going to require a different backport.(CVE-2026-43365)

In the Linux kernel, the following vulnerability has been resolved:

nvmet-tcp: fix race between ICReq handling and queue teardown

nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown.

If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before io_work drains the already buffered ICReq. In that case, nvmet_tcp_schedule_release_queue() sets queue->state to NVMET_TCP_Q_DISCONNECTING and drops the queue reference under state_lock.

If io_work later processes that ICReq, nvmet_tcp_handle_icreq() can still overwrite the state back to NVMET_TCP_Q_LIVE. That defeats the DISCONNECTING-state guard in nvmet_tcp_schedule_release_queue() and allows a later socket state change to re-enter teardown and issue a second kref_put() on an already released queue.

The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMET_TCP_Q_FAILED, again reopening the window for a second teardown path to drop the queue reference.

Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started.

Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmet_tcp_socket_error() setting rcv_state to NVMET_TCP_RECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.(CVE-2026-46135)

In the Linux kernel, the following vulnerability has been resolved:

scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show()

target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a 256-byte stack buffer, then will memcpy() cur_len bytes from that buffer. snprintf() returns the length the output would have had, which can exceed the buffer size when the fabric WWN is long because iSCSI IQN names can be up to 223 bytes. The check at the memcpy() site only guards the destination page write, not the source read, so memcpy() will read past the stack buffer and copy adjacent stack contents to the sysfs reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic() will be triggered.

Commit 27e06650a5ea ("scsi: target: target_core_configfs: Add length check to avoid buffer overflow") added the same bound to the target_lu_gp_members_show() but the tg_pt_gp variant was missed so resolve that here.(CVE-2026-46149)

In the Linux kernel, the following vulnerability has been resolved:

sctp: revalidate list cursor after sctp_sendmsg_to_asoc() in SCTP_SENDALL

The SCTP_SENDALL path in sctp_sendmsg() iterates ep->asocs with list_for_each_entry_safe(), which caches the next entry in @tmp before the loop body runs. The body calls sctp_sendmsg_to_asoc(), which may drop the socket lock inside sctp_wait_for_sndbuf().

While the lock is dropped, another thread can SCTP_SOCKOPT_PEELOFF the association cached in @tmp, migrating it to a new endpoint via sctp_sock_migrate() (list_del_init() + list_add_tail() to newep->asocs), and optionally close the new socket which frees the association via kfree_rcu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped.

sctp_wait_for_sndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctp_association *).

Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->init_sid pointer.

Fix by re-deriving @tmp from @asoc after sctp_sendmsg_to_asoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that list_del an association from ep->asocs are sctp_association_free() (which sets asoc->base.dead) and sctp_assoc_migrate() (which changes asoc->base.sk), and sctp_wait_for_sndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive.

The SCTP_ABORT path in sctp_sendmsg_check_sflags() returns 0 and the loop hits 'continue' before sctp_sendmsg_to_asoc() is ever called, so the @tmp cached by list_for_each_entry_safe() still covers the lock-held free that ba59fb027307 ("sctp: walk the list of asoc safely") was added for.(CVE-2026-46227)

In the Linux kernel, the following vulnerability has been resolved:

fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling

A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in send_sigio() and send_sigurg() when a process group receives a signal.

When FASYNC is configured for a process group (PIDTYPE_PGID), both functions use read_lock(&tasklist_lock) to traverse the task list. However, they are frequently called from softirq context: - send_sigio() via input_inject_event -> kill_fasync - send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)

The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait(). 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.

Since PID hashing and do_each_pid_task() traversals are already RCU-protected, the read_lock on tasklist_lock is no longer strictly required for safe traversal. Fix this by replacing tasklist_lock with rcu_read_lock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets.

Lockdep splat:

WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lock

Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); <Interrupt> lock(&dev->event_lock);

*** DEADLOCK ***(CVE-2026-52946)

In the Linux kernel, the following vulnerability has been resolved:

HID: usbhid: fix deadlock in hid_post_reset()

You can build a USB device that includes a HID component and a storage or UAS component. The components can be reset only together. That means that hid_pre_reset() and hid_post_reset() are in the block IO error handling. Hence no memory allocation used in them may do block IO because the IO can deadlock on the mutex held while resetting a device and calling the interface drivers. Use GFP_NOIO for all allocations in them.(CVE-2026-53037)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp

l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it.

Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(), and l2cap_chan_unlock() and l2cap_chan_put() after, matching the pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().(CVE-2026-53071)

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "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"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-321.0.0.223.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "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-\u0026gt;helper\n\nUse expect-\u0026gt;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-\u0026gt;master-\u0026gt;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., \u0026quot;/\u0026quot;), 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-\u0026gt;firstused \u0026gt;= ichdr-\u0026gt;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 \u0026quot;rhs\u0026quot; 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\u0026apos;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\u0026apos;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\u0026apos;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\u0026apos;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 (\u0026quot;xfs: fix attr leaf header freemap.size underflow\u0026quot;) 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 \u0026gt;= 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\u0026apos;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\u0026apos;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\u0026apos;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-\u0026gt;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-\u0026gt;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 (\u0026quot;scsi: target: target_core_configfs: Add length\ncheck to avoid buffer overflow\u0026quot;) 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-\u0026gt;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-\u0026gt;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 \u0026quot;sk != asoc-\u0026gt;base.sk\u0026quot; and \u0026quot;asoc-\u0026gt;base.dead\u0026quot; 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\u0026apos;s list head (type\nconfusion of \u0026amp;newep-\u0026gt;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-\u0026gt;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-\u0026gt;asocs at that point: the\nonly callers that list_del an association from ep-\u0026gt;asocs are\nsctp_association_free() (which sets asoc-\u0026gt;base.dead) and\nsctp_assoc_migrate() (which changes asoc-\u0026gt;base.sk), and\nsctp_wait_for_sndbuf() checks both under the lock before any\nsuccessful return; a tripped check propagates as err \u0026lt; 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 \u0026apos;continue\u0026apos; 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 (\u0026quot;sctp: walk the list of asoc\nsafely\u0026quot;) 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(\u0026amp;tasklist_lock) to traverse the task list.\nHowever, they are frequently called from softirq context:\n- send_sigio() via input_inject_event -\u0026gt; kill_fasync\n- send_sigurg() via tcp_check_urg -\u0026gt; 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(\u0026amp;tasklist_lock) in do_wait().\n2. CPU 1 (process context) attempts write_lock(\u0026amp;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(\u0026amp;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 -\u0026gt; SOFTIRQ-unsafe lock order detected\n[...]\nChain exists of:\n  \u0026amp;dev-\u0026gt;event_lock --\u0026gt; \u0026amp;f_owner-\u0026gt;lock --\u0026gt; tasklist_lock\n\nPossible interrupt unsafe locking scenario:\n       CPU0                    CPU1\n       ----                    ----\n  lock(tasklist_lock);\n                           local_irq_disable();\n                           lock(\u0026amp;dev-\u0026gt;event_lock);\n                           lock(\u0026amp;f_owner-\u0026gt;lock);\n  \u0026lt;Interrupt\u0026gt;\n    lock(\u0026amp;dev-\u0026gt;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)",
  "id": "OESA-2026-2871",
  "modified": "2026-08-06T11:11:47Z",
  "published": "2026-07-06T11:11:47Z",
  "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "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"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.