CVE-2026-68287

What it actually does

Incorrect SKB size budgeting in net_dm_packet_report_size and net_dm_hw_packet_report_size underestimates space needed for 64-bit attributes on 32-bit architectures, allowing skb_over_panic when nla_put_u64_64bit later reserves or appends data.

Why it matters to the business

Kernel panics on 32-bit Linux systems can cause abrupt service outages, loss of network monitoring data, and require manual restarts, increasing operational downtime especially in environments with high packet drop reporting.

How an attack unfolds

An attacker or workload triggers drop_monitor packet reporting paths that invoke nla_put_u64_64bit for NET_DM_ATTR_PC or NET_DM_ATTR_TIMESTAMP; on affected 32-bit kernels the pre-calculated SKB size is too small, so the subsequent __nla_reserve or skb_put call panics the kernel.

How to fix it

Update the Linux kernel to a version containing the fix that replaces nla_total_size(sizeof(u64)) with nla_total_size_64bit(sizeof(u64)) in both report size calculation functions; rebuild and deploy the updated kernel image.

How to confirm the fix worked

Confirm the source change in net/core/drop_monitor.c shows nla_total_size_64bit usage, then boot the patched kernel and exercise drop_monitor reporting paths while monitoring for absence of skb_over_panic.

Typical attack path

1. Gain local execution or induce network conditions that cause monitored packet drops
2. Force invocation of net_dm_packet_report_fill or net_dm_hw_packet_report_fill
3. Trigger nla_put_u64_64bit for 64-bit attributes on 32-bit architecture without efficient unaligned access
4. Cause skb_over_panic due to undersized allocation

How to detect it

Review kernel logs for skb_over_panic or warnings from net_dm_packet_report_fill after enabling drop_monitor; correlate with 32-bit architecture systems and recent packet drop events.

What your security team should do

• Prioritize kernel updates on all 32-bit Linux deployments that enable CONFIG_NET_DROP_MONITOR
• Test patched kernels in staging environments that replicate production drop_monitor usage
• Monitor upstream stable branches for backported fixes and schedule rollout before the next maintenance window