CVE-2024-56671

What it actually does

The vulnerability allows unauthorized modification of a const-qualified irq_chip.name field in the gpio_graniterapids driver, triggering a supervisor write page fault and kernel crash during probe.

Why it matters to the business

Affected systems may experience boot failures and downtime on supported hardware. Low urgency given no KEV listing, ransomware use, or meaningful EPSS increase.

How an attack unfolds

Local interaction with the driver during module initialization causes the crash; no remote vector, code execution, or privilege escalation path is present.

How to fix it

Upgrade the Linux kernel to commit e631cab10c6b287a33c35953e6dbda1f7f89bc1f or apply the listed fixed package versions for affected distributions.

How to confirm the fix worked

Confirm the running kernel contains the fix commit, then verify clean boot and module probe on graniterapids hardware without page-fault crashes.

Typical attack path

1. Obtain local access to a system using the graniterapids GPIO driver
2. Trigger udev or module load that invokes gnr_gpio_probe
3. Induce the const write fault to crash the kernel

How to detect it

Search kernel logs and dmesg for page-fault entries referencing gnr_gpio_probe and gpio_graniterapids during early boot or udev activity.

• BUG: unable to handle page fault for address
• gnr_gpio_probe+0x171/0x220 [gpio_graniterapids]
• #PF: supervisor write access in kernel mode

What your security team should do

• Apply the kernel fix on all systems using the affected GPIO driver
• Prioritize updates on production boot-critical servers
• Review similar const-handling patterns in other GPIO drivers