linux-kernel - [ISSUE] initramfs: Failed to decompress the built-in rootfs and entered panic without log output

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:
 <BYAPR12MB3205E9E6754A56DDFF805E2ED5DB2@BYAPR12MB3205.namprd12.prod.outlook.com>
Date: Fri, 21 Mar 2025 05:50:21 +0000
From: Stephen Eta Zhou <stephen.eta.zhou@...look.com>
To: David Disseldorp <ddiss@...e.de>, John Sperbeck <jsperbeck@...gle.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "mpe@...erman.id.au"
	<mpe@...erman.id.au>, "brauner@...nel.org" <brauner@...nel.org>, Fan Wu
	<wufan@...ux.microsoft.com>, Lukas Wunner <lukas@...ner.de>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [ISSUE] initramfs: Failed to decompress the built-in rootfs and
 entered panic without log output

Hi all,

I found that if `initramfs` fails to decompress the built-in `rootfs`, it will
call `panic_show_mem` to make the kernel enter the panic state. 

`panic_show_mem` will call `panic` inside, and `panic` will call
`pr_emerg` as the log output interface.

However, since the decompression of `initramfs` is in the early stage of
kernel operation, neither `console_init` nor the serial port driver has been
successfully initialized at this time, there will be no log output.

Although `console_flush_on_panic` will be called inside `panic` to force log output,
there is no available console at this time.

`for_each_console_srcu` cannot find any valid console.

After calling `console_flush_on_panic` to refresh the log cache, panic will
immediately perform an operation that seems to be idling:
```C
for (i = 0;; i += PANIC_TIMER_STEP) {
    touch_softlockup_watchdog();

    if (i >= i_next) {
        i += panic_blink(state ^= 1);
        i_next = i + 3600 / PANIC_BLINK_SPD;
    }
    mdelay(PANIC_TIMER_STEP);
}
```
There is no exit condition in the above code. In addition, `panic` will call
`smp_send_stop` to stop the work of other core processors, which means
that if `initramfs` fails to decompress the built-in rootfs, it will fall into a
suspended state and no valid log output will be seen.

The decompression failure I currently encounter occurs when `initramfs`
decompresses the built-in `rootfs`.

The required `block` exceeds the limit of `tmpfs_max_block`,
and the error `write error` is returned.

However, when decompressing the non-built-in `rootfs`,
it did not enter `panic`, but called `printk` to print the log,
which would not interrupt the operation of the system. ()

After the `console` and serial port initialization are completed,
the error log can be seen normally.

I am wondering whether the decompression of the built-in `rootfs`
should also call `printk` instead of `panic`?

Below is my debugging environment:
board：vexpress-v2p-ca9
kernel：6.14-rc7

Has anyone encountered this issue, or is it already being addressed?

Thanks,
Stephen