linux-hardening - Re: [PATCH] pstore: fix ftrace dump, when ECC is enabled

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

Message-ID: <e3a5b0dd-4119-2b92-a70f-89c3e91a2533@igalia.com>
Date: Wed, 18 Feb 2026 16:42:48 -0300
From: "Guilherme G. Piccoli" <gpiccoli@...lia.com>
To: Andrey Skvortsov <andrej.skvortzov@...il.com>
Cc: Kees Cook <kees@...nel.org>, Mark Rutland <mark.rutland@....com>,
 Masami Hiramatsu <mhiramat@...nel.org>, Steven Rostedt
 <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
 linux-hardening@...r.kernel.org, Tony Luck <tony.luck@...el.com>,
 linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH] pstore: fix ftrace dump, when ECC is enabled

On 15/02/2026 15:51, Andrey Skvortsov wrote:
> total_size is sum of record->size and record->ecc_notice_size (ECC: No
> errors detected). When ECC is not used, then there is no problem.
> When ECC is enabled, then ftrace dump is decoded incorrectly after
> restart.
> 
> First this affects starting offset calculation, that breaks
> reading of all ftrace records.
> 
>   CPU:66 ts:51646260179894273 3818ffff80008002  fe00ffff800080f0  0x3818ffff80008002 <- 0xfe00ffff800080f0
>   CPU:66 ts:56589664458375169 3818ffff80008002  ff02ffff800080f0  0x3818ffff80008002 <- 0xff02ffff800080f0
>   CPU:67 ts:13194139533313 afe4ffff80008002  1ffff800080f0  0xafe4ffff80008002 <- 0x1ffff800080f0
>   CPU:67 ts:13194139533313 b7d0ffff80008001  100ffff80008002  0xb7d0ffff80008001 <- 0x100ffff80008002
>   CPU:67 ts:51646260179894273 8de0ffff80008001  202ffff80008002  0x8de0ffff80008001 <- 0x202ffff80008002
> 
> Second ECC notice message is printed like ftrace record and as a
> result couple of last records are completely wrong.
> 
> For example, when the starting offset is fixed:
> 
>  CPU:0 ts:113 ffffffc00879bd04  ffffffc0080dc08c  cpuidle_enter <- do_idle+0x20c/0x290
>  CPU:0 ts:114 ffffffc00879bd04  ffffffc0080dc08c  cpuidle_enter <- do_idle+0x20c/0x290
>  CPU:100 ts:28259048229270629 6f4e203a4343450a  2073726f72726520  0x6f4e203a4343450a <- 0x2073726f72726520
> 
> Signed-off-by: Andrey Skvortsov <andrej.skvortzov@...il.com>


Thanks for noticing that!

I've managed to reproduce it here and your patch indeed fixes the issue
- I've tested on 6.19 with ramoops.

Feel free to add my:
Tested-by: Guilherme G. Piccoli <gpiccoli@...lia.com>

Cheers,


Guilherme