* [PATCH] i915: Fix NULL pointer dereference in intel_dmc_update_dc6_allowed_count()
@ 2026-02-28 13:09 Tao Liu
2026-03-02 9:14 ` Jani Nikula
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Tao Liu @ 2026-02-28 13:09 UTC (permalink / raw)
To: jani.nikula, rodrigo.vivi, joonas.lahtinen, tursulin, airlied,
simona
Cc: intel-gfx, intel-xe, dri-devel, kexec, linux-kernel, Tao Liu
There is a NULL pointer dereference issue noticed in i915 when 2nd kernel
bootup during kdump. This will panic 2nd kernel and lead to no vmcore
generation. The issue is observed in Meteorlake CPU(cpuid: 0xA06A2):
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP NOPTI
...
RIP: 0010:intel_dmc_update_dc6_allowed_count+0x16/0xa0 [i915]
...
It is easy to locate the NULL pointer dereference by disassembly:
00000000001171e0 <intel_dmc_update_dc6_allowed_count>:
1171e0: f3 0f 1e fa endbr64
1171e4: e8 00 00 00 00 call 1171e9
1171e9: 41 55 push %r13
1171eb: 41 54 push %r12
1171ed: 55 push %rbp
1171ee: 53 push %rbx
1171ef: 4c 8b a7 18 03 00 00 mov 0x318(%rdi),%r12
1171f6: 49 8b 2c 24 mov (%r12),%rbp
To fix this, add a NULL pointer check before dereferencing.
Signed-off-by: Tao Liu <ltao@redhat.com>
---
The issue doesn't happen in 1st kernel, but in 2nd kernel of kdump. I'm not
an expert to i915 and unsure what lead to the NULL pointer. To help further
analysis, here is the full stack:
[ 8.608520] <TASK>
[ 8.610652] gen9_set_dc_state.part.0+0x25d/0x2f0 [i915]
[ 8.616096] icl_display_core_init+0x2d/0x620 [i915]
[ 8.621266] intel_power_domains_init_hw+0x1b2/0x500 [i915]
[ 8.627047] intel_display_driver_probe_noirq+0x87/0x300 [i915]
[ 8.633188] i915_driver_probe+0x207/0x5d0 [i915]
[ 8.637977] ? drm_privacy_screen_get+0x198/0x1c0
[ 8.642832] local_pci_probe+0x41/0x90
[ 8.646646] pci_call_probe+0x58/0x160
[ 8.650458] ? pci_assign_irq+0x2f/0x160
[ 8.654447] ? pci_match_device+0xf8/0x120
[ 8.658522] pci_device_probe+0x95/0x140
[ 8.662582] call_driver_probe+0x27/0x110
[ 8.666570] really_probe+0xcc/0x2c0
[ 8.670190] __driver_probe_device+0x78/0x120
[ 8.674692] driver_probe_device+0x1f/0xa0
[ 8.678857] __driver_attach+0xfa/0x230
[ 8.682757] ? __pfx___driver_attach+0x10/0x10
[ 8.687185] bus_for_each_dev+0x8e/0xe0
[ 8.691159] bus_add_driver+0x11f/0x200
[ 8.694970] driver_register+0x72/0xd0
[ 8.698853] i915_init+0x26/0x90 [i915]
[ 8.702837] ? __pfx_i915_init+0x10/0x10 [i915]
[ 8.707433] do_one_initcall+0x5c/0x320
[ 8.711409] do_init_module+0x60/0x240
[ 8.715132] init_module_from_file+0xd6/0x130
[ 8.719634] idempotent_init_module+0x114/0x310
[ 8.724241] __x64_sys_finit_module+0x71/0xe0
[ 8.728671] do_syscall_64+0x11b/0x6d0
[ 8.732483] ? ksys_read+0x6b/0xe0
[ 8.735854] ? arch_exit_to_user_mode_prepare.isra.0+0xa2/0xd0
[ 8.741768] ? do_syscall_64+0x153/0x6d0
[ 8.745828] ? do_syscall_64+0x153/0x6d0
[ 8.749814] ? do_syscall_64+0x153/0x6d0
[ 8.753800] ? clear_bhb_loop+0x30/0x80
[ 8.757700] entry_SYSCALL_64_after_hwframe+0x76/0x7e
---
drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c b/drivers/gpu/drm/i915/display/intel_dmc.c
index 1006b060c3f3..fd2756badc0c 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -1578,7 +1578,7 @@ void intel_dmc_update_dc6_allowed_count(struct intel_display *display,
struct intel_dmc *dmc = display_to_dmc(display);
u32 dc5_cur_count;
- if (DISPLAY_VER(dmc->display) < 14)
+ if (!dmc || DISPLAY_VER(dmc->display) < 14)
return;
dc5_cur_count = intel_de_read(dmc->display, DG1_DMC_DEBUG_DC5_COUNT);
--
2.47.0
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH] i915: Fix NULL pointer dereference in intel_dmc_update_dc6_allowed_count()
2026-02-28 13:09 [PATCH] i915: Fix NULL pointer dereference in intel_dmc_update_dc6_allowed_count() Tao Liu
@ 2026-03-02 9:14 ` Jani Nikula
2026-03-02 12:33 ` Tao Liu
2026-03-03 4:19 ` Claude review: " Claude Code Review Bot
2026-03-03 4:19 ` Claude Code Review Bot
2 siblings, 1 reply; 5+ messages in thread
From: Jani Nikula @ 2026-03-02 9:14 UTC (permalink / raw)
To: Tao Liu, rodrigo.vivi, joonas.lahtinen, tursulin, airlied, simona,
imre.deak
Cc: intel-gfx, intel-xe, dri-devel, kexec, linux-kernel, Tao Liu
On Sun, 01 Mar 2026, Tao Liu <ltao@redhat.com> wrote:
> There is a NULL pointer dereference issue noticed in i915 when 2nd kernel
> bootup during kdump. This will panic 2nd kernel and lead to no vmcore
> generation. The issue is observed in Meteorlake CPU(cpuid: 0xA06A2):
The previously posted fix is [1].
Imre, please R-b that. It's a NULL pointer dereference in the wild, in
stable kernels. We need to get it fixed instead of bikeshedding on
potential incorrect debugfs results.
BR,
Jani.
[1] https://lore.kernel.org/r/20251202183950.2450315-1-jani.nikula@intel.com
>
> BUG: kernel NULL pointer dereference, address: 0000000000000000
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> PGD 0 P4D 0
> Oops: Oops: 0000 [#1] SMP NOPTI
> ...
> RIP: 0010:intel_dmc_update_dc6_allowed_count+0x16/0xa0 [i915]
> ...
>
> It is easy to locate the NULL pointer dereference by disassembly:
>
> 00000000001171e0 <intel_dmc_update_dc6_allowed_count>:
> 1171e0: f3 0f 1e fa endbr64
> 1171e4: e8 00 00 00 00 call 1171e9
> 1171e9: 41 55 push %r13
> 1171eb: 41 54 push %r12
> 1171ed: 55 push %rbp
> 1171ee: 53 push %rbx
> 1171ef: 4c 8b a7 18 03 00 00 mov 0x318(%rdi),%r12
> 1171f6: 49 8b 2c 24 mov (%r12),%rbp
>
> To fix this, add a NULL pointer check before dereferencing.
>
> Signed-off-by: Tao Liu <ltao@redhat.com>
> ---
>
> The issue doesn't happen in 1st kernel, but in 2nd kernel of kdump. I'm not
> an expert to i915 and unsure what lead to the NULL pointer. To help further
> analysis, here is the full stack:
>
> [ 8.608520] <TASK>
> [ 8.610652] gen9_set_dc_state.part.0+0x25d/0x2f0 [i915]
> [ 8.616096] icl_display_core_init+0x2d/0x620 [i915]
> [ 8.621266] intel_power_domains_init_hw+0x1b2/0x500 [i915]
> [ 8.627047] intel_display_driver_probe_noirq+0x87/0x300 [i915]
> [ 8.633188] i915_driver_probe+0x207/0x5d0 [i915]
> [ 8.637977] ? drm_privacy_screen_get+0x198/0x1c0
> [ 8.642832] local_pci_probe+0x41/0x90
> [ 8.646646] pci_call_probe+0x58/0x160
> [ 8.650458] ? pci_assign_irq+0x2f/0x160
> [ 8.654447] ? pci_match_device+0xf8/0x120
> [ 8.658522] pci_device_probe+0x95/0x140
> [ 8.662582] call_driver_probe+0x27/0x110
> [ 8.666570] really_probe+0xcc/0x2c0
> [ 8.670190] __driver_probe_device+0x78/0x120
> [ 8.674692] driver_probe_device+0x1f/0xa0
> [ 8.678857] __driver_attach+0xfa/0x230
> [ 8.682757] ? __pfx___driver_attach+0x10/0x10
> [ 8.687185] bus_for_each_dev+0x8e/0xe0
> [ 8.691159] bus_add_driver+0x11f/0x200
> [ 8.694970] driver_register+0x72/0xd0
> [ 8.698853] i915_init+0x26/0x90 [i915]
> [ 8.702837] ? __pfx_i915_init+0x10/0x10 [i915]
> [ 8.707433] do_one_initcall+0x5c/0x320
> [ 8.711409] do_init_module+0x60/0x240
> [ 8.715132] init_module_from_file+0xd6/0x130
> [ 8.719634] idempotent_init_module+0x114/0x310
> [ 8.724241] __x64_sys_finit_module+0x71/0xe0
> [ 8.728671] do_syscall_64+0x11b/0x6d0
> [ 8.732483] ? ksys_read+0x6b/0xe0
> [ 8.735854] ? arch_exit_to_user_mode_prepare.isra.0+0xa2/0xd0
> [ 8.741768] ? do_syscall_64+0x153/0x6d0
> [ 8.745828] ? do_syscall_64+0x153/0x6d0
> [ 8.749814] ? do_syscall_64+0x153/0x6d0
> [ 8.753800] ? clear_bhb_loop+0x30/0x80
> [ 8.757700] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 1006b060c3f3..fd2756badc0c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -1578,7 +1578,7 @@ void intel_dmc_update_dc6_allowed_count(struct intel_display *display,
> struct intel_dmc *dmc = display_to_dmc(display);
> u32 dc5_cur_count;
>
> - if (DISPLAY_VER(dmc->display) < 14)
> + if (!dmc || DISPLAY_VER(dmc->display) < 14)
> return;
>
> dc5_cur_count = intel_de_read(dmc->display, DG1_DMC_DEBUG_DC5_COUNT);
--
Jani Nikula, Intel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] i915: Fix NULL pointer dereference in intel_dmc_update_dc6_allowed_count()
2026-03-02 9:14 ` Jani Nikula
@ 2026-03-02 12:33 ` Tao Liu
0 siblings, 0 replies; 5+ messages in thread
From: Tao Liu @ 2026-03-02 12:33 UTC (permalink / raw)
To: Jani Nikula
Cc: rodrigo.vivi, joonas.lahtinen, tursulin, airlied, simona,
imre.deak, intel-gfx, intel-xe, dri-devel, kexec, linux-kernel
On Mon, Mar 2, 2026 at 10:14 PM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> On Sun, 01 Mar 2026, Tao Liu <ltao@redhat.com> wrote:
> > There is a NULL pointer dereference issue noticed in i915 when 2nd kernel
> > bootup during kdump. This will panic 2nd kernel and lead to no vmcore
> > generation. The issue is observed in Meteorlake CPU(cpuid: 0xA06A2):
>
> The previously posted fix is [1].
Thanks for the link, I didn't notice it. For kdump case, as far as I
have tested, only adding (!dmc) check for
intel_dmc_update_dc6_allowed_count() is sufficient to allow kdump to
work.
Thanks,
Tao Liu
>
> Imre, please R-b that. It's a NULL pointer dereference in the wild, in
> stable kernels. We need to get it fixed instead of bikeshedding on
> potential incorrect debugfs results.
>
> BR,
> Jani.
>
>
> [1] https://lore.kernel.org/r/20251202183950.2450315-1-jani.nikula@intel.com
>
>
> >
> > BUG: kernel NULL pointer dereference, address: 0000000000000000
> > #PF: supervisor read access in kernel mode
> > #PF: error_code(0x0000) - not-present page
> > PGD 0 P4D 0
> > Oops: Oops: 0000 [#1] SMP NOPTI
> > ...
> > RIP: 0010:intel_dmc_update_dc6_allowed_count+0x16/0xa0 [i915]
> > ...
> >
> > It is easy to locate the NULL pointer dereference by disassembly:
> >
> > 00000000001171e0 <intel_dmc_update_dc6_allowed_count>:
> > 1171e0: f3 0f 1e fa endbr64
> > 1171e4: e8 00 00 00 00 call 1171e9
> > 1171e9: 41 55 push %r13
> > 1171eb: 41 54 push %r12
> > 1171ed: 55 push %rbp
> > 1171ee: 53 push %rbx
> > 1171ef: 4c 8b a7 18 03 00 00 mov 0x318(%rdi),%r12
> > 1171f6: 49 8b 2c 24 mov (%r12),%rbp
> >
> > To fix this, add a NULL pointer check before dereferencing.
> >
> > Signed-off-by: Tao Liu <ltao@redhat.com>
> > ---
> >
> > The issue doesn't happen in 1st kernel, but in 2nd kernel of kdump. I'm not
> > an expert to i915 and unsure what lead to the NULL pointer. To help further
> > analysis, here is the full stack:
> >
> > [ 8.608520] <TASK>
> > [ 8.610652] gen9_set_dc_state.part.0+0x25d/0x2f0 [i915]
> > [ 8.616096] icl_display_core_init+0x2d/0x620 [i915]
> > [ 8.621266] intel_power_domains_init_hw+0x1b2/0x500 [i915]
> > [ 8.627047] intel_display_driver_probe_noirq+0x87/0x300 [i915]
> > [ 8.633188] i915_driver_probe+0x207/0x5d0 [i915]
> > [ 8.637977] ? drm_privacy_screen_get+0x198/0x1c0
> > [ 8.642832] local_pci_probe+0x41/0x90
> > [ 8.646646] pci_call_probe+0x58/0x160
> > [ 8.650458] ? pci_assign_irq+0x2f/0x160
> > [ 8.654447] ? pci_match_device+0xf8/0x120
> > [ 8.658522] pci_device_probe+0x95/0x140
> > [ 8.662582] call_driver_probe+0x27/0x110
> > [ 8.666570] really_probe+0xcc/0x2c0
> > [ 8.670190] __driver_probe_device+0x78/0x120
> > [ 8.674692] driver_probe_device+0x1f/0xa0
> > [ 8.678857] __driver_attach+0xfa/0x230
> > [ 8.682757] ? __pfx___driver_attach+0x10/0x10
> > [ 8.687185] bus_for_each_dev+0x8e/0xe0
> > [ 8.691159] bus_add_driver+0x11f/0x200
> > [ 8.694970] driver_register+0x72/0xd0
> > [ 8.698853] i915_init+0x26/0x90 [i915]
> > [ 8.702837] ? __pfx_i915_init+0x10/0x10 [i915]
> > [ 8.707433] do_one_initcall+0x5c/0x320
> > [ 8.711409] do_init_module+0x60/0x240
> > [ 8.715132] init_module_from_file+0xd6/0x130
> > [ 8.719634] idempotent_init_module+0x114/0x310
> > [ 8.724241] __x64_sys_finit_module+0x71/0xe0
> > [ 8.728671] do_syscall_64+0x11b/0x6d0
> > [ 8.732483] ? ksys_read+0x6b/0xe0
> > [ 8.735854] ? arch_exit_to_user_mode_prepare.isra.0+0xa2/0xd0
> > [ 8.741768] ? do_syscall_64+0x153/0x6d0
> > [ 8.745828] ? do_syscall_64+0x153/0x6d0
> > [ 8.749814] ? do_syscall_64+0x153/0x6d0
> > [ 8.753800] ? clear_bhb_loop+0x30/0x80
> > [ 8.757700] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> >
> > ---
> > drivers/gpu/drm/i915/display/intel_dmc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c b/drivers/gpu/drm/i915/display/intel_dmc.c
> > index 1006b060c3f3..fd2756badc0c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> > @@ -1578,7 +1578,7 @@ void intel_dmc_update_dc6_allowed_count(struct intel_display *display,
> > struct intel_dmc *dmc = display_to_dmc(display);
> > u32 dc5_cur_count;
> >
> > - if (DISPLAY_VER(dmc->display) < 14)
> > + if (!dmc || DISPLAY_VER(dmc->display) < 14)
> > return;
> >
> > dc5_cur_count = intel_de_read(dmc->display, DG1_DMC_DEBUG_DC5_COUNT);
>
> --
> Jani Nikula, Intel
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Claude review: i915: Fix NULL pointer dereference in intel_dmc_update_dc6_allowed_count()
2026-02-28 13:09 [PATCH] i915: Fix NULL pointer dereference in intel_dmc_update_dc6_allowed_count() Tao Liu
2026-03-02 9:14 ` Jani Nikula
@ 2026-03-03 4:19 ` Claude Code Review Bot
2026-03-03 4:19 ` Claude Code Review Bot
2 siblings, 0 replies; 5+ messages in thread
From: Claude Code Review Bot @ 2026-03-03 4:19 UTC (permalink / raw)
To: dri-devel-reviews
Patch Review
**Correctness: The fix is correct.** The NULL guard before the dereference is the right approach, and early-returning when `dmc` is NULL is the correct behavior — if DMC firmware isn't loaded, there's no DC6 tracking state to update.
```c
- if (DISPLAY_VER(dmc->display) < 14)
+ if (!dmc || DISPLAY_VER(dmc->display) < 14)
```
**Minor suggestions:**
1. **Missing `Fixes:` tag.** A crash fix like this should include a `Fixes:` tag pointing to the commit that introduced `intel_dmc_update_dc6_allowed_count()`. This helps backport tracking.
2. **Missing `Cc: stable@vger.kernel.org`.** Since this is a NULL dereference panic that prevents kdump from generating vmcores, it's a candidate for stable backports.
3. **Style consideration:** The version check uses `dmc->display` when the function already receives `display` as a parameter (and `dmc->display` is the same pointer — set during `intel_dmc_init()`). The function could use `display` directly for the version check and keep the `dmc` NULL check separate for clarity:
```c
if (!dmc || DISPLAY_VER(display) < 14)
return;
```
This makes the two conditions logically distinct: "is DMC available?" vs. "is the display version new enough?" — and avoids dereferencing `dmc` unnecessarily for the version check. However, this is a minor style point and the patch as-is is functionally correct.
4. **Broader observation:** The subagent research found several other functions in `intel_dmc.c` that also dereference `dmc` without a NULL check (e.g., `dmc_load_mmio()`, `dmc_load_program()`, `dmc_configure_event()`). Those are likely safe because they're only called from firmware-loading paths where `dmc` is known non-NULL, but the inconsistency in NULL-checking patterns across the file is worth noting for future hardening.
**Overall: The patch is a valid and minimal crash fix. Recommend adding `Fixes:` and `Cc: stable` tags.**
---
Generated by Claude Code Patch Reviewer
^ permalink raw reply [flat|nested] 5+ messages in thread* Claude review: i915: Fix NULL pointer dereference in intel_dmc_update_dc6_allowed_count()
2026-02-28 13:09 [PATCH] i915: Fix NULL pointer dereference in intel_dmc_update_dc6_allowed_count() Tao Liu
2026-03-02 9:14 ` Jani Nikula
2026-03-03 4:19 ` Claude review: " Claude Code Review Bot
@ 2026-03-03 4:19 ` Claude Code Review Bot
2 siblings, 0 replies; 5+ messages in thread
From: Claude Code Review Bot @ 2026-03-03 4:19 UTC (permalink / raw)
To: dri-devel-reviews
Overall Series Review
Subject: i915: Fix NULL pointer dereference in intel_dmc_update_dc6_allowed_count()
Author: Tao Liu <ltao@redhat.com>
Patches: 3
Reviewed: 2026-03-03T14:19:14.663558
---
This is a single-patch fix for a real NULL pointer dereference crash in `intel_dmc_update_dc6_allowed_count()` during kdump's second kernel boot. The bug is legitimate: `display_to_dmc()` is explicitly documented as potentially returning NULL (`/* Note: This may be NULL. */`), and the caller `gen9_set_dc_state()` invokes this function without any DMC existence check. Many other callers of `display_to_dmc()` in the same file already guard against NULL (e.g., `has_dmc_id_fw()`, `intel_pipedmc_start_mmioaddr()`, `intel_dmc_suspend()`, `intel_dmc_wait_fw_load()`).
The fix is correct and follows the established codebase pattern. A few minor improvements could be suggested.
---
Generated by Claude Code Patch Reviewer
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-03-03 4:19 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-28 13:09 [PATCH] i915: Fix NULL pointer dereference in intel_dmc_update_dc6_allowed_count() Tao Liu
2026-03-02 9:14 ` Jani Nikula
2026-03-02 12:33 ` Tao Liu
2026-03-03 4:19 ` Claude review: " Claude Code Review Bot
2026-03-03 4:19 ` Claude Code Review Bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox