linux-kernel - Re: [PATCH] ACPI, APEI, Fix use resource

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]

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