CVE-2026-98419: drop_monitor: fix out-of-bounds write in reset_per_cpu_data()
In the Linux kernel, the following vulnerability has been resolved:
dropmonitor: fix out-of-bounds write in resetpercpudata()
In resetpercpudata(), al is computed as:
al = sizeof(struct netdmalertmsg); al += dmhitlimit sizeof(struct netdmdroppoint); al += sizeof(struct nlattr);
skb = genlmsgnew(al, GFPKERNEL); ... nla = nlareserve(skb, NLAUNSPEC, sizeof(struct netdmalertmsg)); ... msg = nladata(nla); memset(msg, 0, al);
Because al includes sizeof(struct nlattr) (the 4-byte attribute header), genlmsgnew() allocates al bytes of tailroom starting at nla. However, msg points to nladata(nla), which is located sizeof(struct nlattr) bytes past nla. Calling memset(msg, 0, al) therefore writes al bytes starting from msg, exceeding the allocated buffer by sizeof(struct nlattr) (4 bytes) and corrupting skbsharedinfo.
Fix this by letting al represent only the payload length, allocating the skb with genlmsgnew(nlatotalsize(al), GFPKERNEL), and zeroing al bytes from msg.
Affected Software
Event History
Frequently Asked Questions
What must occur for the overwrite to happen?
The affected reset_per_cpu_data() path must allocate the generic-netlink skb and then zero the alert-message buffer. The provided data does not specify the attacker’s access level, interface, or other prerequisites for reaching this path.
What is the immediate effect of the memory overwrite?
The memset starts at the netlink attribute payload but uses a length that also includes the attribute header. This writes four bytes beyond the allocated buffer and corrupts skb_shared_info.
How can I check whether a kernel source tree contains the fix?
In the corrected code, al represents only the payload length, the allocation uses genlmsg_new(nla_total_size(al), GFP_KERNEL), and memset zeros al bytes from the payload pointer. Vulnerable code instead allocates with genlmsg_new(al, GFP_KERNEL) while al includes sizeof(struct nlattr).