[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhSFOx1d_7-XnbobjZXjps_mXq3S33T_5E=PmNAeyqAsdw@mail.gmail.com>
Date: Mon, 2 May 2022 20:16:07 -0400
From: Paul Moore <paul@...l-moore.com>
To: Richard Guy Briggs <rgb@...hat.com>
Cc: Linux-Audit Mailing List <linux-audit@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
linux-fsdevel@...r.kernel.org, Eric Paris <eparis@...isplace.org>,
Steve Grubb <sgrubb@...hat.com>, Jan Kara <jack@...e.cz>
Subject: Re: [PATCH v2 1/3] fanotify: Ensure consistent variable type for response
On Thu, Apr 28, 2022 at 8:45 PM Richard Guy Briggs <rgb@...hat.com> wrote:
>
> The user space API for the response variable is __u32. This patch makes
> sure that the whole path through the kernel uses __u32 so that there is
> no sign extension or truncation of the user space response.
>
> Suggested-by: Steve Grubb <sgrubb@...hat.com>
> Link: https://lore.kernel.org/r/12617626.uLZWGnKmhe@x2
> Signed-off-by: Richard Guy Briggs <rgb@...hat.com>
> Link: https://lore.kernel.org/r/aa98a3ad00666a6fc0ce411755de4a1a60f5c0cd.1651174324.git.rgb@redhat.com
> ---
> fs/notify/fanotify/fanotify.h | 2 +-
> fs/notify/fanotify/fanotify_user.c | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
It seems like audit_fanotify()/__audit_fanotify() should also be
changed, yes? Granted, in this case it's an unsigned int to u32
conversion so not really all that critical, but if you are going to
update the fanotify code you might as well update the audit code as
well for the sake of completeness.
--
paul-moore.com
Powered by blists - more mailing lists