nfqueue max copy_range broken, how to fix/mitigate?

nfqueue max copy_range broken, how to fix/mitigate?

[Florian Westphal]

nf_queue claims to support copy size of up to 0xffff:

case NFQNL_COPY_PACKET:
        /* we're using struct nlattr which has 16bit nla_len */
        if (range > 0xffff)
               queue->copy_range = 0xffff;

Which is incorrect, as the maximum attribute size is 0xffff - NLA_HDRLEN.
Thus, when trying to queue a maximum-sized IP packet, you get
NFQA_PAYLOAD with nla->len = 4 (due to overflow), i.e. no payload at
all.

Since this is a limitation of netlink this isn't fixable in nfqueue.
How to best handle this situation?

We can either truncate and queue 0xffff - NLA_HDRLEN (i.e., cut off 4
bytes from what will be queued), or we could refuse to queue the packet
(userspace asked for the full packet, but we can't fullfill the
 request).

Any ideas/suggestions?

Thanks,
Florian

Re: nfqueue max copy_range broken, how to fix/mitigate?

[Florian Westphal]

Florian Westphal <fw@strlen.de> wrote:
> Since this is a limitation of netlink this isn't fixable in nfqueue.
> How to best handle this situation?
> 
> We can either truncate and queue 0xffff - NLA_HDRLEN (i.e., cut off 4
> bytes from what will be queued), or we could refuse to queue the packet
> (userspace asked for the full packet, but we can't fullfill the
>  request).

Another method would be to "fix" this in userspace by checking
for attr->nla_len < NLA_HDRLEN in combination with
mnl_nlmsg_get_payload_tail(nlh) - (char *) attr >= 0xffff and then
assuming that the next attribute is at 0xffff - attr->nla_len instead
of attr->nla_len.

But that would mean cramming very ugly code into libmnl et al.