linux-kernel - Re: [REGRESSION] Kernel booted via kexec fails to resume from hibernation

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z4ejbdJr87V3IwV8@desktop0a>
Date: Wed, 15 Jan 2025 13:00:45 +0100
From: Roberto Ricci <io@...icci.it>
To: Baoquan He <bhe@...hat.com>
Cc: ebiederm@...ssion.com, rafael@...nel.org, pavel@....cz,
	ytcoode@...il.com, kexec@...ts.infradead.org,
	linux-pm@...r.kernel.org, akpm@...ux-foundation.org,
	regressions@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] Kernel booted via kexec fails to resume from
 hibernation

On 2025-01-15 Wed 12:04:10 +0800, Baoquan He wrote:
> On 01/14/25 at 02:16pm, Roberto Ricci wrote:
> > On 2025-01-13 Mon 22:28:48 +0100, Roberto Ricci wrote:
> > > I can reproduce this with kernel 6.13-rc7 in a qemu x86_64 virtual machine
> > > running Void Linux, with the following commands:
> > > 
> > > ```
> > > # kexec -l /boot/vmlinuz-6.13.0-rc7 --initrd=/boot/initramfs-6.13.0-rc7 --reuse-cmdline
> > > # reboot
> > > # printf reboot >/sys/power/disk
> > > # printf disk >/sys/power/state
> > > ```
> > 
> > Looks like it's the kernel performing the kexec which causes the issue,
> > not the target one. E.g.: kexec-ing 6.7 from 6.13-rc7 makes resume from
> > hibernation fail; but if I kexec 6.13-rc7 from 6.7, then it works fine.
> 
> I tried the latest mainline kernel with your above command execution
> series, I didn't see the problem you reported. Can you try kexec from
> 6.7 to 6.7 or something like that and try to bisect a specific criminal
> commit?

As I mentioned in my initial report, only versions >= 6.8 are affected.
Anyway, I actually was kexec-ing the same kernel which was already booted
when I did the bisection which pointed to 18d565ea95fe.

> As for below commit, it seems not a suspect.
> 18d565ea95fe ("kexec_file: fix incorrect temp_start value in locate_mem_hole_top_down()")
> 
> If possible, can you revert below two commits altogether to have a try?
> I am not sure if they caused the problem.
> 
> 18d565ea95fe kexec_file: fix incorrect temp_start value in locate_mem_hole_top_down()
> 816d334afa85 kexec: modify the meaning of the end parameter in kimage_is_destination_range()

Reverting these two commits does not fix things on v6.13-rc7.

But I have found that reverting 18d565ea95fe fixes the issue for kernels
up to 6.11. Since 6.12 this is not enough. So I'm doing another bisection.
I will report results maybe later today.