From: Paul Moore <paul@paul-moore.com>
To: 15074444048@163.com, audit@vger.kernel.org, eparis@redhat.com
Cc: 15074444048@163.com, lihaojie <lihaojie@kylinos.cn>,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2] kernel/audit: reorder the member of audit_context
Date: Thu, 05 Dec 2024 19:45:04 -0500 [thread overview]
Message-ID: <aef181673159ac72f1e7922548186fc6@paul-moore.com> (raw)
In-Reply-To: <20241205063023.744685-1-15074444048@163.com>
On Dec 5, 2024 15074444048@163.com wrote:
>
> Adjust the positions of target_ref and target_comm to
> reduce their direct proximity. This can prevent the memset
> operation on target_ref from potentially affecting target_comm
I don't really see the above as very convinving, sure by moving the
target_ref field after target_comm it is less likely that a too-long
memset() on target_ref will impact target_comm, but ...
* lsm_prop is a fixed sized struct so memset()'ing it should be
easy to verify.
* if a memset(target_ref) does go long, it still jeapordizes other
parts of the audit_context struct (see the audit_tree_refs pointers).
If we need to workaround some shortcomings of the static analysis
tooling (which compiler/tool are you using?) that's okay, and the
paragraph below is fine, but I don't believe this change really offers
much in the way of runtime protection (the first paragraph).
I'm CC'ing the linux-hardening folks as they may have some additional
insight on how to best work around static analysis limitations.
> The compiler's static analysis tool considers that the memset
> operation might affect the adjacent struct member target_comm,
> potentially causing subsequent writes to target_comm to exceed
> its boundaries. Even if an overflow does not actually occur,
> the compiler may issue a warning because it cannot fully
> determine the safety of the operation.
>
> Verification:
> - "pahole" shows no size nor member offset changes to struct audit_context.
> - "objdump -d" shows no object code changes.
>
> Signed-off-by: lihaojie <lihaojie@kylinos.cn>
> ---
> kernel/audit.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/audit.h b/kernel/audit.h
> index 0211cb307d30..77c140228a4a 100644
> --- a/kernel/audit.h
> +++ b/kernel/audit.h
> @@ -144,8 +144,8 @@ struct audit_context {
> kuid_t target_auid;
> kuid_t target_uid;
> unsigned int target_sessionid;
> - struct lsm_prop target_ref;
> char target_comm[TASK_COMM_LEN];
> + struct lsm_prop target_ref;
>
> struct audit_tree_refs *trees, *first_trees;
> struct list_head killed_trees;
> --
> 2.25.1
--
paul-moore.com
parent reply other threads:[~2024-12-06 0:45 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20241205063023.744685-1-15074444048@163.com>]
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=aef181673159ac72f1e7922548186fc6@paul-moore.com \
--to=paul@paul-moore.com \
--cc=15074444048@163.com \
--cc=audit@vger.kernel.org \
--cc=eparis@redhat.com \
--cc=lihaojie@kylinos.cn \
--cc=linux-hardening@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