lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 24 Jul 2012 03:24:38 +0300 (EEST) From: Julian Anastasov <ja@....bg> To: David Miller <davem@...emloft.net> cc: netdev@...r.kernel.org Subject: Re: [PATCH 2/2] ipv4: Change rt->rt_iif encoding. Hello, On Mon, 23 Jul 2012, David Miller wrote: > Hmmm, the problem is that when we decapsulate VLAN devices, we're left > with the parent device's index in skb->skb_iif. Not sure if it is a problem with VLANs, can be also with some virtual devices but may be they use dev_forward_skb() where skb_iif is zeroed. > That's what all of that "orig_dev" logic in __netif_receive_skb() is > all about. The skb->dev is rewritten by vlan_do_receive() for that > case. This is the part that I didn't know for skb_iif. I was also worrying about ip_mc_output looping packets with skb_iif because skb_clone copies the field but may be such loops happen only for locally originated traffic where skb_iif starts with 0. Still, the comment in ipmr_queue_xmit() and the IPSKB_FORWARDED bit puzzles me: * RFC1584 teaches, that DVMRP/PIM router must deliver packets locally * not only before forwarding, but after forwarding on all output * interfaces. It is clear, if mrouter runs a multicasting ip_mr_forward preserves one copy to local app, calls ipmr_queue_xmit() where packet can be looped? ip_mr_input(): /* Packet is looped back after forward, it should not be * forwarded second time, but still can be delivered locally. */ I really hope the case is for locally originated multicast, not for packets received from network. > I wonder if we should just get rid of all of that orig_dev logic and > simply update skb->skb_iif every time we hit the code starting at > label "another_round" I don't have opinion about this problem. I see your new change for __netif_receive_skb, the skb_iif places are something that I have to check for me... Regards -- Julian Anastasov <ja@....bg> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists