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: <b079b4f1-4d11-4137-8204-16935dc12129@google.com>
Date: Wed, 12 Nov 2025 11:28:05 +0800
From: Liangyan <liangyan.peng@...edance.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
 Liangyan <liangyan.peng@...edance.com>
Cc: peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
 namhyung@...nel.org, mark.rutland@....com,
 alexander.shishkin@...ux.intel.com, jolsa@...nel.org, irogers@...gle.com,
 adrian.hunter@...el.com, james.clark@...aro.org, zengxianjun@...edance.com,
 linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [External] Re: [PATCH v2] perf/core: Fix pending work re-queued
 in __perf_event_overflow



On 2025/11/11 21:30, Sebastian Andrzej Siewior wrote:
> On 2025-11-10 00:41:22 [+0800], Liangyan wrote:
>> We got warning below during perf test.
> …
>>
>> A race condition occurs between task context and IRQ context when
>> handling sigtrap tracepoint event overflows:
>>
>> 1. In task context, an event is overflowed and its pending work is
>>    queued to task->task_works
>> 2. Before pending_work is set, the same event overflows in IRQ context
>> 3. Both contexts queue the same perf pending work to task->task_works
>>
>> This double queuing causes:
>> - task_work_run() enters infinite loop calling perf_pending_task()
>> - Potential warnings and use-after-free when event is freed in
>> perf_pending_task()
>>
>> Fix the race by disabling interrupts during queuing of perf pending work.
> 
> Makes sense. Lets it does not overflow in NMI, too.
> Either way I suggest to trim the commit message and remove the
> backtrace as it probably does not add any value.
> 
> Sebastian

Got it, I will remove the backtrace in the following version.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ