On Thu, 2017-01-26 at 09:32 -0600, Roy Keene wrote:
This bug appears to have existed for a long time:
https://www.spinics.net/lists/netdev/msg222459.html
http://www.kernelhub.org/?p=2&msg=823752
Though possibly with different things not setting the "input" funct
include/net/dst.h:
496 static inline int dst_input(struct sk_buff *skb) {
498 return skb_dst(skb)->input(skb);
499 }
Is there any reason not to check to see if this pointer is NULL before
blindly calling it ?
On Thu, 26 Jan 2017, Roy Keene wrote:
[Resending to netdev from LKML]
%r13
0x8157d7fe pop%r14
0x8157d800 pop%rbp
0x8157d801 retq
This leads me to believe that ((struct dst_entry *)(skb->_skb_refdst &
SKB_DST_PTRMASK))->input is NULL and we are jumping there (callq).
Under what conditions would ((struct dst_entry *)(skb->_skb_refdst &
SKB_DST_PTRMASK))->input be NULL at this point ?
Thanks,
Roy Keene
pop%rbp
0x8157d801 retq
This leads me to believe that ((struct dst_entry *)(skb->_skb_refdst &
SKB_DST_PTRMASK))->input is NULL and we are jumping there (callq).
Under what conditions would ((struct dst_entry *)(skb->_skb_refdst &
SKB_DST_PTRMASK))->input be NULL at this point ?
Thanks,
Roy Keene
e pop%r14
0x8157d800 pop%rbp
0x8157d801 retq
This leads me to believe that ((struct dst_entry *)(skb->_skb_refdst &
SKB_DST_PTRMASK))->input is NULL and we are jumping there (callq).
Under what conditions would ((struct dst_entry *)(skb->_skb_refdst &
SKB_DST_PTRMASK))->input be NULL at this point ?
Thanks,
Roy Keene
