mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: <shao.mingyin@zte.com.cn>
To: <richard@nod.at>
Cc: <linux-mtd@lists.infradead.org>, <chengzhihao1@huawei.com>,
	<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
Subject: [PATCH 0/3] ubifs: fix an auth node leak and two error-handling bugs
Date: Mon, 2 Nov 2026 19:50:30 +0800 (CST)	[thread overview]
Message-ID: <20261102195030814Aeehrb4WmExc085745ldN@zte.com.cn> (raw)

This series fixes three independent problems in ubifs, all found while
auditing the error paths around the GC write-buffer, xattr creation and
authenticated node hashing.

Patch 1 fixes a leak.  move_nodes() allocates the authentication node for
the GC journal head and writes it into the GC write-buffer; the buffer is
freed only when one of the steps fails.  On an authenticated file system
every GC pass that moves nodes therefore leaks ubifs_auth_node_sz()
bytes, so the loss is unbounded on a long-running system.

Patch 2 fixes state that survives a failed operation.  create_xattr()
sets UBIFS_CRYPT_FL for inodes that carry an encryption context, but its
error path clears the flag whether this call set it or not.  A setxattr()
that fails before anything reaches the journal, for example because its
journal buffer cannot be allocated, therefore leaves the in-memory inode
marked as unencrypted; the next inode write persists that, and after the
next mount the inode is no longer treated as encrypted although its names
and data still are.

Patch 3 stops five call sites from ignoring ubifs_node_calc_hash().  With
authentication enabled a failing crypto operation leaves those callers
using an uninitialised stack buffer as the node hash; it is then stored in
the TNC or in the master node, and the affected nodes fail verification
later.

The three patches are independent and can be applied in any order or as a
subset.  They are listed by severity, not by dependency: the leak first,
then the persistent state loss, then the error propagation.

All three carry Fixes: and Cc: stable.

Testing: the patches apply to next-20261030, pass checkpatch.pl --strict
with 0 errors/0 warnings/0 checks, and fs/ubifs/ builds with
CONFIG_UBIFS_FS_AUTHENTICATION, CONFIG_UBIFS_FS_XATTR and
CONFIG_UBIFS_FS_SECURITY enabled and W=1 without new warnings.  They were
not exercised at runtime: this machine has no UBI/MTD tooling or
emulation, so there is no mount test.  Patch 1 is the easiest to verify by
inspection; patch 2 needs an allocation or I/O failure in
ubifs_jnl_update(); patch 3 needs a crypto failure inside
ubifs_node_calc_hash().

Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>
---
base-commit: 7649ba73f9e7e1e04d0b46213e39c79ae09dd55c

             reply	other threads:[~2026-11-02 11:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 11:50 shao.mingyin [this message]
2026-11-02 12:12 ` [PATCH 1/3] ubifs: gc: fix authentication node leak shao.mingyin
2026-11-02 12:13 ` [PATCH 2/3] ubifs: xattr: preserve the encryption flag when creation fails shao.mingyin
2026-11-02 12:14 ` [PATCH 3/3] ubifs: check node hash calculation errors shao.mingyin
2026-11-02 13:41   ` Zhihao Cheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261102195030814Aeehrb4WmExc085745ldN@zte.com.cn \
    --to=shao.mingyin@zte.com.cn \
    --cc=chengzhihao1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®