All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "David Windsor" <dwindsor@gmail.com>
Cc: selinux@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH v6 bpf-next 1/4] security: introduce struct lsm_xattrs
Date: Thu, 30 Jul 2026 23:53:20 +0000	[thread overview]
Message-ID: <20260730235320.EEA951F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260730234533.1912709-2-dwindsor@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Latent buffer overflow: `struct lsm_xattrs` lacks a capacity field, and `lsm_get_xattr_slot()` increments `xattr_count` without bounds checking.
--

--- Patch [1]: [PATCH v6 bpf-next 1/4] security: introduce struct lsm_xattrs ---
commit 4d965e040bf3aa7aac8ca18905c2c3f09a037f96
Author: David Windsor <dwindsor@gmail.com>

security: introduce struct lsm_xattrs

This patch introduces struct lsm_xattrs to consolidate the LSM xattr array
and its count into a single context object. This preparation allows better
compatibility with the BPF verifier for a planned kfunc that lets BPF LSM
programs atomically label new inodes.

> diff --git a/include/linux/security.h b/include/linux/security.h
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
[ ... ]
> @@ -68,6 +68,11 @@ struct watch;
>  struct watch_notification;
>  struct lsm_ctx;
>  
> +struct lsm_xattrs {
> +	struct xattr *xattrs;
> +	unsigned int xattr_count;
> +};
> +

[Severity: Medium]
Should this struct also track the maximum capacity of the array?

Since this object is being introduced to allow dynamically loaded BPF LSM
programs to label new inodes, a BPF program calling the planned kfunc
multiple times could potentially exceed the allocated capacity. Tracking
the max capacity would allow for bounds checking.

>  /* Default (no) options for the capable function */
>  #define CAP_OPT_NONE 0x0
[ ... ]
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
[ ... ]
> -static inline struct xattr *lsm_get_xattr_slot(struct xattr *xattrs,
> -					       int *xattr_count)
> +static inline struct xattr *lsm_get_xattr_slot(struct lsm_xattrs *ctx)
>  {
> -	if (unlikely(!xattrs))
> +	if (unlikely(!ctx || !ctx->xattrs))
>  		return NULL;
> -	return &xattrs[(*xattr_count)++];
> +	return &ctx->xattrs[ctx->xattr_count++];
>  }

[Severity: Medium]
Does this increment need a bounds check against the array capacity?

If a dynamic BPF LSM program requests more slots than were allocated in
security_inode_init_security() (via blob_sizes.lbs_xattr_count + 1), this
would result in an out-of-bounds write to the array.

This could subsequently lead to memory corruption during the cleanup loop
that calls kfree() on the array elements.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730234533.1912709-1-dwindsor@gmail.com?part=1

  reply	other threads:[~2026-07-30 23:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30 23:45 [PATCH v6 bpf-next 0/4] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling David Windsor
2026-07-30 23:45 ` [PATCH v6 bpf-next 1/4] security: introduce struct lsm_xattrs David Windsor
2026-07-30 23:53   ` sashiko-bot [this message]
2026-07-30 23:45 ` [PATCH v6 bpf-next 2/4] security: add security_lsmxattr_add() David Windsor
2026-07-31  0:00   ` sashiko-bot
2026-07-31  0:30     ` David Windsor
2026-07-30 23:45 ` [PATCH v6 bpf-next 3/4] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling David Windsor
2026-07-30 23:53   ` Paul Moore
2026-07-31  0:01     ` David Windsor
2026-07-31  0:04   ` sashiko-bot
2026-07-30 23:45 ` [PATCH v6 bpf-next 4/4] selftests/bpf: add tests for bpf_init_inode_xattr kfunc David Windsor
2026-07-30 23:55   ` sashiko-bot

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=20260730235320.EEA951F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dwindsor@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=selinux@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 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.