Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221231055310.2040648-1-yoochan1026@gmail.com>
 <Y7AHvYfZreO/G/kT@kroah.com> <CALQpDLfMjAE9_VtMO6e_iiPrciFNbksLQT3AB3QTGwZCNf5=sA@mail.gmail.com>
 <Y7AhLWSPE+2hnZ2I@kroah.com>
In-Reply-To: <Y7AhLWSPE+2hnZ2I@kroah.com>
From:   Yoochan Lee <yoochan1026@gmail.com>
Date:   Sat, 31 Dec 2022 22:06:19 +0900
Message-ID: <CALQpDLc4+-0st-U_s+09QCb2nmv=nQizheGXjhyKJLGS45zmZw@mail.gmail.com>
Subject: Re: [PATCH] misc: hpilo: Fix use-after-free in ilo_open
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     matt.hsiao@hpe.com, arnd@arndb.de, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Thanks.

Since I don't have a real device, it is difficult to verify the bug dynamic=
ally.
However, this type of race condition (i.e., b/w remove device and
fops) is prevalently founded recently[1-3].
Therefore, I think this bug can be triggered if a real device exists.

The main reason for this race condition (i.e., b/w detach and fops) is
there is no proper lock mechanism.
I think the detach device function is delayed until the other
operations (e.g., fops) is finished.
To this end, I use kref to wait for the other operations.

The tool I am making is currently under development, and it can find
the race condition between detach function and fops.

[1] https://lore.kernel.org/lkml/20220919040701.GA302806@ubuntu/
[2] https://lore.kernel.org/lkml/20220919040457.GA302681@ubuntu/
[3] https://lore.kernel.org/lkml/20220919101825.GA313940@ubuntu/

2022=EB=85=84 12=EC=9B=94 31=EC=9D=BC (=ED=86=A0) =EC=98=A4=ED=9B=84 8:46, =
Greg KH <gregkh@linuxfoundation.org>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
>
> On Sat, Dec 31, 2022 at 07:05:36PM +0900, Yoochan Lee wrote:
> > Hi,
> >
> > I haven't tested with a physical device cause I don't have a real devic=
e.
> > I found this bug through static analysis.
>
> Then please verify that it actually is a bug and that you have fixed it
> properly.  To send patches that are broken wastes everyone's time :(
>
> Also, you did not properly describe how the static analysis happened or
> what tools reported it as is required.
>
> > This type of bug is similar to [1] and [2].
> >
> > And I'm sorry that my patch is incorrect.
> > It's my first time patching a Linux kernel myself.
>
> I suggest taking the tutorial on kernelnewbies.org and working in the
> drivers/staging/* portion of the kernel first, so that you can learn how
> this all works.  Do not dive in and assume that fixing issues that a
> random tool spits out is even correct to do.
>
> good luck!
>
> greg k-h