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;
Date:   Tue, 3 Jan 2023 10:35:31 +0800
From:   Matt Hsiao <matt.hsiao@hpe.com>
To:     Yoochan Lee <yoochan1026@gmail.com>
Cc:     Greg KH <gregkh@linuxfoundation.org>, arnd@arndb.de,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] misc: hpilo: Fix use-after-free in ilo_open
Message-ID: <20230103023531.GA26527@blofly.tw.rdlabs.hpecorp.net>
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>
 <CALQpDLdqW9UYfk_3AKXk-yiCtUize=HXDTM6h-nurH31j9FN8A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CALQpDLdqW9UYfk_3AKXk-yiCtUize=HXDTM6h-nurH31j9FN8A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Precedence: bulk

On Sun, Jan 01, 2023 at 10:19:14AM +0900, Yoochan Lee wrote:
> > 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.

This is incorrect.

The iLO device is an SoC attached directly on the PCB board.
It cannot be removed like a PCMCIA card that you referred so the
patch cannot apply the same to iLO. This iLO SoC does have a NIC, but
detach the LAN cable connected to it does not remove the SoC itself from
the host CPU.

> 
> > 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년 12월 31일 (토) 오후 10:48, Greg KH <gregkh@linuxfoundation.org>님이 작성:
> >
> > 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 dynamically.
> > > 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