On Thu, Jan 11, 2018 at 11:59 PM, Greg KH [off-list ref] wrote:

On Thu, Jan 11, 2018 at 04:47:18PM -0800, Dan Williams wrote:

quoted

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.

quoted

Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <redacted>
Cc: Hideaki YOSHIFUJI <redacted>
Cc: netdev@vger.kernel.org
Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Dan Williams <redacted>
---
 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.