* 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") @ 2019-06-03 22:38 Zubin Mithra 2019-06-04 7:38 ` Ard Biesheuvel 2019-06-04 12:34 ` Greg KH 0 siblings, 2 replies; 11+ messages in thread From: Zubin Mithra @ 2019-06-03 22:38 UTC (permalink / raw) To: stable Cc: gregkh, groeck, blackgod016574, ard.biesheuvel, dvhart, andy, tglx, mingo, bp Hello, CVE-2019-12380 was fixed in the upstream linux kernel with the commit :- * 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") Could the patch be applied in order to v4.19.y? Tests run: * Chrome OS tryjob Thanks, - Zubin ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") 2019-06-03 22:38 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") Zubin Mithra @ 2019-06-04 7:38 ` Ard Biesheuvel 2019-06-04 7:46 ` Greg Kroah-Hartman 2019-06-04 12:34 ` Greg KH 1 sibling, 1 reply; 11+ messages in thread From: Ard Biesheuvel @ 2019-06-04 7:38 UTC (permalink / raw) To: Zubin Mithra Cc: stable, Greg Kroah-Hartman, groeck, Gen Zhang, Darren Hart, Andy Shevchenko, Thomas Gleixner, Ingo Molnar, Borislav Petkov On Tue, 4 Jun 2019 at 00:38, Zubin Mithra <zsm@chromium.org> wrote: > > Hello, > > CVE-2019-12380 was fixed in the upstream linux kernel with the commit :- > * 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") > > Could the patch be applied in order to v4.19.y? > > Tests run: > * Chrome OS tryjob > Unless I am missing something, it seems to me that there is some inflation going on when it comes to CVE number assignments. The code in question only affects systems that are explicitly booted with efi=old_map, and the memory allocation occurs so early during the boot sequence that even if we fail and handle it gracefully, it is highly unlikely that we can get to a point where the system is usable at all. Does Chrome OS boot in EFI mode? Does it use efi=old_map? Is the kernel built with 5 level paging enabled? Did you run it on 5 level paging hardware? Or is this just a tick the box exercise? Also, I am annoyed (does it show? :-)) that nobody mentioned the CVE at any point when the patch was under review (not even privately) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") 2019-06-04 7:38 ` Ard Biesheuvel @ 2019-06-04 7:46 ` Greg Kroah-Hartman 2019-06-04 8:52 ` Guenter Roeck 0 siblings, 1 reply; 11+ messages in thread From: Greg Kroah-Hartman @ 2019-06-04 7:46 UTC (permalink / raw) To: Ard Biesheuvel Cc: Zubin Mithra, stable, groeck, Gen Zhang, Darren Hart, Andy Shevchenko, Thomas Gleixner, Ingo Molnar, Borislav Petkov On Tue, Jun 04, 2019 at 09:38:27AM +0200, Ard Biesheuvel wrote: > On Tue, 4 Jun 2019 at 00:38, Zubin Mithra <zsm@chromium.org> wrote: > > > > Hello, > > > > CVE-2019-12380 was fixed in the upstream linux kernel with the commit :- > > * 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") > > > > Could the patch be applied in order to v4.19.y? > > > > Tests run: > > * Chrome OS tryjob > > > > Unless I am missing something, it seems to me that there is some > inflation going on when it comes to CVE number assignments. > > The code in question only affects systems that are explicitly booted > with efi=old_map, and the memory allocation occurs so early during the > boot sequence that even if we fail and handle it gracefully, it is > highly unlikely that we can get to a point where the system is usable > at all. > > Does Chrome OS boot in EFI mode? Does it use efi=old_map? Is the > kernel built with 5 level paging enabled? Did you run it on 5 level > paging hardware? > > Or is this just a tick the box exercise? > > Also, I am annoyed (does it show? :-)) that nobody mentioned the CVE > at any point when the patch was under review (not even privately) CVEs are almost always asked for _after_ the patch is merged, as the average fix-to-CVE request timeframe is -100 days. Also, for the kernel, CVEs almost mean nothing, so if this really isn't an issue, I'll not backport this. And I really doubt that any chromeos device has 5 level page tables just yet :) thanks, greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") 2019-06-04 7:46 ` Greg Kroah-Hartman @ 2019-06-04 8:52 ` Guenter Roeck 2019-06-04 9:03 ` Ard Biesheuvel 2019-06-04 9:09 ` Greg Kroah-Hartman 0 siblings, 2 replies; 11+ messages in thread From: Guenter Roeck @ 2019-06-04 8:52 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Ard Biesheuvel, Zubin Mithra, stable, Guenter Roeck, Gen Zhang, Darren Hart, Andy Shevchenko, Thomas Gleixner, Ingo Molnar, Borislav Petkov On Tue, Jun 4, 2019 at 12:46 AM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Tue, Jun 04, 2019 at 09:38:27AM +0200, Ard Biesheuvel wrote: > > On Tue, 4 Jun 2019 at 00:38, Zubin Mithra <zsm@chromium.org> wrote: > > > > > > Hello, > > > > > > CVE-2019-12380 was fixed in the upstream linux kernel with the commit :- > > > * 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") > > > > > > Could the patch be applied in order to v4.19.y? > > > > > > Tests run: > > > * Chrome OS tryjob > > > > > > > Unless I am missing something, it seems to me that there is some > > inflation going on when it comes to CVE number assignments. > > > > The code in question only affects systems that are explicitly booted > > with efi=old_map, and the memory allocation occurs so early during the > > boot sequence that even if we fail and handle it gracefully, it is > > highly unlikely that we can get to a point where the system is usable > > at all. > > > > Does Chrome OS boot in EFI mode? Does it use efi=old_map? Is the > > kernel built with 5 level paging enabled? Did you run it on 5 level > > paging hardware? > > > > Or is this just a tick the box exercise? > > > > Also, I am annoyed (does it show? :-)) that nobody mentioned the CVE > > at any point when the patch was under review (not even privately) > > CVEs are almost always asked for _after_ the patch is merged, as the > average fix-to-CVE request timeframe is -100 days. > > Also, for the kernel, CVEs almost mean nothing, so if this really isn't > an issue, I'll not backport this. > > And I really doubt that any chromeos device has 5 level page tables just > yet :) > FWIW, Chrome OS kernels are not only used in Chromebooks nowadays. They are also used in VM images in systems with hundreds of GB of memory. At least some of those may well boot in EFI mode. Plus, as also mentioned, we do not (and will not) double-guess CVEs. If anyone has an issue with CVE creation, I would suggest to discuss with the respective bodies, not with us. Zubin, as mentioned before, please hold back on -stable backport requests for CVE fixes. Please apply CVE fixes to our branches directly instead, per the above guidance ("for the kernel, CVEs almost mean nothing"). I'll revise our policy accordingly. Again, sorry for the trouble. Thanks, Guenter > thanks, > > greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") 2019-06-04 8:52 ` Guenter Roeck @ 2019-06-04 9:03 ` Ard Biesheuvel 2019-06-04 9:09 ` Greg Kroah-Hartman 1 sibling, 0 replies; 11+ messages in thread From: Ard Biesheuvel @ 2019-06-04 9:03 UTC (permalink / raw) To: Guenter Roeck Cc: Greg Kroah-Hartman, Zubin Mithra, stable, Guenter Roeck, Gen Zhang, Darren Hart, Andy Shevchenko, Thomas Gleixner, Ingo Molnar, Borislav Petkov On Tue, 4 Jun 2019 at 10:52, Guenter Roeck <groeck@google.com> wrote: > > On Tue, Jun 4, 2019 at 12:46 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > On Tue, Jun 04, 2019 at 09:38:27AM +0200, Ard Biesheuvel wrote: > > > On Tue, 4 Jun 2019 at 00:38, Zubin Mithra <zsm@chromium.org> wrote: > > > > > > > > Hello, > > > > > > > > CVE-2019-12380 was fixed in the upstream linux kernel with the commit :- > > > > * 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") > > > > > > > > Could the patch be applied in order to v4.19.y? > > > > > > > > Tests run: > > > > * Chrome OS tryjob > > > > > > > > > > Unless I am missing something, it seems to me that there is some > > > inflation going on when it comes to CVE number assignments. > > > > > > The code in question only affects systems that are explicitly booted > > > with efi=old_map, and the memory allocation occurs so early during the > > > boot sequence that even if we fail and handle it gracefully, it is > > > highly unlikely that we can get to a point where the system is usable > > > at all. > > > > > > Does Chrome OS boot in EFI mode? Does it use efi=old_map? Is the > > > kernel built with 5 level paging enabled? Did you run it on 5 level > > > paging hardware? > > > > > > Or is this just a tick the box exercise? > > > > > > Also, I am annoyed (does it show? :-)) that nobody mentioned the CVE > > > at any point when the patch was under review (not even privately) > > > > CVEs are almost always asked for _after_ the patch is merged, as the > > average fix-to-CVE request timeframe is -100 days. > > > > Also, for the kernel, CVEs almost mean nothing, so if this really isn't > > an issue, I'll not backport this. > > > > And I really doubt that any chromeos device has 5 level page tables just > > yet :) > > > > FWIW, Chrome OS kernels are not only used in Chromebooks nowadays. > They are also used in VM images in systems with hundreds of GB of > memory. At least some of those may well boot in EFI mode. Yes, but why would you boot those with efi=old_map, which is an option that is only there for compatibility with old and non-standard EFI implementations. > Plus, as > also mentioned, we do not (and will not) double-guess CVEs. If anyone > has an issue with CVE creation, I would suggest to discuss with the > respective bodies, not with us. > Fair enough. > Zubin, as mentioned before, please hold back on -stable backport > requests for CVE fixes. Please apply CVE fixes to our branches > directly instead, per the above guidance ("for the kernel, CVEs almost > mean nothing"). I'll revise our policy accordingly. Again, sorry for > the trouble. > No trouble at all, and apologies for the grumpy tone. In this particular case, the CVE is highly dubious (imo), since not every bug is a vulnerability, and this bug is very difficult to hit even on systems which make use of efi=old_map. While that also reduces the risk of regressions, pulling this bug into a stable release requires justification, and sadly, given the apparent policy issues with assigning CVE numbers, the fact that the patch addresses a CVE is not sufficient. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") 2019-06-04 8:52 ` Guenter Roeck 2019-06-04 9:03 ` Ard Biesheuvel @ 2019-06-04 9:09 ` Greg Kroah-Hartman 1 sibling, 0 replies; 11+ messages in thread From: Greg Kroah-Hartman @ 2019-06-04 9:09 UTC (permalink / raw) To: Guenter Roeck Cc: Ard Biesheuvel, Zubin Mithra, stable, Guenter Roeck, Gen Zhang, Darren Hart, Andy Shevchenko, Thomas Gleixner, Ingo Molnar, Borislav Petkov On Tue, Jun 04, 2019 at 01:52:06AM -0700, Guenter Roeck wrote: > On Tue, Jun 4, 2019 at 12:46 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > On Tue, Jun 04, 2019 at 09:38:27AM +0200, Ard Biesheuvel wrote: > > > On Tue, 4 Jun 2019 at 00:38, Zubin Mithra <zsm@chromium.org> wrote: > > > > > > > > Hello, > > > > > > > > CVE-2019-12380 was fixed in the upstream linux kernel with the commit :- > > > > * 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") > > > > > > > > Could the patch be applied in order to v4.19.y? > > > > > > > > Tests run: > > > > * Chrome OS tryjob > > > > > > > > > > Unless I am missing something, it seems to me that there is some > > > inflation going on when it comes to CVE number assignments. > > > > > > The code in question only affects systems that are explicitly booted > > > with efi=old_map, and the memory allocation occurs so early during the > > > boot sequence that even if we fail and handle it gracefully, it is > > > highly unlikely that we can get to a point where the system is usable > > > at all. > > > > > > Does Chrome OS boot in EFI mode? Does it use efi=old_map? Is the > > > kernel built with 5 level paging enabled? Did you run it on 5 level > > > paging hardware? > > > > > > Or is this just a tick the box exercise? > > > > > > Also, I am annoyed (does it show? :-)) that nobody mentioned the CVE > > > at any point when the patch was under review (not even privately) > > > > CVEs are almost always asked for _after_ the patch is merged, as the > > average fix-to-CVE request timeframe is -100 days. > > > > Also, for the kernel, CVEs almost mean nothing, so if this really isn't > > an issue, I'll not backport this. > > > > And I really doubt that any chromeos device has 5 level page tables just > > yet :) > > > > FWIW, Chrome OS kernels are not only used in Chromebooks nowadays. > They are also used in VM images in systems with hundreds of GB of > memory. At least some of those may well boot in EFI mode. Plus, as > also mentioned, we do not (and will not) double-guess CVEs. If anyone > has an issue with CVE creation, I would suggest to discuss with the > respective bodies, not with us. I have discussed it with the respective bodies and they agree that the CVEs for kernel issues are a total joke. The only way it can "be fixed" is to burn it all down and create something new. Some of us have some plans for doing that, but it's on the back-burner due to "real world" work to get done at this moment. Again, like I said in the other email, treat CVE tags as a flag that you might want to look at the patch. But not as a "this must be applied!" type of rule at all. If this fix is needed for your systems, great, I'll be glad to queue it up, Ard was just asking for confirmation about this resolving a real issue for you or not. > Zubin, as mentioned before, please hold back on -stable backport > requests for CVE fixes. Please apply CVE fixes to our branches > directly instead, per the above guidance ("for the kernel, CVEs almost > mean nothing"). I'll revise our policy accordingly. Again, sorry for > the trouble. Again, don't take your toys and go away. The backport requests you all have been asking for are great, and hopefully saves you time in the end by having the fix upstream and re-reviewed by everyone. It also benifits all of the non-Chromeos systems in the world, of which I know Google relies on a lot of them, so you are doing work that the rest of your company appreciates. If someone asks "does this really resolve an issue for you", answer the reasonable question :) thanks, greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") 2019-06-03 22:38 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") Zubin Mithra 2019-06-04 7:38 ` Ard Biesheuvel @ 2019-06-04 12:34 ` Greg KH 2019-06-04 13:39 ` Ard Biesheuvel 1 sibling, 1 reply; 11+ messages in thread From: Greg KH @ 2019-06-04 12:34 UTC (permalink / raw) To: Zubin Mithra Cc: stable, groeck, blackgod016574, ard.biesheuvel, dvhart, andy, tglx, mingo, bp On Mon, Jun 03, 2019 at 03:38:52PM -0700, Zubin Mithra wrote: > Hello, > > CVE-2019-12380 was fixed in the upstream linux kernel with the commit :- > * 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") > > Could the patch be applied in order to v4.19.y? Now queued up, thanks. greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") 2019-06-04 12:34 ` Greg KH @ 2019-06-04 13:39 ` Ard Biesheuvel 2019-06-04 13:45 ` Greg KH 2019-06-04 16:38 ` Zubin Mithra 0 siblings, 2 replies; 11+ messages in thread From: Ard Biesheuvel @ 2019-06-04 13:39 UTC (permalink / raw) To: Greg KH Cc: Zubin Mithra, stable, Guenter Roeck, Gen Zhang, Darren Hart, Andy Shevchenko, Thomas Gleixner, Ingo Molnar, Borislav Petkov On Tue, 4 Jun 2019 at 14:34, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Mon, Jun 03, 2019 at 03:38:52PM -0700, Zubin Mithra wrote: > > Hello, > > > > CVE-2019-12380 was fixed in the upstream linux kernel with the commit :- > > * 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") > > > > Could the patch be applied in order to v4.19.y? > > Now queued up, thanks. > Given the discussion leading up to this, I'm slightly surprised. As I alluded to in my questions to Zubin, I am concerned that the testing carried out on this patch has too little coverage, given that a) Chrome OS apparently does not boot in EFI mode b) therefore, Chrome OS there does not use efi=old_map c) Chrome OS hardware does not implement 5 level paging I have done all the testing I could before merging the patch, but I would prefer to defer from backporting it until it hits a release. I know some people argue that this still does not provide sufficient coverage, but those are usually not the same people getting emails when their EFI systems no longer boot without any output whatsoever after upgrading from one stable kernel version to the next. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") 2019-06-04 13:39 ` Ard Biesheuvel @ 2019-06-04 13:45 ` Greg KH 2019-06-04 13:47 ` Ard Biesheuvel 2019-06-04 16:38 ` Zubin Mithra 1 sibling, 1 reply; 11+ messages in thread From: Greg KH @ 2019-06-04 13:45 UTC (permalink / raw) To: Ard Biesheuvel Cc: Zubin Mithra, stable, Guenter Roeck, Gen Zhang, Darren Hart, Andy Shevchenko, Thomas Gleixner, Ingo Molnar, Borislav Petkov On Tue, Jun 04, 2019 at 03:39:15PM +0200, Ard Biesheuvel wrote: > On Tue, 4 Jun 2019 at 14:34, Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Mon, Jun 03, 2019 at 03:38:52PM -0700, Zubin Mithra wrote: > > > Hello, > > > > > > CVE-2019-12380 was fixed in the upstream linux kernel with the commit :- > > > * 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") > > > > > > Could the patch be applied in order to v4.19.y? > > > > Now queued up, thanks. > > > > Given the discussion leading up to this, I'm slightly surprised. > > As I alluded to in my questions to Zubin, I am concerned that the > testing carried out on this patch has too little coverage, given that > a) Chrome OS apparently does not boot in EFI mode > b) therefore, Chrome OS there does not use efi=old_map > c) Chrome OS hardware does not implement 5 level paging > > I have done all the testing I could before merging the patch, but I > would prefer to defer from backporting it until it hits a release. I > know some people argue that this still does not provide sufficient > coverage, but those are usually not the same people getting emails > when their EFI systems no longer boot without any output whatsoever > after upgrading from one stable kernel version to the next. Ok, I'll go drop it. Can you please email stable@vger when it is in a release so that I know to queue it up then? thanks, greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") 2019-06-04 13:45 ` Greg KH @ 2019-06-04 13:47 ` Ard Biesheuvel 0 siblings, 0 replies; 11+ messages in thread From: Ard Biesheuvel @ 2019-06-04 13:47 UTC (permalink / raw) To: Greg KH Cc: Zubin Mithra, stable, Guenter Roeck, Gen Zhang, Darren Hart, Andy Shevchenko, Thomas Gleixner, Ingo Molnar, Borislav Petkov On Tue, 4 Jun 2019 at 15:46, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Tue, Jun 04, 2019 at 03:39:15PM +0200, Ard Biesheuvel wrote: > > On Tue, 4 Jun 2019 at 14:34, Greg KH <gregkh@linuxfoundation.org> wrote: > > > > > > On Mon, Jun 03, 2019 at 03:38:52PM -0700, Zubin Mithra wrote: > > > > Hello, > > > > > > > > CVE-2019-12380 was fixed in the upstream linux kernel with the commit :- > > > > * 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") > > > > > > > > Could the patch be applied in order to v4.19.y? > > > > > > Now queued up, thanks. > > > > > > > Given the discussion leading up to this, I'm slightly surprised. > > > > As I alluded to in my questions to Zubin, I am concerned that the > > testing carried out on this patch has too little coverage, given that > > a) Chrome OS apparently does not boot in EFI mode > > b) therefore, Chrome OS there does not use efi=old_map > > c) Chrome OS hardware does not implement 5 level paging > > > > I have done all the testing I could before merging the patch, but I > > would prefer to defer from backporting it until it hits a release. I > > know some people argue that this still does not provide sufficient > > coverage, but those are usually not the same people getting emails > > when their EFI systems no longer boot without any output whatsoever > > after upgrading from one stable kernel version to the next. > > Ok, I'll go drop it. Can you please email stable@vger when it is in a > release so that I know to queue it up then? > OK, thanks ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") 2019-06-04 13:39 ` Ard Biesheuvel 2019-06-04 13:45 ` Greg KH @ 2019-06-04 16:38 ` Zubin Mithra 1 sibling, 0 replies; 11+ messages in thread From: Zubin Mithra @ 2019-06-04 16:38 UTC (permalink / raw) To: Ard Biesheuvel Cc: stable, gregkh, groeck, blackgod016574, dvhart, andy, tglx, mingo, bp On Tue, Jun 04, 2019 at 03:39:15PM +0200, Ard Biesheuvel wrote: > On Tue, 4 Jun 2019 at 14:34, Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Mon, Jun 03, 2019 at 03:38:52PM -0700, Zubin Mithra wrote: > > > Hello, > > > > > > CVE-2019-12380 was fixed in the upstream linux kernel with the commit :- > > > * 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") > > > > > > Could the patch be applied in order to v4.19.y? > > > > Now queued up, thanks. > > > > Given the discussion leading up to this, I'm slightly surprised. > > As I alluded to in my questions to Zubin, I am concerned that the > testing carried out on this patch has too little coverage, given that > a) Chrome OS apparently does not boot in EFI mode > b) therefore, Chrome OS there does not use efi=old_map > c) Chrome OS hardware does not implement 5 level paging I see, yes, I have not done appropriate testing on this patch. Sorry about the mistake and the confusion! I'll keep in mind to do more appropriate testing from the next patch onwards. Thanks, - Zubin > > I have done all the testing I could before merging the patch, but I > would prefer to defer from backporting it until it hits a release. I > know some people argue that this still does not provide sufficient > coverage, but those are usually not the same people getting emails > when their EFI systems no longer boot without any output whatsoever > after upgrading from one stable kernel version to the next. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-06-04 16:38 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-03 22:38 4e78921ba4dd ("efi/x86/Add missing error handling to old_memmap 1:1 mapping code") Zubin Mithra 2019-06-04 7:38 ` Ard Biesheuvel 2019-06-04 7:46 ` Greg Kroah-Hartman 2019-06-04 8:52 ` Guenter Roeck 2019-06-04 9:03 ` Ard Biesheuvel 2019-06-04 9:09 ` Greg Kroah-Hartman 2019-06-04 12:34 ` Greg KH 2019-06-04 13:39 ` Ard Biesheuvel 2019-06-04 13:45 ` Greg KH 2019-06-04 13:47 ` Ard Biesheuvel 2019-06-04 16:38 ` Zubin Mithra
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.