CVE-2022-49783 (GCVE-0-2022-49783)
Vulnerability from cvelistv5
Published
2025-05-01 14:09
Modified
2025-05-04 08:45
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Drop fpregs lock before inheriting FPU permissions Mike Galbraith reported the following against an old fork of preempt-rt but the same issue also applies to the current preempt-rt tree. BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: fpu_clone CPU: 6 PID: 1 Comm: systemd Tainted: G E (unreleased) Call Trace: <TASK> dump_stack_lvl ? fpu_clone __might_resched rt_spin_lock fpu_clone ? copy_thread ? copy_process ? shmem_alloc_inode ? kmem_cache_alloc ? kernel_clone ? __do_sys_clone ? do_syscall_64 ? __x64_sys_rt_sigprocmask ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? exc_page_fault ? entry_SYSCALL_64_after_hwframe </TASK> Mike says: The splat comes from fpu_inherit_perms() being called under fpregs_lock(), and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic() returning true despite static key __fpu_state_size_dynamic having never been enabled. Mike's assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables preemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This problem exists since commit 9e798e9aa14c ("x86/fpu: Prepare fpu_clone() for dynamically enabled features"). Even though the original bug report should not have enabled the paths at all, the bug still exists. fpregs_lock is necessary when editing the FPU registers or a task's FP state but it is not necessary for fpu_inherit_perms(). The only write of any FP state in fpu_inherit_perms() is for the new child which is not running yet and cannot context switch or be borrowed by a kernel thread yet. Hence, fpregs_lock is not protecting anything in the new child until clone() completes and can be dropped earlier. The siglock still needs to be acquired by fpu_inherit_perms() as the read of the parent's permissions has to be serialised. [ bp: Cleanup splat. ]
References
Impacted products
Vendor Product Version
Linux Linux Version: 9e798e9aa14c45fb94e47b30bf6347b369ce9df7
Version: 9e798e9aa14c45fb94e47b30bf6347b369ce9df7
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/kernel/fpu/core.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "c6e8a7a1780af3da65e78a615f7d0874da6aabb0",
              "status": "affected",
              "version": "9e798e9aa14c45fb94e47b30bf6347b369ce9df7",
              "versionType": "git"
            },
            {
              "lessThan": "36b038791e1e2baea892e9276588815fd14894b4",
              "status": "affected",
              "version": "9e798e9aa14c45fb94e47b30bf6347b369ce9df7",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "arch/x86/kernel/fpu/core.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.16"
            },
            {
              "lessThan": "5.16",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.0.*",
              "status": "unaffected",
              "version": "6.0.10",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.0.10",
                  "versionStartIncluding": "5.16",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1",
                  "versionStartIncluding": "5.16",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Drop fpregs lock before inheriting FPU permissions\n\nMike Galbraith reported the following against an old fork of preempt-rt\nbut the same issue also applies to the current preempt-rt tree.\n\n   BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\n   in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd\n   preempt_count: 1, expected: 0\n   RCU nest depth: 0, expected: 0\n   Preemption disabled at:\n   fpu_clone\n   CPU: 6 PID: 1 Comm: systemd Tainted: G            E       (unreleased)\n   Call Trace:\n    \u003cTASK\u003e\n    dump_stack_lvl\n    ? fpu_clone\n    __might_resched\n    rt_spin_lock\n    fpu_clone\n    ? copy_thread\n    ? copy_process\n    ? shmem_alloc_inode\n    ? kmem_cache_alloc\n    ? kernel_clone\n    ? __do_sys_clone\n    ? do_syscall_64\n    ? __x64_sys_rt_sigprocmask\n    ? syscall_exit_to_user_mode\n    ? do_syscall_64\n    ? syscall_exit_to_user_mode\n    ? do_syscall_64\n    ? syscall_exit_to_user_mode\n    ? do_syscall_64\n    ? exc_page_fault\n    ? entry_SYSCALL_64_after_hwframe\n    \u003c/TASK\u003e\n\nMike says:\n\n  The splat comes from fpu_inherit_perms() being called under fpregs_lock(),\n  and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic()\n  returning true despite static key __fpu_state_size_dynamic having never\n  been enabled.\n\nMike\u0027s assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables\npreemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This\nproblem exists since commit\n\n  9e798e9aa14c (\"x86/fpu: Prepare fpu_clone() for dynamically enabled features\").\n\nEven though the original bug report should not have enabled the paths at\nall, the bug still exists.\n\nfpregs_lock is necessary when editing the FPU registers or a task\u0027s FP\nstate but it is not necessary for fpu_inherit_perms(). The only write\nof any FP state in fpu_inherit_perms() is for the new child which is\nnot running yet and cannot context switch or be borrowed by a kernel\nthread yet. Hence, fpregs_lock is not protecting anything in the new\nchild until clone() completes and can be dropped earlier. The siglock\nstill needs to be acquired by fpu_inherit_perms() as the read of the\nparent\u0027s permissions has to be serialised.\n\n  [ bp: Cleanup splat. ]"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-04T08:45:16.690Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/c6e8a7a1780af3da65e78a615f7d0874da6aabb0"
        },
        {
          "url": "https://git.kernel.org/stable/c/36b038791e1e2baea892e9276588815fd14894b4"
        }
      ],
      "title": "x86/fpu: Drop fpregs lock before inheriting FPU permissions",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2022-49783",
    "datePublished": "2025-05-01T14:09:17.054Z",
    "dateReserved": "2025-05-01T14:05:17.223Z",
    "dateUpdated": "2025-05-04T08:45:16.690Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2022-49783\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-05-01T15:16:01.510\",\"lastModified\":\"2025-05-02T13:53:20.943\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nx86/fpu: Drop fpregs lock before inheriting FPU permissions\\n\\nMike Galbraith reported the following against an old fork of preempt-rt\\nbut the same issue also applies to the current preempt-rt tree.\\n\\n   BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\\n   in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd\\n   preempt_count: 1, expected: 0\\n   RCU nest depth: 0, expected: 0\\n   Preemption disabled at:\\n   fpu_clone\\n   CPU: 6 PID: 1 Comm: systemd Tainted: G            E       (unreleased)\\n   Call Trace:\\n    \u003cTASK\u003e\\n    dump_stack_lvl\\n    ? fpu_clone\\n    __might_resched\\n    rt_spin_lock\\n    fpu_clone\\n    ? copy_thread\\n    ? copy_process\\n    ? shmem_alloc_inode\\n    ? kmem_cache_alloc\\n    ? kernel_clone\\n    ? __do_sys_clone\\n    ? do_syscall_64\\n    ? __x64_sys_rt_sigprocmask\\n    ? syscall_exit_to_user_mode\\n    ? do_syscall_64\\n    ? syscall_exit_to_user_mode\\n    ? do_syscall_64\\n    ? syscall_exit_to_user_mode\\n    ? do_syscall_64\\n    ? exc_page_fault\\n    ? entry_SYSCALL_64_after_hwframe\\n    \u003c/TASK\u003e\\n\\nMike says:\\n\\n  The splat comes from fpu_inherit_perms() being called under fpregs_lock(),\\n  and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic()\\n  returning true despite static key __fpu_state_size_dynamic having never\\n  been enabled.\\n\\nMike\u0027s assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables\\npreemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This\\nproblem exists since commit\\n\\n  9e798e9aa14c (\\\"x86/fpu: Prepare fpu_clone() for dynamically enabled features\\\").\\n\\nEven though the original bug report should not have enabled the paths at\\nall, the bug still exists.\\n\\nfpregs_lock is necessary when editing the FPU registers or a task\u0027s FP\\nstate but it is not necessary for fpu_inherit_perms(). The only write\\nof any FP state in fpu_inherit_perms() is for the new child which is\\nnot running yet and cannot context switch or be borrowed by a kernel\\nthread yet. Hence, fpregs_lock is not protecting anything in the new\\nchild until clone() completes and can be dropped earlier. The siglock\\nstill needs to be acquired by fpu_inherit_perms() as the read of the\\nparent\u0027s permissions has to be serialised.\\n\\n  [ bp: Cleanup splat. ]\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Eliminar el bloqueo de fpregs antes de heredar los permisos de FPU Mike Galbraith inform\u00f3 lo siguiente contra una antigua bifurcaci\u00f3n de preempt-rt, pero el mismo problema tambi\u00e9n se aplica al \u00e1rbol preempt-rt actual. ERROR: funci\u00f3n inactiva llamada desde un contexto no v\u00e1lido en kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd preempt_count: 1, expected: 0 Profundidad de anidamiento de RCU: 0, expected: 0 Preempci\u00f3n deshabilitada en: fpu_clone CPU: 6 PID: 1 Comm: systemd Tainted: GE (no publicado) Rastreo de llamadas:   dump_stack_lvl ? fpu_clone __might_resched rt_spin_lock fpu_clone ? copy_thread ? copy_process ? shmem_alloc_inode ? kmem_cache_alloc ? kernel_clone ? __do_sys_clone ? do_syscall_64 ? __x64_sys_rt_sigprocmask ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? exc_page_fault ? entry_SYSCALL_64_after_hwframe   Mike dice: El problema se debe a que fpu_inherit_perms() se llama bajo fpregs_lock() y a que alcanzamos spin_lock_irq() debido a que fpu_state_size_dynamic() devuelve verdadero a pesar de que la clave est\u00e1tica __fpu_state_size_dynamic nunca se ha habilitado. La evaluaci\u00f3n de Mike parece correcta. fpregs_lock en un kernel PREEMPT_RT deshabilita la preempci\u00f3n, por lo que llamar a spin_lock_irq() en fpu_inherit_perms() no es seguro. Este problema existe desde la confirmaci\u00f3n 9e798e9aa14c (\\\"x86/fpu: Preparar fpu_clone() para funciones habilitadas din\u00e1micamente\\\"). Aunque el informe de error original no deber\u00eda haber habilitado las rutas, el error persiste. fpregs_lock es necesario al editar los registros de FPU o el estado de FP de una tarea, pero no es necesario para fpu_inherit_perms(). La \u00fanica escritura de cualquier estado de FP en fpu_inherit_perms() es para el nuevo hijo, que a\u00fan no se est\u00e1 ejecutando y a\u00fan no puede cambiar de contexto ni ser tomado prestado por un hilo del kernel. Por lo tanto, fpregs_lock no protege nada en el nuevo hijo hasta que clone() se complete y pueda eliminarse antes. El siglock a\u00fan debe ser adquirido por fpu_inherit_perms(), ya que la lectura de los permisos del padre debe serializarse. [bp: Limpieza splat.]\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/36b038791e1e2baea892e9276588815fd14894b4\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/c6e8a7a1780af3da65e78a615f7d0874da6aabb0\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.