| Message ID | 151571803884.27429.7578279171286065970.stgit@dwillia2-desk3.amr.corp.intel.com |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | prevent bounds-check bypass via speculative execution | expand |
On Thu, Jan 11, 2018 at 04:47:18PM -0800, Dan Williams wrote: > Static analysis reports that 'offset' may be a user controlled value > that is used as a data dependency reading from a raw_frag_vec buffer. > In order to avoid potential leaks of kernel memory values, block > speculative execution of the instruction stream that could issue further > reads based on an invalid '*(rfv->c + offset)' value. > > Based on an original patch by Elena Reshetova. There is the "Co-Developed-by:" tag now, if you want to use it... > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> > Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> > Cc: netdev@vger.kernel.org > Signed-off-by: Elena Reshetova <elena.reshetova@intel.com> > Signed-off-by: Dan Williams <dan.j.williams@intel.com> > --- > net/ipv4/raw.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) Ugh, what is this, the 4th time I've said "I don't think this is an issue, so why are you changing this code." to this patch. To be followed by a "oh yeah, you are right, I'll drop it", only to see it show back up in the next time this patch series is sent out? Same for the other patches in this series that I have reviewed 4, maybe 5, times already. The "v2" is not very true here... thanks, greg k-h
On Thu, Jan 11, 2018 at 11:59 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > On Thu, Jan 11, 2018 at 04:47:18PM -0800, Dan Williams wrote: >> Static analysis reports that 'offset' may be a user controlled value >> that is used as a data dependency reading from a raw_frag_vec buffer. >> In order to avoid potential leaks of kernel memory values, block >> speculative execution of the instruction stream that could issue further >> reads based on an invalid '*(rfv->c + offset)' value. >> >> Based on an original patch by Elena Reshetova. > > There is the "Co-Developed-by:" tag now, if you want to use it... Ok, thanks. > >> Cc: "David S. Miller" <davem@davemloft.net> >> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> >> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> >> Cc: netdev@vger.kernel.org >> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com> >> Signed-off-by: Dan Williams <dan.j.williams@intel.com> >> --- >> net/ipv4/raw.c | 10 ++++++---- >> 1 file changed, 6 insertions(+), 4 deletions(-) > > Ugh, what is this, the 4th time I've said "I don't think this is an > issue, so why are you changing this code." to this patch. To be > followed by a "oh yeah, you are right, I'll drop it", only to see it > show back up in the next time this patch series is sent out? > > Same for the other patches in this series that I have reviewed 4, maybe > 5, times already. The "v2" is not very true here... The theme of the review feedback on v1 was 'don't put ifence in any net/ code', and that was addressed. I honestly thought the new definition of array_ptr() changed the calculus on this patch. Given the same pattern appears in the ipv6 case, and I have yet to hear that we should drop the ipv6 patch, make the code symmetric just for readability purposes. Otherwise we need a comment saying why this is safe for ipv4, but maybe not safe for ipv6, I think 'array_ptr' is effectively that comment. I.e. 'array_ptr()' is designed to be low impact for instrumenting false positives. If that new argument does not hold water I will definitely drop this patch.
On Fri, Jan 12, 2018 at 10:47:44AM -0800, Dan Williams wrote: > On Thu, Jan 11, 2018 at 11:59 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > >> Cc: "David S. Miller" <davem@davemloft.net> > >> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> > >> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> > >> Cc: netdev@vger.kernel.org > >> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com> > >> Signed-off-by: Dan Williams <dan.j.williams@intel.com> > >> --- > >> net/ipv4/raw.c | 10 ++++++---- > >> 1 file changed, 6 insertions(+), 4 deletions(-) > > > > Ugh, what is this, the 4th time I've said "I don't think this is an > > issue, so why are you changing this code." to this patch. To be > > followed by a "oh yeah, you are right, I'll drop it", only to see it > > show back up in the next time this patch series is sent out? > > > > Same for the other patches in this series that I have reviewed 4, maybe > > 5, times already. The "v2" is not very true here... > > The theme of the review feedback on v1 was 'don't put ifence in any > net/ code', and that was addressed. > > I honestly thought the new definition of array_ptr() changed the > calculus on this patch. Given the same pattern appears in the ipv6 > case, and I have yet to hear that we should drop the ipv6 patch, make > the code symmetric just for readability purposes. Otherwise we need a > comment saying why this is safe for ipv4, but maybe not safe for ipv6, > I think 'array_ptr' is effectively that comment. I.e. 'array_ptr()' is > designed to be low impact for instrumenting false positives. If that > new argument does not hold water I will definitely drop this patch. I also argued, again in an older review of this same patch series, that the ipv6 patch should be dropped as well for this same exact reason. I didn't think you wanted to hear me rant about the same thing on both patches :) greg k-h
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c index 125c1eab3eaa..91091a10294f 100644 --- a/net/ipv4/raw.c +++ b/net/ipv4/raw.c @@ -57,6 +57,7 @@ #include <linux/in_route.h> #include <linux/route.h> #include <linux/skbuff.h> +#include <linux/nospec.h> #include <linux/igmp.h> #include <net/net_namespace.h> #include <net/dst.h> @@ -472,17 +473,18 @@ static int raw_getfrag(void *from, char *to, int offset, int len, int odd, struct sk_buff *skb) { struct raw_frag_vec *rfv = from; + char *rfv_buf; - if (offset < rfv->hlen) { + rfv_buf = array_ptr(rfv->hdr.c, offset, rfv->hlen); + if (rfv_buf) { int copy = min(rfv->hlen - offset, len); if (skb->ip_summed == CHECKSUM_PARTIAL) - memcpy(to, rfv->hdr.c + offset, copy); + memcpy(to, rfv_buf, copy); else skb->csum = csum_block_add( skb->csum, - csum_partial_copy_nocheck(rfv->hdr.c + offset, - to, copy, 0), + csum_partial_copy_nocheck(rfv_buf, to, copy, 0), odd); odd = 0;