linux-kernel - Re: Who is looking at CVEs to prevent them?

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4f8e6d29-a60a-47e2-bd7b-8c66bb9ee0dc@kili.mountain>
Date:   Tue, 7 Mar 2023 14:32:48 +0300
From:   Dan Carpenter <error27@...il.com>
To:     Hillf Danton <hdanton@...a.com>
Cc:     Masami Ichikawa <masami.ichikawa@...aclelinux.com>,
        cip-dev <cip-dev@...ts.cip-project.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, lwn@....net, smatch@....kernel.org
Subject: Re: Who is looking at CVEs to prevent them?

On Tue, Mar 07, 2023 at 07:00:29PM +0800, Hillf Danton wrote:
> On 7 Mar 2023 12:51:14 +0300 Dan Carpenter <error27@...il.com>
> > On Thu, Jan 19, 2023 at 09:14:53AM +0900, Masami Ichikawa wrote:
> > > CVE-2023-0210: ksmbd: check nt_len to be at least CIFS_ENCPWD_SIZE in
> > > ksmbd_decode_ntlmssp_auth_blob
> > > 
> > > 5.15, 6.0, and 6.1 were fixed.
> > > 
> > > Fixed status
> > > mainline: [797805d81baa814f76cf7bdab35f86408a79d707]
> > > stable/5.15: [e32f867b37da7902685c9a106bef819506aa1a92]
> > > stable/6.0: [1e7ed525c60d8d51daf2700777071cd0dfb6f807]
> > > stable/6.1: [5e7d97dbae25ab4cb0ac1b1b98aebc4915689a86]
> > 
> > Sorry, I have kind of hijacked the cip-dev email list...  I use these
> > lists to figure out where we are failing.
> > 
> > I created a static checker warning for this bug.  I also wrote a blog
> > stepping through the process:
> > https://staticthinking.wordpress.com/2023/03/07/triaging-security-bugs/
> > 
> > If anyone wants to review the warnings, just email me and I can send
> > them to you.  I Cc'd LWN because I was going to post the warnings but I
> > chickened out because that didn't feel like responsible disclosure. The
> 
> Given the syzbot reports only in the past three years for instance, the
> chickenout sounds a bit over reaction.

Yeah.  Really just posting the code and the results seems like the best
way forward to me too.  That's how syzbot does it and it's the only
realistic way forward.

The good thing is that static checker warnings are much easier to
analyse than syzbot warnings.

> 
> > instructions for how to find these yourself are kind of right there in
> > the blog so it's not too hard to generate these results yourself...  I
> > don't really have enough time to review static checker warnings anymore
> > but I don't know who wants to do that job now.
> 
> If no more than three warnings you will post a week after filtering, feel
> free to add me to your Cc list, better with the leading [triage smatch
> warning] on the subject line the same way as the syzbot report.

I've sent you the complete list just so you can see what there is.
I want to get out of the filtering business as much as possible.  I want
more people involved at all stages really.  Writing checks.  Reviewing
warnings.

regards,
dan carpenter