linux-kernel - kill(2) Syscall Behavior with pid=-1

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

Date:   Wed, 1 Sep 2021 08:46:18 -0400
From:   Zach Hopkins <hopkinsza@...il.com>
To:     linux-kernel@...r.kernel.org
Subject: kill(2) Syscall Behavior with pid=-1

Howdy,

I believe I may have found an edge case where kill(2) exhibits
unexpected behavior. The context is with only 2 processes running atop
the kernel -- an init and a compiled C binary. According to the kill(2)
man page, it seems that `kill(-1, SIGTERM)' should return -1 with
errno=ESRCH in this scenario (when run in the C binary), but instead it
returns 0.

Relevant parts of the linux man page are as follows:

1. "If pid equals -1, then sig is sent to every process for which the
calling process has permission to send signals, except for process 1
(init)"

2. "On success (at least one signal was sent), zero is returned"

3. "on Linux the call kill(-1,sig) does not signal the calling process"

In this scenario, the init and the C binary are the only processes
running on the system. With pid=-1, no signal should be sent to init or
itself due to exhibits 1 and 3. There are no other processes which could
possibly be signaled, so therefore the kill() should return -1 with
errno=ESRCH (No such process).

This was found while running Linux 5.13.0 via qemu. Testing the same
situation on NetBSD 9.2 gave the initially expected results.

Thank you for your time, and let me know if there's any more information
or context that would be helpful.