CVE-2023-54267
published 2025-12-30CVE-2023-54267: In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT lppaca_shared_proc()…
PriorityP422low2.5
EPSS
0.19%
8.6th percentile
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
lppaca_shared_proc() takes a pointer to the lppaca which is typically
accessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leads
to checking if preemption is enabled, for example:
BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693
caller is lparcfg_data+0x408/0x19a0
CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2
Call Trace:
dump_stack_lvl+0x154/0x200 (unreliable)
check_preemption_disabled+0x214/0x220
lparcfg_data+0x408/0x19a0
...
This isn't actually a problem however, as it does not matter which
lppaca is accessed, the shared proc state will be the same.
vcpudispatch_stats_procfs_init() already works around this by disabling
preemption, but the lparcfg code does not, erroring any time
/proc/powerpc/lparcfg is accessed with DEBUG_PREEMPT enabled.
Instead of disabling preemption on the caller side, rework
lppaca_shared_proc() to not take a pointer and instead directly access
the lppaca, bypassing any potential preemption checks.
[mpe: Rework to avoid needing a definition in paca.h and lppaca.h]
Affected
17 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.55-1 (bookworm) | linux 6.1.55-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= f13c13a005127b5dc5daaca190277a062d946e63 < 953c54dfdc5d3eb7243ed902b50acb5ea1db4355 | 953c54dfdc5d3eb7243ed902b50acb5ea1db4355 |
| linux | linux | >= f13c13a005127b5dc5daaca190277a062d946e63 < 2935443dc9c28499223d8c881474259e4b998f2a | 2935443dc9c28499223d8c881474259e4b998f2a |
| linux | linux | >= f13c13a005127b5dc5daaca190277a062d946e63 < 4c8568cf4c45b415854195c8832b557cdefba57a | 4c8568cf4c45b415854195c8832b557cdefba57a |
| linux | linux | >= f13c13a005127b5dc5daaca190277a062d946e63 < 3c5e8e666794d7dde6d14ea846c6c04f2bb34900 | 3c5e8e666794d7dde6d14ea846c6c04f2bb34900 |
| linux | linux | >= f13c13a005127b5dc5daaca190277a062d946e63 < f45ee5c074013a0fbfce77a5af5efddb01f5d4f4 | f45ee5c074013a0fbfce77a5af5efddb01f5d4f4 |
| linux | linux | >= f13c13a005127b5dc5daaca190277a062d946e63 < eac030b22ea12cdfcbb2e941c21c03964403c63f | eac030b22ea12cdfcbb2e941c21c03964403c63f |
| linux | linux_kernel | >= 0 < 5.10.197-1 | 5.10.197-1 |
| linux | linux_kernel | >= 0 < 6.1.55-1 | 6.1.55-1 |
| linux | linux_kernel | >= 0 < 6.5.3-1 | 6.5.3-1 |
| linux | linux_kernel | >= 0 < 6.5.3-1 | 6.5.3-1 |
| linux | linux_kernel | >= 3.12.0 < 5.10.195 | 5.10.195 |
| linux | linux_kernel | >= 5.11.0 < 5.15.132 | 5.15.132 |
| linux | linux_kernel | >= 5.16.0 < 6.1.53 | 6.1.53 |
| linux | linux_kernel | >= 6.2.0 < 6.4.16 | 6.4.16 |
| linux | linux_kernel | >= 6.5.0 < 6.5.3 | 6.5.3 |
Stop checking back — get the weekly exploitation signal.
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-r3v9-vm52-w2px: In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
lppaca_share
ghsa_unreviewed·2025-12-30
CVE-2023-54267 GHSA-r3v9-vm52-w2px: In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
lppaca_share
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
lppaca_shared_proc() takes a pointer to the lppaca which is typically
accessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leads
to checking if preemption is enabled, for example:
BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693
caller is lparcfg_data+0x408/0x19a0
CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2
Call Trace:
dump_stack_lvl+0x154/0x200 (unreliable)
check_preemption_disabled+0x214/0x220
lparcfg_data+0x408/0x19a0
...
This isn't actually a problem however, as it does not matter which
lppaca is accessed, the shared proc state will be the same.
vcpudispatch_stats_procfs_init() already works around this
OSV
powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
osv·2025-12-30
CVE-2023-54267 powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
lppaca_shared_proc() takes a pointer to the lppaca which is typically
accessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leads
to checking if preemption is enabled, for example:
BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693
caller is lparcfg_data+0x408/0x19a0
CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2
Call Trace:
dump_stack_lvl+0x154/0x200 (unreliable)
check_preemption_disabled+0x214/0x220
lparcfg_data+0x408/0x19a0
...
This isn't actually a problem however, as it does not matter which
lppaca is accessed, the shared proc state will be
OSV
CVE-2023-54267: In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT lppaca_shared_
osv·2025-12-30
CVE-2023-54267 CVE-2023-54267: In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT lppaca_shared_
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT lppaca_shared_proc() takes a pointer to the lppaca which is typically accessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leads to checking if preemption is enabled, for example: BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693 caller is lparcfg_data+0x408/0x19a0 CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2 Call Trace: dump_stack_lvl+0x154/0x200 (unreliable) check_preemption_disabled+0x214/0x220 lparcfg_data+0x408/0x19a0 ... This isn't actually a problem however, as it does not matter which lppaca is accessed, the shared proc state will be the same. vcpudispatch_stats_procfs_init() already works around this by d
Red Hat
kernel: powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
vendor_redhat·2025-12-30·CVSS 2.5
CVE-2023-54267 [LOW] CWE-663 kernel: powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
kernel: powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
lppaca_shared_proc() takes a pointer to the lppaca which is typically
accessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leads
to checking if preemption is enabled, for example:
BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693
caller is lparcfg_data+0x408/0x19a0
CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2
Call Trace:
dump_stack_lvl+0x154/0x200 (unreliable)
check_preemption_disabled+0x214/0x220
lparcfg_data+0x408/0x19a0
...
This isn't actually a problem however, as it does not matter which
lppaca is accessed, the shared proc state will
Debian
CVE-2023-54267: linux - In the Linux kernel, the following vulnerability has been resolved: powerpc/pse...
vendor_debian·2023
CVE-2023-54267 CVE-2023-54267: linux - In the Linux kernel, the following vulnerability has been resolved: powerpc/pse...
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT lppaca_shared_proc() takes a pointer to the lppaca which is typically accessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leads to checking if preemption is enabled, for example: BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693 caller is lparcfg_data+0x408/0x19a0 CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2 Call Trace: dump_stack_lvl+0x154/0x200 (unreliable) check_preemption_disabled+0x214/0x220 lparcfg_data+0x408/0x19a0 ... This isn't actually a problem however, as it does not matter which lppaca is accessed, the shared proc state will be the same. vcpudispatch_stats_procfs_init() already works around this by d
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2023-54267 kernel: powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
bugzilla·2025-12-30
CVE-2023-54267 [LOW] CVE-2023-54267 kernel: powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
CVE-2023-54267 kernel: powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
lppaca_shared_proc() takes a pointer to the lppaca which is typically
accessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leads
to checking if preemption is enabled, for example:
BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693
caller is lparcfg_data+0x408/0x19a0
CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2
Call Trace:
dump_stack_lvl+0x154/0x200 (unreliable)
check_preemption_disabled+0x214/0x220
lparcfg_data+0x408/0x19a0
...
This isn't actually a problem however, as it does not matter which
lppaca is accessed, the sha
Wiz
CVE-2023-54267 Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz
CVE-2023-54267 CVE-2023-54267 Impact, Exploitability, and Mitigation Steps | Wiz
## CVE-2023-54267 :
Linux Kernel vulnerability analysis and mitigation
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT
lppaca_shared_proc() takes a pointer to the lppaca which is typically
accessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leads
to checking if preemption is enabled, for example:
BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693
caller is lparcfg_data+0x408/0x19a0
CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2
Call Trace:
dump_stack_lvl+0x154/0x200 (unreliable)
check_preemption_disabled+0x214/0x220
lparcfg_data+0x408/0x19a0
...
This isn't actually a problem however, as it does not matter which
lppaca is accessed, the shared proc state will
https://git.kernel.org/stable/c/2935443dc9c28499223d8c881474259e4b998f2ahttps://git.kernel.org/stable/c/3c5e8e666794d7dde6d14ea846c6c04f2bb34900https://git.kernel.org/stable/c/4c8568cf4c45b415854195c8832b557cdefba57ahttps://git.kernel.org/stable/c/953c54dfdc5d3eb7243ed902b50acb5ea1db4355https://git.kernel.org/stable/c/eac030b22ea12cdfcbb2e941c21c03964403c63fhttps://git.kernel.org/stable/c/f45ee5c074013a0fbfce77a5af5efddb01f5d4f4
2025-12-30
Published