{
  "cveId": "CVE-2024-35871",
  "url": "https://patchblox.com/security/cve/CVE-2024-35871",
  "summary": "CVE-2024-35871 is fixed in linux on 1 platform, first by DEBIAN-CVE-2024-35871, released May 19, 2024. It is not reported as exploited. Patch Radar priority: High.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  riscv: process: Fix kernel gp leakage  childregs...",
  "description": "In the Linux kernel, the following vulnerability has been resolved:  riscv: process: Fix kernel gp leakage  childregs represents the registers which are active for the new thread in user context. For a kernel thread, childregs-\u003Egp is never used since the kernel gp is not touched by switch_to. For a user mode helper, the gp value can be observed in user space after execve or possibly by other means.  [From the email thread]  The /* Kernel thread */ comment is somewhat inaccurate in that it is also used for user_mode_helper threads, which exec a user process, e.g. /sbin/init or when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have PF_KTHREAD set and are valid targets for ptrace etc. even before they exec.  childregs is the *user* context during syscall execution and it is observable from userspace in at least five ways:  1. kernel_execve does not currently clear integer registers, so the starting    register state for PID 1 and other user processes started by the kernel has    sp = user stack, gp = kernel __global_pointer$, all other integer registers    zeroed by the memset in the patch comment.     This is a bug in its own right, but I\u0027m unwilling to bet that it is the only    way to exploit the issue addressed by this patch.  2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread    before it execs, but ptrace requires SIGSTOP to be delivered which can only    happen at user/kernel boundaries.  3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for    user_mode_helpers before the exec completes, but gp is not one of the    registers it returns.  4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel    addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses    are also exposed via PERF_SAMPLE_REGS_USER which is permitted under    LOCKDOWN_PERF. I have not attempted to write exploit code.  5. Much of the tracing infrastructure allows access to user registers. I have    not attempted to determine which forms of tracing allow access to user    registers without already allowing access to kernel registers.",
  "published": "2024-05-19T09:15:08Z",
  "severity": "high",
  "cvss": 7.1,
  "cvssVector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
  "epss": 0.00266,
  "epssPercentile": 0.1864,
  "priority": "High",
  "priorityTier": 3,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 12.15 (bookworm)",
      "fixedVersion": "6.1.85-1",
      "fix": "DEBIAN-CVE-2024-35871",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2024-35871",
      "released": "2024-05-19T09:15:08Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 13.5 (trixie)",
      "fixedVersion": "6.8.9-1",
      "fix": "DEBIAN-CVE-2024-35871",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2024-35871",
      "released": "2024-05-19T09:15:08Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "6.8.9-1",
      "fix": "DEBIAN-CVE-2024-35871",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2024-35871",
      "released": "2024-05-19T09:15:08Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-08T00:53:09Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}