Advisory Published
Updated

REDHAT-BUG-690028

First published: Wed Mar 23 2011(Updated: )

The libc' sigqueue() function allows to queue a signal, as well as some accompanying data to a process. The kernel's interface that is used to implement this function is known as rt_sigqueueinfo(). It has been added in Linux 2.2. This system call is interesting from a security perspective, because it allows userland to compeletely specify the siginfo_t structure. This structure is normally typically almost entirely written by the kernel when a signal is delivered. Since at least Linux 2.4.0, most abuses of the kernel interface have been prevented with a simple check: /* Not even root can pretend to send signals from the kernel. Nor can they impersonate a kill(), which adds source info. */ if (info.si_code &gt;= 0) return -EPERM; This check made sure that rt_sigqueueinfo() could not spoof a signal whose SI_CODE would be SI_KERNEL or SI_USER. As the comment indicates, a process receiving a signal should be able to trust its source pid or uid if its si_code matches SI_USER. Unfortunately, a couple of years later, when tgkill() and tkill() were added, this check was forgotten and was not updated to prevent the spoofing of a TGKILL si_code. Because of this, userland is unable to trust the pid and uid information of a TKILL signal. This is bad, because it is a useful feature in a scenario where a process which cannot ptrace you can send you signals. This includes at least the startup code of setuid binaries. Meanwhile, userland and libc writers still assumed that they could trust the origin of a SI_TKILL signal. Glibc authors too [1]. Worse: they even silently patched SI_TKILL with SI_USER [2], [3]. So even a userland application that (righfully so) only trusts SI_USER signals will be vulnerable. A tentative patch for this vulnerability has been committed to Linus' kernel tree [4]. In this patch, we prevent rt_sigqueueinfo() from specifying any si_code != SI_QUEUE. While we believe it to be very unlikley, this could in theory break userland in some older Linux distributions, so we may have to revert to a more concervative patch and prevent ( (si_code == SI_TKILL) || (si_code &gt;= SI_QUEUE) ) instead. [1]: <a href="http://codesearch.google.com/codesearch/p?hl=en#xy1xtVWIKOQ/pub/glibc/snapshots/glibc-latest.tar.bz2%7CXP6Z3zoy3dk/glibc-20090518/nptl/init.c&amp;l=175">http://codesearch.google.com/codesearch/p?hl=en#xy1xtVWIKOQ/pub/glibc/snapshots/glibc-latest.tar.bz2%7CXP6Z3zoy3dk/glibc-20090518/nptl/init.c&amp;l=175</a> [2]: <a href="http://codesearch.google.com/codesearch/p?hl=en#xy1xtVWIKOQ/pub/glibc/snapshots/glibc-latest.tar.bz2%7CXP6Z3zoy3dk/glibc-20090518/sysdeps/unix/sysv/linux/sigwaitinfo.c&amp;l=63">http://codesearch.google.com/codesearch/p?hl=en#xy1xtVWIKOQ/pub/glibc/snapshots/glibc-latest.tar.bz2%7CXP6Z3zoy3dk/glibc-20090518/sysdeps/unix/sysv/linux/sigwaitinfo.c&amp;l=63</a> [3]: <a href="http://codesearch.google.com/codesearch/p?hl=en#xy1xtVWIKOQ/pub/glibc/snapshots/glibc-latest.tar.bz2%7CXP6Z3zoy3dk/glibc-20090518/sysdeps/unix/sysv/linux/sigtimedwait.c&amp;l=62">http://codesearch.google.com/codesearch/p?hl=en#xy1xtVWIKOQ/pub/glibc/snapshots/glibc-latest.tar.bz2%7CXP6Z3zoy3dk/glibc-20090518/sysdeps/unix/sysv/linux/sigtimedwait.c&amp;l=62</a> [4]: <a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=da48524eb20662618854bb3df2db01fc65f3070c">http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=da48524eb20662618854bb3df2db01fc65f3070c</a> Acknowledgements: Red Hat would like to thank Julien Tinnes of Google Security Team for reporting this issue. Upstream commit: <a href="http://git.kernel.org/linus/da48524eb20662618854bb3df2db01fc65f3070c">http://git.kernel.org/linus/da48524eb20662618854bb3df2db01fc65f3070c</a> <a href="http://git.kernel.org/linus/243b422af9ea9af4ead07a8ad54c90d4f9b6081a">http://git.kernel.org/linus/243b422af9ea9af4ead07a8ad54c90d4f9b6081a</a>

Affected SoftwareAffected VersionHow to fix
Linux kernel>=2.4.0
GNU C Library

Never miss a vulnerability like this again

Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.

Frequently Asked Questions

  • What is the severity of REDHAT-BUG-690028?

    The severity of REDHAT-BUG-690028 is considered significant due to its potential security implications.

  • How do I fix REDHAT-BUG-690028?

    To fix REDHAT-BUG-690028, update your system to the latest versions of the affected Linux Kernel and GNU glibc.

  • Which systems are affected by REDHAT-BUG-690028?

    REDHAT-BUG-690028 affects systems running Linux Kernel version 2.4.0 and later, as well as the GNU C Library (glibc).

  • What does REDHAT-BUG-690028 impact?

    REDHAT-BUG-690028 impacts the functionality of the sigqueue() function in libc, which can lead to potential security vulnerabilities.

  • Is REDHAT-BUG-690028 related to any specific Linux distributions?

    REDHAT-BUG-690028 is primarily associated with Red Hat and other distributions utilizing the glibc and affected Linux Kernel versions.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2025 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203