All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx+linux-hardening@kernel.org>
To: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Cc: "Mickaël Salaün" <mic@digikod.net>,
	"Günther Noack" <gnoack@google.com>,
	"Tingmao Wang" <m@maowtm.org>,
	linux-security-module@vger.kernel.org,
	"Kees Cook" <kees@kernel.org>,
	linux-hardening@vger.kernel.org, llvm@lists.linux.dev,
	syzbot+a0eecb22de4d821a9e5d@syzkaller.appspotmail.com
Subject: Re: [PATCH] landlock: Drop __counted_by from landlock_domain.layers
Date: Sat, 10 Oct 2026 20:05:48 +0200	[thread overview]
Message-ID: <asp9mzpa4eJWvij0@debian> (raw)
In-Reply-To: <20261010164450.194439-1-ngocthang2710.1999@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2747 bytes --]

Hello Nguyen,

> Date: 2026-10-10 23:44:49+0700
> From: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
>
> With clang 22 and CONFIG_FORTIFY_SOURCE, the second
> landlock_restrict_self() call hits a bogus fortify report in
> inherit_ruleset():
> 
>   memcpy: detected buffer overflow: 16 byte read of buffer size 0
>   Call Trace:
>    __fortify_panic
>    landlock_merge_ruleset+0xc46/0xc90
>    __se_sys_landlock_restrict_self+0x2bc/0xd40
> 
> layers[] lives in an anonymous struct inside the anonymous union
> that overlays work_free.  For such a flexible array, clang computes the
> address of the __counted_by counter as the start of the array instead of
> &num_layers.  The bound is then read from layers[0], i.e. from
> the first layer's configuration, which is not a count.  The same layout
> crashes clang itself in a standalone test.
> 
> The annotation was added as documentation, so drop it rather than
> restructure the union.  Keep the information in the member comment.
> 
> Reported-by: syzbot+a0eecb22de4d821a9e5d@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=a0eecb22de4d821a9e5d
> Fixes: bd3a19800dd1 ("landlock: Add counted_by in landlock_domain")
> Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
> ---
> Reproduced with clang 22.1.8 and FORTIFY_SOURCE on mic/next (64b9e6eff524):
> the second landlock_restrict_self() hits the report, while 16 nested
> restricts run clean with this patch.  Mickaël, if you prefer to just drop
> bd3a19800dd1 from next, that works as well.

Is this reproducible with Clang 23 or later?

Should __counted_by() expand to nothing for bogus versions of Clang?
That would allow using it, and just ignore Clang when it's broken,
rather than not using safety features.


Have a lovely day!
Alex

>  security/landlock/domain.h | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/security/landlock/domain.h b/security/landlock/domain.h
> index 60e8eb2d6ac2..4bf1555a4349 100644
> --- a/security/landlock/domain.h
> +++ b/security/landlock/domain.h
> @@ -246,8 +246,12 @@ struct landlock_domain {
>  			 * properly handle merged rulesets without overlapping
>  			 * access rights.  These layers are set once and never
>  			 * changed for the lifetime of the domain.
> +			 *
> +			 * Not annotated with __counted_by(@num_layers): clang
> +			 * miscomputes the counter address for a FAM nested in an
> +			 * anonymous struct within a union, which trips FORTIFY.
>  			 */
> -			struct layer_config layers[] __counted_by(num_layers);
> +			struct layer_config layers[];
>  		};
>  	};
>  };
> -- 
> 2.43.0
> 
> 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-10-10 18:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09 17:04 [syzbot] [lsm?] WARNING in landlock_merge_ruleset syzbot
2026-10-10 16:44 ` [PATCH] landlock: Drop __counted_by from landlock_domain.layers Nguyen Ngoc Thang
2026-10-10 18:05   ` Alejandro Colomar [this message]
2026-10-10 18:46     ` Nathan Chancellor
2026-10-11  2:57       ` Nguyen Ngoc Thang
2026-10-11 13:11   ` Günther Noack
2026-10-11 14:31     ` Mickaël Salaün
2026-10-11 15:59       ` Nguyen Ngoc Thang
2026-10-11 16:16       ` Mickaël Salaün

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=asp9mzpa4eJWvij0@debian \
    --to=alx+linux-hardening@kernel.org \
    --cc=gnoack@google.com \
    --cc=kees@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=m@maowtm.org \
    --cc=mic@digikod.net \
    --cc=ngocthang2710.1999@gmail.com \
    --cc=syzbot+a0eecb22de4d821a9e5d@syzkaller.appspotmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.