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: <2204439.yeF237Ovv0@aspire.rjw.lan>
Date:   Sat, 16 Dec 2017 16:54:12 +0100
From:   "Rafael J. Wysocki" <rjw@...ysocki.net>
To:     Borislav Petkov <bp@...en8.de>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Vasyl Gomonovych <gomonovych@...il.com>,
        Len Brown <lenb@...nel.org>, Tony Luck <tony.luck@...el.com>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ACPI, APEI, Fix use resource_size

On Saturday, December 16, 2017 12:56:15 PM CET Borislav Petkov wrote:
> On Sat, Dec 16, 2017 at 11:43:27AM +0100, Rafael J. Wysocki wrote:
> > The argument of resource_size() is (const struct resource *) and res
> > is of type (struct apei_res *).
> > 
> > I'm dropping this one.
> 
> Yeah, us reviewing this one was one big FAIL.

I don't know.

We didn't catch this issue, but that's what 0-day is for, isn't it? :-)

IMO it is not generally wrong to assume certain level of due diligence
on the part of submitters and that assumption is actually met most of the
time from my experience.

It sometimes isn't, but then the submitter lands in my "suspicious" list
and subsequent patches coming from them are subject to special treatment.

Which basically boils down to "Don't do that".

> And I tell myself everytime - build those patches first! Srsly! People
> really don't even build-test their shit before submitting. Because look
> at the compiler output - it is everything but quiet. Crap didn't even
> build.

Right, but at least we know that the current code isn't correct.

Thanks,
Rafael

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ