RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-07-24 22:17:42 +00:00
Code Issues Activity Actions

Kernel: VERIFY that signals are not sent to Kernel processes

Browse source 
Kernel processes can't handle signals, nor should they ever receive any
This commit is contained in:
Idan Horowitz 2022-02-21 19:53:39 +02:00 • committed by Andreas Kling
parent 2c996cbbee
commit 0911112286
2 changed files with 2 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

1
Kernel/Process.cpp
View file

@ -707,6 +707,7 @@ void Process::terminate_due_to_signal(u8 signal)
ErrorOr<void> Process::send_signal(u8 signal, Process* sender) ErrorOr<void> Process::send_signal(u8 signal, Process* sender)
{ {
VERIFY(is_user_process());
// Try to send it to the "obvious" main thread: // Try to send it to the "obvious" main thread:
auto receiver_thread = Thread::from_tid(pid().value()); auto receiver_thread = Thread::from_tid(pid().value());
// If the main thread has died, there may still be other threads: // If the main thread has died, there may still be other threads:

1
Kernel/Thread.cpp
View file

@ -721,6 +721,7 @@ u32 Thread::pending_signals_for_state() const
void Thread::send_signal(u8 signal, [[maybe_unused]] Process* sender) void Thread::send_signal(u8 signal, [[maybe_unused]] Process* sender)
{ {
VERIFY(signal < 32); VERIFY(signal < 32);
VERIFY(process().is_user_process());
SpinlockLocker scheduler_lock(g_scheduler_lock); SpinlockLocker scheduler_lock(g_scheduler_lock);
// FIXME: Figure out what to do for masked signals. Should we also ignore them here? // FIXME: Figure out what to do for masked signals. Should we also ignore them here?