In the Linux kernel, the following vulnerability has been resolved: btrfs: fix zero size inode with non-zero size after log replay When logging that an inode exists, as part of logging a new name or logging new dir entries for a directory, we always set the generation of the logged inode item to 0. This is to signal during log replay (in overwrite_item()), that we should not set the i_size since we only logged that an inode exists, so the i_size of the inode in the subvolume tree must be preserved (as when we log new names or that an inode exists, we don't log extents). This works fine except when we have already logged an inode in full mode or it's the first time we are logging an inode created in a past transaction, that inode has a new i_size of 0 and then we log a new name for the inode (due to a new hardlink or a rename), in which case we log an i_size of 0 for the inode and a generation of 0, which causes the log replay code to not update the inode's i_size to 0 (in overwrite_item()). An example scenario: mkdir /mnt/dir xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo sync xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo ln /mnt/dir/foo /mnt/dir/bar xfs_io -c "fsync" /mnt/dir <power fail> After log replay the file remains with a size of 64K. This is because when we first log the inode, when we fsync file foo, we log its current i_size of 0, and then when we create a hard link we log again the inode in exists mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we add to the log tree, so during log replay overwrite_item() sees that the generation is 0 and i_size is 0 so we skip updating the inode's i_size from 64K to 0. Fix this by making sure at fill_inode_item() we always log the real generation of the inode if it was logged in the current transaction with the i_size we logged before. Also if an inode created in a previous transaction is logged in exists mode only, make sure we log the i_size stored in the inode item located from the commit root, so that if we log multiple times that the inode exists we get the correct i_size. A test case for fstests will follow soon.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: btrfs: fix zero size inode with non-
    zero size after log replay When logging that an inode exists, as part of logging a new name or logging new
    dir entries for a directory, we always set the generation of the logged inode item to 0. This is to signal
    during log replay (in overwrite_item()), that we should not set the i_size since we only logged that an
    inode exists, so the i_size of the inode in the subvolume tree must be preserved (as when we log new names
    or that an inode exists, we don't log extents). This works fine except when we have already logged an
    inode in full mode or it's the first time we are logging an inode created in a past transaction, that
    inode has a new i_size of 0 and then we log a new name for the inode (due to a new hardlink or a rename),
    in which case we log an i_size of 0 for the inode and a generation of 0, which causes the log replay code
    to not update the inode's i_size to 0 (in overwrite_item()). An example scenario: mkdir /mnt/dir xfs_io -f
    -c "pwrite 0 64K" /mnt/dir/foo sync xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo ln /mnt/dir/foo
    /mnt/dir/bar xfs_io -c "fsync" /mnt/dir <power fail> After log replay the file remains with a size of 64K.
    This is because when we first log the inode, when we fsync file foo, we log its current i_size of 0, and
    then when we create a hard link we log again the inode in exists mode (LOG_INODE_EXISTS) but we set a
    generation of 0 for the inode item we add to the log tree, so during log replay overwrite_item() sees that
    the generation is 0 and i_size is 0 so we skip updating the inode's i_size from 64K to 0. Fix this by
    making sure at fill_inode_item() we always log the real generation of the inode if it was logged in the
    current transaction with the i_size we logged before. Also if an inode created in a previous transaction
    is logged in exists mode only, make sure we log the i_size stored in the inode item located from the
    commit root, so that if we log multiple times that the inode exists we get the correct i_size. A test case
    for fstests will follow soon. (CVE-2026-43118)

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-098815 advisory.

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

    btrfs: fix zero size inode with non-zero size after log replay

    When logging that an inode exists, as part of logging a new name or     logging new dir entries for a directory, we always set the generation of     the logged inode item to 0. This is to signal during log replay (in     overwrite_item()), that we should not set the i_size since we only logged     that an inode exists, so the i_size of the inode in the subvolume tree     must be preserved (as when we log new names or that an inode exists, we     don't log extents).

    This works fine except when we have already logged an inode in full mode     or it's the first time we are logging an inode created in a past     transaction, that inode has a new i_size of 0 and then we log a new name     for the inode (due to a new hardlink or a rename), in which case we log     an i_size of 0 for the inode and a generation of 0, which causes the log     replay code to not update the inode's i_size to 0 (in overwrite_item()).

    An example scenario:

      mkdir /mnt/dir       xfs_io -f -c pwrite 0 64K /mnt/dir/foo

      sync

      xfs_io -c truncate 0 -c fsync /mnt/dir/foo

      ln /mnt/dir/foo /mnt/dir/bar

      xfs_io -c fsync /mnt/dir

      <power fail>

    After log replay the file remains with a size of 64K. This is because when     we first log the inode, when we fsync file foo, we log its current i_size     of 0, and then when we create a hard link we log again the inode in exists     mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we     add to the log tree, so during log replay overwrite_item() sees that the     generation is 0 and i_size is 0 so we skip updating the inode's i_size     from 64K to 0.

    Fix this by making sure at fill_inode_item() we always log the real     generation of the inode if it was logged in the current transaction with     the i_size we logged before. Also if an inode created in a previous     transaction is logged in exists mode only, make sure we log the i_size     stored in the inode item located from the commit root, so that if we log     multiple times that the inode exists we get the correct i_size.

    A test case for fstests will follow soon.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-102103 advisory.

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

    btrfs: fix zero size inode with non-zero size after log replay

    When logging that an inode exists, as part of logging a new name or     logging new dir entries for a directory, we always set the generation of     the logged inode item to 0. This is to signal during log replay (in     overwrite_item()), that we should not set the i_size since we only logged     that an inode exists, so the i_size of the inode in the subvolume tree     must be preserved (as when we log new names or that an inode exists, we     don't log extents).

    This works fine except when we have already logged an inode in full mode     or it's the first time we are logging an inode created in a past     transaction, that inode has a new i_size of 0 and then we log a new name     for the inode (due to a new hardlink or a rename), in which case we log     an i_size of 0 for the inode and a generation of 0, which causes the log     replay code to not update the inode's i_size to 0 (in overwrite_item()).

    An example scenario:

      mkdir /mnt/dir       xfs_io -f -c pwrite 0 64K /mnt/dir/foo

      sync

      xfs_io -c truncate 0 -c fsync /mnt/dir/foo

      ln /mnt/dir/foo /mnt/dir/bar

      xfs_io -c fsync /mnt/dir

      <power fail>

    After log replay the file remains with a size of 64K. This is because when     we first log the inode, when we fsync file foo, we log its current i_size     of 0, and then when we create a hard link we log again the inode in exists     mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we     add to the log tree, so during log replay overwrite_item() sees that the     generation is 0 and i_size is 0 so we skip updating the inode's i_size     from 64K to 0.

    Fix this by making sure at fill_inode_item() we always log the real     generation of the inode if it was logged in the current transaction with     the i_size we logged before. Also if an inode created in a previous     transaction is logged in exists mode only, make sure we log the i_size     stored in the inode item located from the commit root, so that if we log     multiple times that the inode exists we get the correct i_size.

    A test case for fstests will follow soon.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-1693 advisory.

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

    af_unix: Give up GC if MSG_PEEK intervened. (CVE-2026-23394)

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

    ipv6: add NULL checks for idev in SRv6 paths (CVE-2026-23442)

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

    netfilter: conntrack: add missing netlink policy validations (CVE-2026-31407)

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

    netfilter: ipset: drop logically empty buckets in mtype_del (CVE-2026-31418)

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

    net: skb: fix cross-cache free of KFENCE-allocated skb head (CVE-2026-31429)

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

    X.509: Fix out-of-bounds access when parsing extensions (CVE-2026-31430)

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

    ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop() (CVE-2026-31531)

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

    can: raw: fix ro->uniq use-after-free in raw_rcv() (CVE-2026-31532)

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

    net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption (CVE-2026-31533)

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

    mm/userfaultfd: fix hugetlb fault mutex hash calculation (CVE-2026-31575)

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

    wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit (CVE-2026-31579)

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

    bcache: fix cached_dev.sb_bio use-after-free and crash (CVE-2026-31580)

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

    mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() (CVE-2026-31586)

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

    KVM: x86: Use scratch field in MMIO fragment to hold small write values (CVE-2026-31588)

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

    KVM: SEV: Lock all vCPUs when synchronzing VMSAs for SNP launch finish (CVE-2026-31591)

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

    KVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm->lock (CVE-2026-31592)

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

    KVM: SEV: Reject attempts to sync VMSA of an already-launched/encrypted vCPU (CVE-2026-31593)

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

    arm64: mm: Handle invalid large leaf mappings correctly (CVE-2026-31600)

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

    usbip: validate number_of_packets in usbip_pack_ret_submit() (CVE-2026-31607)

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

    smb: client: fix OOB reads parsing symlink error response (CVE-2026-31613)

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

    smb: client: fix off-by-8 bounds check in check_wsl_eas() (CVE-2026-31614)

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

    HID: core: clamp report_size in s32ton() to avoid undefined shift (CVE-2026-31624)

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

    HID: alps: fix NULL pointer dereference in alps_raw_event() (CVE-2026-31625)

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

    x86/CPU: Fix FPDSS on Zen1 (CVE-2026-31628)

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

    rxrpc: fix reference count leak in rxrpc_server_keyring() (CVE-2026-31634)

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

    rxrpc: reject undecryptable rxkad response tickets (CVE-2026-31637)

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

    mm: filemap: fix nr_pages calculation overflow in filemap_map_pages() (CVE-2026-31648)

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

    mm/damon/sysfs: dealloc repeat_call_control if damon_call() fails (CVE-2026-31653)

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

    drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat (CVE-2026-31656)

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

    tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG (CVE-2026-31662)

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

    xfrm: hold dev ref until after transport_finish NF_HOOK (CVE-2026-31663)

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

    xfrm: clear trailing padding in build_polexpire() (CVE-2026-31664)

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

    netfilter: nft_ct: fix use-after-free in timeout object destroy (CVE-2026-31665)

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

    btrfs: fix incorrect return value after changing leaf in lookup_extent_data_ref() (CVE-2026-31666)

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

    Input: uinput - fix circular locking dependency with ff-core (CVE-2026-31667)

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

    seg6: separate dst_cache for input and output paths in seg6 lwtunnel (CVE-2026-31668)

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

    mptcp: fix slab-use-after-free in __inet_lookup_established (CVE-2026-31669)

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

    xfrm_user: fix info leak in build_report() (CVE-2026-31671)

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

    af_unix: read UNIX_DIAG_VFS data under unix_state_lock (CVE-2026-31673)

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

    netfilter: xt_multiport: validate range encoding in checkentry (CVE-2026-31681)

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

    net: sched: act_csum: validate nested VLAN headers (CVE-2026-31684)

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

    netfilter: ip6t_eui64: reject invalid MAC header for all packets (CVE-2026-31685)

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

    EDAC/mc: Fix error path ordering in edac_mc_alloc() (CVE-2026-31689)

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

    igb: remove napi_synchronize() in igb_down() (CVE-2026-31691)

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

    rtnetlink: add missing netlink_ns_capable() check for peer netns (CVE-2026-31692)

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

    fuse: reject oversized dirents in page cache (CVE-2026-31694)

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

    net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd() (CVE-2026-31700)

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

    writeback: Fix use after free in inode_switch_wbs_work_fn() (CVE-2026-31703)

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

    smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path (CVE-2026-31708)

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

    fuse: abort on fatal signal during sync init (CVE-2026-31713)

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

    fs/ntfs3: validate rec->used in journal-replay file record check (CVE-2026-31716)

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

    crypto: krb5enc - fix async decrypt skipping hash verification (CVE-2026-31719)

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

    dcache: Limit the minimal number of bucket to two (CVE-2026-43071)

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

    x86-64: rename misleadingly named '__copy_user_nocache()' function (CVE-2026-43073)

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

    eventpoll: defer struct eventpoll free to RCU grace period (CVE-2026-43074)

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

    perf/x86/intel/uncore: Skip discovery table for offline dies (CVE-2026-43079)

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

    net: ioam6: fix OOB and missing lock (CVE-2026-43083)

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

    netfilter: nfnetlink_queue: make hash table per queue (CVE-2026-43084)

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

    netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator (CVE-2026-43085)

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

    ipvs: fix NULL deref in ip_vs_add_service error path (CVE-2026-43086)

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

    xfrm_user: fix info leak in build_mapping() (CVE-2026-43089)

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

    xfrm: fix refcount leak in xfrm_migrate_policy_find (CVE-2026-43090)

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

    xfrm: Wait for RCU readers during policy netns exit (CVE-2026-43091)

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

    xsk: validate MTU against usable frame size on bind (CVE-2026-43092)

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

    xsk: tighten UMEM headroom validation to account for tailroom and min frame (CVE-2026-43093)

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

    ixgbevf: add missing negotiate_features op to Hyper-V ops table (CVE-2026-43094)

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

    ipv4: icmp: fix null-ptr-deref in icmp_build_probe() (CVE-2026-43099)

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

    bridge: guard local VLAN-0 FDB helpers against NULL vlan group (CVE-2026-43100)

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

    ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data() (CVE-2026-43101)

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

    xfrm: account XFRMA_IF_ID in aevent size calculation (CVE-2026-43107)

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

    x86: shadow stacks: proper error handling for mmap lock (CVE-2026-43109)

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

    fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath (CVE-2026-43112)

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

    netfilter: nft_set_pipapo_avx2: don't return non-matching entry on expiry (CVE-2026-43114)

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

    netfilter: ctnetlink: ensure safe access to master conntrack (CVE-2026-43116)

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

    btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() (CVE-2026-43117)

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

    btrfs: fix zero size inode with non-zero size after log replay (CVE-2026-43118)

    In the Linux kernel, the following vulnerability has been resolved:xfrm: esp: avoid in-place decrypt on     shared skb frags

    Dirty Frag and other issues in Amazon Linux kernels:https://aws.amazon.com/security/security-     bulletins/2026-027-aws/ (CVE-2026-43284)

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

    smb: client: require a full NFS mode SID before reading mode bits (CVE-2026-43350)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - btrfs: fix zero size inode with non-zero size after log replay When logging that an inode exists, as part     of logging a new name or logging new dir entries for a directory, we always set the generation of the     logged inode item to 0. This is to signal during log replay (in overwrite_item()), that we should not set     the i_size since we only logged that an inode exists, so the i_size of the inode in the subvolume tree     must be preserved (as when we log new names or that an inode exists, we don't log extents). This works     fine except when we have already logged an inode in full mode or it's the first time we are logging an     inode created in a past transaction, that inode has a new i_size of 0 and then we log a new name for the     inode (due to a new hardlink or a rename), in which case we log an i_size of 0 for the inode and a     generation of 0, which causes the log replay code to not update the inode's i_size to 0 (in     overwrite_item()). An example scenario: mkdir /mnt/dir xfs_io -f -c pwrite 0 64K /mnt/dir/foo sync     xfs_io -c truncate 0 -c fsync /mnt/dir/foo ln /mnt/dir/foo /mnt/dir/bar xfs_io -c fsync /mnt/dir     <power fail> After log replay the file remains with a size of 64K. This is because when we first log the     inode, when we fsync file foo, we log its current i_size of 0, and then when we create a hard link we log     again the inode in exists mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we add     to the log tree, so during log replay overwrite_item() sees that the generation is 0 and i_size is 0 so we     skip updating the inode's i_size from 64K to 0. Fix this by making sure at fill_inode_item() we always log     the real generation of the inode if it was logged in the current transaction with the i_size we logged     before. Also if an inode created in a previous transaction is logged in exists mode only, make sure we log     the i_size stored in the inode item located from the commit root, so that if we log multiple times that     the inode exists we get the correct i_size. A test case for fstests will follow soon. (CVE-2026-43118)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
471367	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19804.0.0	Tenable Cloud Security	Google COS Security Checks	Local	medium
471367	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19804.0.0	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	medium
340524	Unity Linux 20.1050a Security Update: kernel (UTSA-2026-098815)	Nessus	Unity Linux Local Security Checks	Local	medium
338484	Unity Linux 20.1050e Security Update: kernel (UTSA-2026-102103)	Nessus	Unity Linux Local Security Checks	Local	medium
335080	openSUSE 16: cluster-md-kmp-64kb / cluster-md-kmp-azure / cluster-md-kmp-default / etc (openSUSE-SU-2026:21555-1)	Nessus	SuSE Local Security Checks	Local	high
329149	SUSE SLED15 / SLES15 : Security update for the Linux Kernel (SUSE-SU-2026:3166-1)	Nessus	SuSE Local Security Checks	Local	medium
313525	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-1693)	Nessus	Amazon Linux Local Security Checks	Local	high
312641	Linux Distros Unpatched Vulnerability : CVE-2026-43118	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-43118

medium

Tenable Plugins

medium

medium

medium

medium

high

medium

high

medium