linux-kernel - Re: Kernel panic in __migrate_swap

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

Message-ID: <6FAF1A0D-540A-4E08-B358-3335BAD36BAC@gmail.com>
Date: Thu, 19 Jun 2025 10:44:10 +0530
From: Abhigyan ghosh <zscript.team.zs@...il.com>
To: jhladky@...hat.com
CC: linux-kernel@...r.kernel.org
Subject: Re: Kernel panic in __migrate_swap_task() under stress-ng

Hi Jirka,

Thanks again for the detailed logs and clarification.

Based on your trace and timing (often crashing around test 30+ out of 41, after long runtime), I suspect it could be a use-after-free or delayed wake-up race in the CPU stopper thread handling.

In particular, I noticed:

The RIP __migrate_swap_task+0x2f attempts to dereference +0x4c8 from a NULL task_struct pointer.

That offset is near task->se.cfs_rq or task->sched_info on some architectures — which makes me wonder if the task was already de-queued from its CPU’s rq during swap or sem cleanup.

Since stress-ng uses short timed sem/fork loops with varying threads, maybe the task was migrated mid-finalization?

As an experiment, I’ll try:

Looping stress-ng --sem --taskset 0-15

Watching perf top and tracing with ftrace on migrate_swap_stop and task_rq_lock

Let’s see if I can narrow it down further. If I get a hit, I’ll share the trace.

Thanks again —
Best regards,
Abhigyan Ghosh
zsml.zscript.org

aghosh