CVE-2023-54049

What it actually does

Missing validation of kstrdup() return value in the rpmsg glink driver allows a NULL pointer dereference when allocation fails, resulting in kernel memory corruption or crash.

Why it matters to the business

Affected Linux-based systems may experience sudden crashes or loss of inter-processor messaging functionality, causing unplanned downtime and service disruption.

How an attack unfolds

An attacker triggers the allocation failure path in the rpmsg glink driver through crafted inputs or memory pressure, causing the kernel to dereference a NULL pointer and panic.

How to fix it

Update to fixed versions: vault-benchmark and vault-benchmark-compat to 0.3.0-r36 on Chainguard or Wolfi; Linux kernel to commit 5197498c902502127a47abda5359dd7f1d41946f or later stable releases containing the check.

How to confirm the fix worked

Verify the presence of the kstrdup return-value check in the rpmsg glink source after patching; confirm no NULL dereference occurs under allocation-failure test conditions.

Typical attack path

1. Identify systems running vulnerable kernel versions with rpmsg glink enabled
2. Induce memory pressure or supply inputs that cause kstrdup to fail
3. Trigger the unchecked return value leading to NULL dereference
4. Cause kernel panic or denial of service

How to detect it

Review kernel logs for oops or panic messages containing rpmsg_glink or kstrdup; inspect crash dumps for NULL dereference in the glink driver path.

What your security team should do

• Apply the listed kernel and package updates as soon as possible
• Prioritize systems that use rpmsg or inter-processor communication
• Monitor for kernel oops/panic events referencing rpmsg glink
• Reboot systems after patching to load fixed kernel