segmentation fault when stepping multi-threaded application

[Christophe Leroy]

Le 30/04/2025 à 15:18, Tomas Alvarez Vanoli a écrit :
> [Vous ne recevez pas souvent de courriers de tomas.alvarez-vanoli at hitachienergy.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
> 
>> Am I missing something ?
> 
> Apologies for that, I made a mistake. The board is based off T1040, with e5500.
> Previous report affected two of our products, the one from the previous report and the one I am reporting now.
> 
> Since I wrote the email I was able to also reproduce a crash when stepping 3 times and then continuing, but in that case the problematic address always comes from r2.

Is it only when using gdbserver, or does it also happen when using gdb 
directly on the board ?

Christophe

> 
> Tomas Alvarez Vanoli
> R&D Embedded Software Developer
> -----Original Message-----
> From: Christophe Leroy <christophe.leroy at csgroup.eu>
> Sent: Wednesday, 30 April 2025 14:52
> To: Tomas Alvarez Vanoli <tomas.alvarez-vanoli at hitachienergy.com>; linuxppc-dev at lists.ozlabs.org
> Subject: Re: segmentation fault when stepping multi-threaded application
> 
> [You don't often get email from christophe.leroy at csgroup.eu. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Warning
> 
> This email comes from outside of Hitachi Energy. Make sure you verify the sender before clicking any links or downloading/opening attachments.
> If this email looks suspicious, report it by clicking 'Report Phishing' button in Outlook.
> See the SecureWay group in Yammer for more security information.
> 
> Le 28/04/2025 à 13:16, Tomas Alvarez Vanoli a écrit :
>> [Vous ne recevez pas souvent de courriers de
>> tomas.alvarez-vanoli at hitachienergy.com. Découvrez pourquoi ceci est
>> important à https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Hello, I am writing because I have a segmentation fault when remote-debugging a PPC 32-bit target with gdbserver.
>> This is the same platform described in
>> 'https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flor%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C2df4f9b0c64549c4a53008dd87e9762b%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638816158963370369%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iVjUSjuMm9L%2FAax1TKElszuYIQzZWteTG1Dt02xcIow%3D&reserved=0
>> e.kernel.org%2Flinuxppc-dev%2Fdc38afe9-6b78-f3f5-666b-986939e40fc6%40k
>> eymile.com%2F&data=05%7C02%7Ctomas.alvarez-vanoli%40hitachienergy.com%
>> 7Cd48fefc550ab4077b24508dd87e5be03%7C7831e6d9dc6c4cd19ec61dc2b4133195%
>> 7C0%7C0%7C638816142997141092%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
>> nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
>> 3D%3D%7C60000%7C%7C%7C&sdata=InfI5W80oeLQMPkx9yc8zDgYvGdazTUUW5hwP8%2B
>> o6UM%3D&reserved=0', although the bug does not seem to be the same and
>> the position of the thread struct does not affect it.
>>
>> The segmentation fault message is the following:
>>
>> tomcli[135]: User access of kernel address (dffbdf10) - exploit
>> attempt? (uid: 0)
>>
>>
>> gdbserver is sometimes unresponsive, although sometimes I am able to kill it with CTRL+C.
>> The code I use to reproduce this (tomcli) is the same as my colleague sent back in 2016:
>>
>>
>>
>> This can be reproduced always by starting the debug session, stepping 5 times and then issuing a continue.
>> Sometimes just a continue will do.
>> This error is also happening sporadically when running our main application under gdbserver, we get a segmentation fault in dl_fixup.
>> It never happens during normal runtime.
>>
>> The address that the kernel complains about is coming from pt_regs->gpr[3]. This value is put in the register in a call to PTRACE_SINGLESTEP (value 9).
>>
>> I poked around the ptrace code a bit, seeing if there were any possible overflows but I could not find anything, so maybe I'm barking up the wrong tree, although it does seem to be related to ptrace.
>>
>> I also added a dump_stack before the "exploit attempt" message:
>>
>> CPU: 3 PID: 135 Comm: tomcli Not tainted
>> 6.1.133-00564-g0c302b26a2c4-dirty #0 Hardware name: name,prodname
>> e5500 0x80241021 CoreNet Generic
> 
> In the begining you say it is the same platform as the other report.
> When I follow the link I understand that platform is a 83xx.
> 
> Here it is a e5500.
> 
> Am I missing something ?
> 
> Christophe
>