linux-kernel - [v3.8] [v3.9] [v3.10] [Regression] efi: be more paranoid about available space when creating variables

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

Message-ID: <51A8F32D.90401@canonical.com>
Date:	Fri, 31 May 2013 14:59:57 -0400
From:	Joseph Salisbury <joseph.salisbury@...onical.com>
To:	matthew.garrett@...ula.com
CC:	matt.fleming@...el.com, Thomas Gleixner <tglx@...utronix.de>,
	mingo@...hat.com, hpa@...or.com, x86@...nel.org,
	linux-efi@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: [v3.8] [v3.9] [v3.10] [Regression]  efi: be more paranoid about available
 space when creating variables

Hi Matthew,

A bug was opened that reports a regression that prevents a system from
booting[0].  After a kernel bisect, it was found that reverting the
following commit resolved this bug:

commit 68d929862e29a8b52a7f2f2f86a0600423b093cd
Author: Matthew Garrett <matthew.garrett@...ula.com>
Date:   Sat Mar 2 19:40:17 2013 -0500

    efi: be more paranoid about available space when creating variables

The regression was introduced as of v3.9-rc2, but it also made it's way
into the stable trees(Commit 9f677cf in v3.8).

I see the following commit was introduced to address this issue:

commit 31ff2f20d9003e74991d135f56e503fe776c127c
Author: Matthew Garrett <matthew.garrett@...ula.com>
Date:   Mon Apr 15 13:09:47 2013 -0700

    efi: Distinguish between "remaining space" and actually used space

However, the issue still in 3.9.4, 3.10-rc3 and v3.8.13 after
backporting 31ff2f2.

I see that you are the author of this patch, so I wanted to run this by
you and see if reverting commit 68d9298 is an option.  There are several
folks reporting this, so it should be easy to collect any additional
data/information or perform testing, if needed.

Thanks,

Joe

[0] http://pad.lv/1173423
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/