Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

Hi Sabrina, On Fri, Apr 28, 2017 at 6:18 PM, Sabrina Dubroca wrote: > One small thing here: since you're touching this comment, could you > move it next to skb_to_sgvec, since that's the function it's supposed > to document? Done. I'll wait until next week to resubmit, to

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

Hi Sabrina, On Fri, Apr 28, 2017 at 6:18 PM, Sabrina Dubroca wrote: > One small thing here: since you're touching this comment, could you > move it next to skb_to_sgvec, since that's the function it's supposed > to document? Done. I'll wait until next week to resubmit, to give some more time

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

2017-04-25, 20:47:30 +0200, Jason A. Donenfeld wrote: > This is a defense-in-depth measure in response to bugs like > 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). While > we're at it, we also limit the amount of recursion this function is > allowed to do. Not actually providing a

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

2017-04-25, 20:47:30 +0200, Jason A. Donenfeld wrote: > This is a defense-in-depth measure in response to bugs like > 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). While > we're at it, we also limit the amount of recursion this function is > allowed to do. Not actually providing a

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

From: "Jason A. Donenfeld" Date: Thu, 27 Apr 2017 11:21:51 +0200 > Hey Dave, > > David Laight and I have been discussing offlist. It occurred to both > of us that this could just be turned into a loop because perhaps this > is actually just tail-recursive. Upon further

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

From: "Jason A. Donenfeld" Date: Thu, 27 Apr 2017 11:21:51 +0200 > Hey Dave, > > David Laight and I have been discussing offlist. It occurred to both > of us that this could just be turned into a loop because perhaps this > is actually just tail-recursive. Upon further inspection, however, the

RE: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

From: Jason A. Donenfeld > On Thu, Apr 27, 2017 at 1:30 PM, Sabrina Dubroca wrote: > > Hmm, I think this can actually happen: > > Alright, perhaps better to err on the side of caution, then. You only need to recurse if both pointers are set. David

RE: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

From: Jason A. Donenfeld > On Thu, Apr 27, 2017 at 1:30 PM, Sabrina Dubroca wrote: > > Hmm, I think this can actually happen: > > Alright, perhaps better to err on the side of caution, then. You only need to recurse if both pointers are set. David

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

On Thu, Apr 27, 2017 at 1:30 PM, Sabrina Dubroca wrote: > Hmm, I think this can actually happen: Alright, perhaps better to err on the side of caution, then. Jason

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

On Thu, Apr 27, 2017 at 1:30 PM, Sabrina Dubroca wrote: > Hmm, I think this can actually happen: Alright, perhaps better to err on the side of caution, then. Jason

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

2017-04-27, 11:21:51 +0200, Jason A. Donenfeld wrote: > However, perhaps there's the chance that fraglist skbs having > separate fraglists are actually forbidden? Is this the case? Hmm, I think this can actually happen: /* net/ipv4/ip_fragment.c */ static int ip_frag_reasm(struct ipq

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

2017-04-27, 11:21:51 +0200, Jason A. Donenfeld wrote: > However, perhaps there's the chance that fraglist skbs having > separate fraglists are actually forbidden? Is this the case? Hmm, I think this can actually happen: /* net/ipv4/ip_fragment.c */ static int ip_frag_reasm(struct ipq

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

Hey Dave, David Laight and I have been discussing offlist. It occurred to both of us that this could just be turned into a loop because perhaps this is actually just tail-recursive. Upon further inspection, however, the way the current algorithm works, it's possible that each of the fraglist skbs

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

Hey Dave, David Laight and I have been discussing offlist. It occurred to both of us that this could just be turned into a loop because perhaps this is actually just tail-recursive. Upon further inspection, however, the way the current algorithm works, it's possible that each of the fraglist skbs

[PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

This is a defense-in-depth measure in response to bugs like 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). While we're at it, we also limit the amount of recursion this function is allowed to do. Not actually providing a bounded base case is a future diaster that we can easily avoid

[PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

This is a defense-in-depth measure in response to bugs like 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). While we're at it, we also limit the amount of recursion this function is allowed to do. Not actually providing a bounded base case is a future diaster that we can easily avoid