{"api_version":"1","generated_at":"2026-09-20T14:37:05+00:00","cve":"CVE-2026-90347","urls":{"html":"https://cve.report/CVE-2026-90347","api":"https://cve.report/api/cve/CVE-2026-90347.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-90347","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-90347"},"summary":{"title":"arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry","description":"In the Linux kernel, the following vulnerability has been resolved:\n\narm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry\n\nCommit e057b9477232 (\"arm64: syscall: Ensure saved x0 is kept in-sync\nwith tracer updates\") attempted to resolve a long-standing issue with\nsyscall entry tracing, where a tracer is able to manipulate the first\nsyscall argument without being subjected to seccomp or audit checking.\n\nUnfortunately, that fix was incomplete [1], as it failed to update\n'orig_x0' between a tracer updating x0 during a seccomp ptrace exit\n(SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated.\n\nRather than add hooks to the core seccomp code, instead move the\nsynchronisation code into the ptrace GPR and syscall setting code so\nthat 'orig_x0' is kept up to date with x0 whenever we're stopped on the\nsyscall entry path.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-09-17 17:17:33","updated_at":"2026-09-18 18:17:54"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"8.4","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","baseScore":8.4,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"CHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"NONE"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"8.4","severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","data":{"baseScore":8.4,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/88b839ce497ccb1ff92f7ae742c78dd2937ba572","name":"https://git.kernel.org/stable/c/88b839ce497ccb1ff92f7ae742c78dd2937ba572","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/f433869f23841a50455c4087d85540d5b4d37cde","name":"https://git.kernel.org/stable/c/f433869f23841a50455c4087d85540d5b4d37cde","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-90347","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-90347","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected a5cd110cb8369d6b37ef5ccfe56b3fa1338c9615 f433869f23841a50455c4087d85540d5b4d37cde git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected a5cd110cb8369d6b37ef5ccfe56b3fa1338c9615 88b839ce497ccb1ff92f7ae742c78dd2937ba572 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4.8","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 4.8 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.6 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":{"cve_year":"2026","cve_id":"90347","cve":"CVE-2026-90347","epss":"0.001520000","percentile":"0.047280000","score_date":"2026-09-19","updated_at":"2026-09-20 00:14:30"},"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["arch/arm64/kernel/ptrace.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"f433869f23841a50455c4087d85540d5b4d37cde","status":"affected","version":"a5cd110cb8369d6b37ef5ccfe56b3fa1338c9615","versionType":"git"},{"lessThan":"88b839ce497ccb1ff92f7ae742c78dd2937ba572","status":"affected","version":"a5cd110cb8369d6b37ef5ccfe56b3fa1338c9615","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["arch/arm64/kernel/ptrace.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"4.8"},{"lessThan":"4.8","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.6","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.6","versionStartIncluding":"4.8","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3-rc1","versionStartIncluding":"4.8","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\narm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry\n\nCommit e057b9477232 (\"arm64: syscall: Ensure saved x0 is kept in-sync\nwith tracer updates\") attempted to resolve a long-standing issue with\nsyscall entry tracing, where a tracer is able to manipulate the first\nsyscall argument without being subjected to seccomp or audit checking.\n\nUnfortunately, that fix was incomplete [1], as it failed to update\n'orig_x0' between a tracer updating x0 during a seccomp ptrace exit\n(SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated.\n\nRather than add hooks to the core seccomp code, instead move the\nsynchronisation code into the ptrace GPR and syscall setting code so\nthat 'orig_x0' is kept up to date with x0 whenever we're stopped on the\nsyscall entry path."}],"metrics":[{"cvssV3_1":{"baseScore":8.4,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","version":"3.1"},"scenarios":[{"lang":"en","value":"AV:L - The attacker-controlled value is x0 written by ptrace(PTRACE_SETREGSET, NT_PRSTATUS) into gpr_set() while the tracee is stopped in syscall_trace_enter() after ptrace_report_syscall_entry() or ptrace_event(PTRACE_EVENT_SECCOMP) from SECCOMP_RET_TRACE. That write is a local ptrace syscall, not a received protocol message.\nAC:L - The tracer owns the stop: waitpid() for the PTRACE_SYSCALL enter-stop or PTRACE_EVENT_SECCOMP trap, PTRACE_SETREGSET to replace regs[0], then PTRACE_CONT. el0_svc_common() then reaches secure_computing() with orig_x0 still equal to the pre-ptrace x0. No race or uninfluenced layout is required.\nPR:L - __ptrace_may_access() allows a same-uid tracer, and default yama ptrace_scope (YAMA_SCOPE_RELATIONAL) permits PTRACE_TRACEME or PTRACE_ATTACH to a descendant without CAP_SYS_PTRACE. An ordinary user can fork, trace the child, and issue PTRACE_SETREGSET; init-namespace root is not required.\nUI:N - The attacker issues PTRACE_TRACEME/PTRACE_SYSCALL, PTRACE_SETREGSET of NT_PRSTATUS, and the in-flight syscall on their own descendant. No separate victim action such as mounting a filesystem or opening a file is required.\nS:C - populate_seccomp_data() exposes orig_x0 as sd.args[0] to a parent-installed seccomp filter (container runtime, systemd RestrictNamespaces, Android minijail). gpr_set() updates regs[0] without orig_x0, so invoke_syscall() via SC_ARM64_REGS_TO_ARGS runs a denied first argument while the filter still allows the old orig_x0, escaping that sandbox.\nC:H - syscall_get_arguments() returns stale orig_x0 to seccomp while __arm64_sys_* wrappers take regs[0]. A tracer starts an allowed openat(dfd) or socket(domain) and replaces x0 with a blocked directory fd or AF_NETLINK/AF_PACKET, so the syscall discloses files or netlink state the filter was written to deny.\nI:H - arm64 clone() takes clone_flags in x0 (CONFIG_CLONE_BACKWARDS). After gpr_set() writes regs[0] without orig_x0, __seccomp_filter() (including the SECCOMP_RET_TRACE recheck) still sees the allowed flags while invoke_syscall() honors CLONE_NEWUSER/CLONE_NEWNS the policy forbade; substituting write/ioctl's fd in x0 likewise modifies data the filter blocked.\nA:N - The bug is orig_x0 remaining stale after gpr_set() so populate_seccomp_data() and audit_syscall_entry() inspect the wrong first argument. That is a seccomp/audit policy bypass, not memory corruption, and it does not oops, panic, deadlock, or hang the kernel."}]}],"providerMetadata":{"dateUpdated":"2026-09-18T17:54:46.679Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/f433869f23841a50455c4087d85540d5b4d37cde"},{"url":"https://git.kernel.org/stable/c/88b839ce497ccb1ff92f7ae742c78dd2937ba572"}],"title":"arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-90347","datePublished":"2026-09-17T16:08:56.232Z","dateReserved":"2026-09-11T19:38:34.805Z","dateUpdated":"2026-09-18T17:54:46.679Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-17 17:17:33","lastModifiedDate":"2026-09-18 18:17:54","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","baseScore":8.4,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"CHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"NONE"},"exploitabilityScore":2,"impactScore":5.8}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"90347","Ordinal":"1","Title":"arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry","CVE":"CVE-2026-90347","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"90347","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\narm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry\n\nCommit e057b9477232 (\"arm64: syscall: Ensure saved x0 is kept in-sync\nwith tracer updates\") attempted to resolve a long-standing issue with\nsyscall entry tracing, where a tracer is able to manipulate the first\nsyscall argument without being subjected to seccomp or audit checking.\n\nUnfortunately, that fix was incomplete [1], as it failed to update\n'orig_x0' between a tracer updating x0 during a seccomp ptrace exit\n(SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated.\n\nRather than add hooks to the core seccomp code, instead move the\nsynchronisation code into the ptrace GPR and syscall setting code so\nthat 'orig_x0' is kept up to date with x0 whenever we're stopped on the\nsyscall entry path.","Type":"Description","Title":"arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry"}]}}}