https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-04T19:56:40.332407+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2024-06624 bdu:2024-06624 2026-10-04T19:56:40.417659+00:00 bdu:2024-06624 https://cve.radiocsirt.org/vuln/euvd-2026-344611 EUVD-2026-344611 2026-10-04T19:56:40.417698+00:00 EUVD-2026-344611 https://cve.radiocsirt.org/vuln/fkie_cve-2022-48892 fkie_cve-2022-48892 2026-10-04T19:56:40.417713+00:00

In the Linux kernel, the following vulnerability has been resolved:

sched/core: Fix use-after-free bug in dup_user_cpus_ptr()

Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be restricted on asymmetric systems"), the setting and clearing of user_cpus_ptr are done under pi_lock for arm64 architecture. However, dup_user_cpus_ptr() accesses user_cpus_ptr without any lock protection. Since sched_setaffinity() can be invoked from another process, the process being modified may be undergoing fork() at the same time. When racing with the clearing of user_cpus_ptr in __set_cpus_allowed_ptr_locked(), it can lead to user-after-free and possibly double-free in arm64 kernel.

Commit 8f9ea86fdf99 ("sched: Always preserve the user requested cpumask") fixes this problem as user_cpus_ptr, once set, will never be cleared in a task's lifetime. However, this bug was re-introduced in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in do_set_cpus_allowed(). This time, it will affect all arches.

Fix this bug by always clearing the user_cpus_ptr of the newly cloned/forked task before the copying process starts and check the user_cpus_ptr state of the source task under pi_lock.

Note to stable, this patch won't be applicable to stable releases. Just copy the new dup_user_cpus_ptr() function over.

 https://cve.radiocsirt.org/vuln/ghsa-hm85-hr96-4gwf GHSA-hm85-hr96-4gwf 2026-10-04T19:56:40.417758+00:00

In the Linux kernel, the following vulnerability has been resolved:

sched/core: Fix use-after-free bug in dup_user_cpus_ptr()

Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be restricted on asymmetric systems"), the setting and clearing of user_cpus_ptr are done under pi_lock for arm64 architecture. However, dup_user_cpus_ptr() accesses user_cpus_ptr without any lock protection. Since sched_setaffinity() can be invoked from another process, the process being modified may be undergoing fork() at the same time. When racing with the clearing of user_cpus_ptr in __set_cpus_allowed_ptr_locked(), it can lead to user-after-free and possibly double-free in arm64 kernel.

Commit 8f9ea86fdf99 ("sched: Always preserve the user requested cpumask") fixes this problem as user_cpus_ptr, once set, will never be cleared in a task's lifetime. However, this bug was re-introduced in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in do_set_cpus_allowed(). This time, it will affect all arches.

Fix this bug by always clearing the user_cpus_ptr of the newly cloned/forked task before the copying process starts and check the user_cpus_ptr state of the source task under pi_lock.

Note to stable, this patch won't be applicable to stable releases. Just copy the new dup_user_cpus_ptr() function over.

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-48892 UBUNTU-CVE-2022-48892 2026-10-04T19:56:40.417787+00:00

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 91 more

In the Linux kernel, the following vulnerability has been resolved: sched/core: Fix use-after-free bug in dup_user_cpus_ptr() Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be restricted on asymmetric systems"), the setting and clearing of user_cpus_ptr are done under pi_lock for arm64 architecture. However, dup_user_cpus_ptr() accesses user_cpus_ptr without any lock protection. Since sched_setaffinity() can be invoked from another process, the process being modified may be undergoing fork() at the same time. When racing with the clearing of user_cpus_ptr in __set_cpus_allowed_ptr_locked(), it can lead to user-after-free and possibly double-free in arm64 kernel. Commit 8f9ea86fdf99 ("sched: Always preserve the user requested cpumask") fixes this problem as user_cpus_ptr, once set, will never be cleared in a task's lifetime. However, this bug was re-introduced in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in do_set_cpus_allowed(). This time, it will affect all arches. Fix this bug by always clearing the user_cpus_ptr of the newly cloned/forked task before the copying process starts and check the user_cpus_ptr state of the source task under pi_lock. Note to stable, this patch won't be applicable to stable releases. Just copy the new dup_user_cpus_ptr() function over.

 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1888 WID-SEC-W-2024-1888 — Linux Kernel: Mehrere Schwachstellen 2026-10-04T19:56:40.417938+00:00

Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder einen unspezifischen Angriff durchzuführen.