linux-kernel - Re: data-race in set_console / vt

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] [day] [month] [year] [list]

Message-ID: <CALbthtfJ66kB9cfthCAML6NmGnV9N0VmnObcZy=XePza+8A-ew@mail.gmail.com>
Date:   Mon, 22 Aug 2022 16:57:22 -0400
From:   Gabriel Ryan <gabe@...columbia.edu>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     jirislaby@...nel.org, linux-kernel@...r.kernel.org,
        bjohannesmeyer@...il.com, jakobkoschel@...il.com,
        xiam0nd.tong@...il.com
Subject: Re: data-race in set_console / vt_ioctl

Hi Greg,

I want to apologize for not responding to you and the developers who
wrote back regarding our reports earlier. Moving forward, we'll
respond to all developers promptly and follow the researcher
guidelines for reporting bugs, including submitting patches and
sending reports in plaintext.

Best,

Gabe




On Sun, Aug 21, 2022 at 4:46 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Fri, Aug 19, 2022 at 09:06:27AM +0200, Greg KH wrote:
> > On Thu, Aug 18, 2022 at 09:17:00PM -0400, Abhishek Shah wrote:
> > > Hi all,
> > >
> > > We found a data race involving the *vt_dont_switch* variable. Upon further
> > > investigation, we see that this racing variable controls whether the
> > > callbacks will be scheduled in the console (see here
> > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__elixir.bootlin.com_linux_v5.18-2Drc5_source_drivers_tty_vt_vt.c-23L3032&d=DwIBAg&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=EyAJYRJu01oaAhhVVY3o8zKgZvacDAXd_PNRtaqACCo&m=Hh6zVRwx03sES-_rP4nbiMMLKzf33Fyrl7-aPu_mxJ4swlpUvEkjtoZRlyp30wJ4&s=5y1FdmpojkxZev__sRBMbryhzfGe1AApYJ3AFOy34HE&e=  >),
> > > but we are not sure of its security implications. Please let us know what
> > > you think.
> >
> > Again, any patch that you might have to resolve this would be great, as
> > that's the easiest thing to review.
>
> Given the your lack of responses to the developer's responding to your
> emails, and the fact that all of your original emails were sent in html
> format which was rejected by the public mailing lists so no one else
> could see them, I'm going to just drop all of these reports as being
> something pretty useless.
>
> If you wish to submit future reports, please read the
> Documentation/process/researcher-guidelines.rst file on how to do this
> properly in a way that will be useful, and be sure to actually respond
> to developers who take the time to write back to your reports.
>
> This is not a one-way process.
>
> thanks,
>
> greg k-h