From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 973A229CA for ; Wed, 21 Apr 2021 21:03:11 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C8C0EB005; Wed, 21 Apr 2021 21:03:09 +0000 (UTC) Date: Wed, 21 Apr 2021 23:03:09 +0200 (CEST) From: Jiri Kosina To: Julia Lawall cc: Steven Rostedt , Stephen Hemminger , Roland Dreier , James Bottomley , ksummit@lists.linux.dev Subject: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches In-Reply-To: Message-ID: References: <20210421152209.68075314@gandalf.local.home> <20210421132824.13a70f6c@hermes.local> <20210421164519.4aa271b9@gandalf.local.home> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 21 Apr 2021, Julia Lawall wrote: > > > The apology states that they didn't detect any vulnerabilities. They > > > found three non exploitable bugs and submitted incorrect patches for them. > > > When the patches received some positive feedback, they explained that the > > > patches were incorrect and provided a proper fix. > > > > > > So they damaged trust, but not actually the Linux kernel... > > > > That's what they stated, but did any patch that they knew was incorrect > > actually make it into the kernel? If so, then it's on them. > > No idea. The apology goes to great lengths to say that none did, but who > knows. There are at least two commmits referenced in the LKML thread (pci_slot_release() wild dereference and missed unlock in set_fan_div()) where new security/stability issue was introduced by the patches. Of course, under normal circumstances, noone would ever be publicly grilled about introducing such an issue in a bugfix by mistake, but this is a special case. -- Jiri Kosina SUSE Labs