9874808878
An skb can be added to a neigh->arp_queue while waiting for an arp
reply. Where original skb's skb->dev can be different to neigh's
neigh->dev. For instance in case of bridging dnated skb from one veth to
another, the skb would be added to a neigh->arp_queue of the bridge.
As skb->dev can be reset back to nf_bridge->physindev and used, and as
there is no explicit mechanism that prevents this physindev from been
freed under us (for instance neigh_flush_dev doesn't cleanup skbs from
different device's neigh queue) we can crash on e.g. this stack:
arp_process
neigh_update
skb = __skb_dequeue(&neigh->arp_queue)
neigh_resolve_output(..., skb)
...
br_nf_dev_xmit
br_nf_pre_routing_finish_bridge_slow
skb->dev = nf_bridge->physindev
br_handle_frame_finish
Let's use plain ifindex instead of net_device link. To peek into the
original net_device we will use dev_get_by_index_rcu(). Thus either we
get device and are safe to use it or we don't get it and drop skb.
Fixes:
|
||
---|---|---|
.. | ||
arp_tables.c | ||
arpt_mangle.c | ||
arptable_filter.c | ||
ip_tables.c | ||
ipt_ah.c | ||
ipt_ECN.c | ||
ipt_REJECT.c | ||
ipt_rpfilter.c | ||
ipt_SYNPROXY.c | ||
iptable_filter.c | ||
iptable_mangle.c | ||
iptable_nat.c | ||
iptable_raw.c | ||
iptable_security.c | ||
Kconfig | ||
Makefile | ||
nf_defrag_ipv4.c | ||
nf_dup_ipv4.c | ||
nf_nat_h323.c | ||
nf_nat_pptp.c | ||
nf_nat_snmp_basic_main.c | ||
nf_nat_snmp_basic.asn1 | ||
nf_reject_ipv4.c | ||
nf_socket_ipv4.c | ||
nf_tproxy_ipv4.c | ||
nft_dup_ipv4.c | ||
nft_fib_ipv4.c | ||
nft_reject_ipv4.c |