Re: [PATCH] file: Call security_file_alloc() after initializing the filp

[Mateusz Guzik]

On Fri, Dec 12, 2025 at 11:01 AM tianjia.zhang
<tianjia.zhang@xxxxxxxxxxxxxxxxx> wrote:
>
>
>
> On 12/9/25 4:22 PM, Mateusz Guzik wrote:
> > On Tue, Dec 09, 2025 at 03:53:47PM +0800, Tianjia Zhang wrote:
> >> When developing a dedicated LSM module, we need to operate on the
> >> file object within the LSM function, such as retrieving the path.
> >> However, in `security_file_alloc()`, the passed-in `filp` is
> >> only a valid pointer; the content of `filp` is completely
> >> uninitialized and entirely random, which confuses the LSM function.
> >>
> >
> > I take it you have some underlying routine called by other hooks as well
> > which ends up looking at ->f_path.
> >
> > Given that f_path *is not valid* to begin with, memsetted or not, your
> > file_alloc_security hoook should not be looking at it to begin with.
> >
> > So I don't think this patch has merit.
> >
>
> The scenario is as follows: I have hooked all LSM functions and
> abstracted struct file into an object using higher-level logic. In my
> handler functions, I need to print the file path of this object for
> debugging purposes. However, doing so will cause a crash unless I
> explicitly know that handler in the file_alloc_security context—which,
> in my case, I don't.
>

Per my previous e-mail the real bug is that you are accessing a field
which at the time does not have a legitimate value.

> Of course, obtaining the path isn't strictly required; I understand that
> in certain situations—such as during initialization—there may be no
> valid path at all. Even so, it would be acceptable if I could reliably
> determine from filp->f_path that fetching the path is inappropriate. The
> problem is that, without knowing whether I'm in the file_alloc_security
> context, I have no reliable way to decide whether it's safe to attempt
> retrieving the path.

For the sake of argument let's say the patch or an equivalent went in
and you no longer crash on f_path.

The only legally populated field at the time is f_cred.

Later someone might get an idea to look at other fields and instead of
crashing get bogus results.

Or to put it differently, it's a design issue in your code. When
called from a hook where mucking with 'file' is illegal, it needs to
know to refrain from doing it.