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> <CALQpDLc4+-0st-U_s+09QCb2nmv=nQizheGXjhyKJLGS45zmZw@mail.gmail.com>
 <Y7A9ssF/WPVDMUKl@kroah.com>
In-Reply-To: <Y7A9ssF/WPVDMUKl@kroah.com>
From:   Yoochan Lee <yoochan1026@gmail.com>
Date:   Sun, 1 Jan 2023 10:19:14 +0900
Message-ID: <CALQpDLdqW9UYfk_3AKXk-yiCtUize=HXDTM6h-nurH31j9FN8A@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

> And how can this device actually be removed from the system?  Is that
> possible with this hardware?
HP ILO device is connected by using LAN cable.
Therefore, the detach function is triggered when the attacker
physically detaches the LAN cable connected to the HP ILO device.

> And again, this is not the correct solution as you have way too many
> reference counts happening here.  Please become more familiar with how
> these all work before adding another one and causing more problems like
> this patch did :(
Okay, I'll find a better way to patch this bug.

Sincerely,
Yoochan

2022=EB=85=84 12=EC=9B=94 31=EC=9D=BC (=ED=86=A0) =EC=98=A4=ED=9B=84 10:48,=
 Greg KH <gregkh@linuxfoundation.org>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1:
>
> A: http://en.wikipedia.org/wiki/Top_post
> Q: Were do I find info about this thing called top-posting?
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> A: No.
> Q: Should I include quotations after my reply?
>
> http://daringfireball.net/2007/07/on_top
>
> On Sat, Dec 31, 2022 at 10:06:19PM +0900, Yoochan Lee wrote:
> > Thanks.
> >
> > Since I don't have a real device, it is difficult to verify the bug dyn=
amically.
> > 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.
>
> And how can this device actually be removed from the system?  Is that
> possible with this hardware?
>
> > 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.
>
> And again, this is not the correct solution as you have way too many
> reference counts happening here.  Please become more familiar with how
> these all work before adding another one and causing more problems like
> this patch did :(
>
> > The tool I am making is currently under development, and it can find
> > the race condition between detach function and fops.
>
> Then you MUST document this as it looks like your tool needs work.
> Please read Documentation/process/researcher-guidelines.rst for what you
> MUST do if you use a tool to find "issues" and send out random patches.
>
> good luck!
>
> greg k-h