linux-kernel - Re: [PATCH] misc: hpilo: Fix use-after-free in ilo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALQpDLc4+-0st-U_s+09QCb2nmv=nQizheGXjhyKJLGS45zmZw@mail.gmail.com>
Date:   Sat, 31 Dec 2022 22:06:19 +0900
From:   Yoochan Lee <yoochan1026@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     matt.hsiao@....com, arnd@...db.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] misc: hpilo: Fix use-after-free in ilo_open

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.

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년 12월 31일 (토) 오후 8:46, Greg KH <gregkh@...uxfoundation.org>님이 작성:
>
> 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 device.
> > 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