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] [day] [month] [year] [list]
Message-ID: <87a5cq7639.ffs@tglx>
Date: Fri, 20 Dec 2024 15:59:54 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: syzbot <syzbot+3c2e3cc60665d71de2f7@...kaller.appspotmail.com>,
 anna-maria@...utronix.de, linux-kernel@...r.kernel.org,
 peterz@...radead.org, syzkaller-bugs@...glegroups.com, Eric Biederman
 <ebiederm@...ssion.com>, Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH] signal/posixtimers: Handle ignore/blocked sequences
 correctly

On Fri, Dec 20 2024 at 14:23, Frederic Weisbecker wrote:
> Le Fri, Dec 20, 2024 at 02:14:07PM +0100, Thomas Gleixner a écrit :
>> On Fri, Dec 20 2024 at 14:06, Frederic Weisbecker wrote:
>> > Le Thu, Dec 19, 2024 at 08:46:25PM +0100, Thomas Gleixner a écrit :
>> >>  		if (!list_empty(&q->list)) {
>> >>  			/*
>> >> -			 * If task group is exiting with the signal already pending,
>> >> -			 * wait for __exit_signal() to do its job. Otherwise if
>> >> -			 * ignored, it's not supposed to be queued. Try to survive.
>> >> +			 * The signal was ignored and blocked. The timer
>> >> +			 * expiry queued it because blocked signals are
>> >> +			 * queued independent of the ignored state.
>> >> +			 *
>> >> +			 * The unblocking set SIGPENDING, but the signal
>> >> +			 * was not yet dequeued from the pending list,
>> >> +			 * which would have put it back on the ignore list.
>> >
>> > I must be missing something. I don't see dequeue_signal() checking if a signal
>> > is ignored upon delivery.
>> 
>> 
>> Sorry, I meant get_signal() which is what the actual signal delivery
>> path on exit to user space invokes. dequeue itself does not care.
>> 
> Hmm, ok it eventually ignores the signal delivery to the user but:
>
> _ Dequeue signal has delivered it to posix timers
> _ The signal isn't moved back to the ignored list (or I'm missing something else?)

Hmm. Right it is not, but that's correct for blocked signals because
they can be also retrieved by sig[timed]wait().

For the case where the signal is ignored, the dequeue and posix timer
delivery is not harmful. If it gets rearmed, then the next timer expiry
will see ignored and move it to the ignored list.

Let me stare at it some more and rewrite the comments to match reality.

Thanks for pointing it out!

       tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ