All of lore.kernel.org
 help / color / mirror / Atom feed
From: Davide Caratti <dcaratti@redhat.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org, Florian Westphal <fw@strlen.de>,
	Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Subject: Re: [PATCH nf] netfilter: conntrack: fix false CRC32c mismatch using paged skb
Date: Tue, 23 May 2017 15:51:05 +0200	[thread overview]
Message-ID: <1495547465.3148.10.camel@redhat.com> (raw)
In-Reply-To: <1495193970.2897.48.camel@redhat.com>

hello Pablo,
On Fri, 2017-05-19 at 13:39 +0200, Davide Caratti wrote:
> On Fri, 2017-05-19 at 10:41 +0200, Pablo Neira Ayuso wrote:
> > I mean, I can see other spots in the kernel tree that may be affected by this?
> > Or is it that you're only observing this from a path that is specific
> > of conntrack?
> 
> I did the check before posting, and the kernel code seemed to already
> ensure skb is writable until SCTP header + sizeof(SCTP header) offset,
> before calling sctp_compute_cksum(). Just to be sure, I re-did that check
> today: besides nf_conntrack sctp_error(), I'm only doubtful about IPVS
> sctp_csum_check() (but I don't have a test scenario yet).

looking at IPVS code: it seems to me that the only call to sctp_csum_check()
is inside sctp_snat_handler(), after skb_make_writable() has returned
successfully.  So, apparently misuse of sctp_compute_cksum() affects only
nf_conntrack module in sctp_error() callback.

Maybe this patch needs 'Fixes: cf6e007eef83 ("netfilter: conntrack: validate
SCTP crc32c in PREROUTING")' tag ?

thanks!
--
davide


  reply	other threads:[~2017-05-23 13:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18 16:01 [PATCH nf] netfilter: conntrack: fix false CRC32c mismatch using paged skb Davide Caratti
2017-05-19  8:41 ` Pablo Neira Ayuso
2017-05-19 11:39   ` Davide Caratti
2017-05-23 13:51     ` Davide Caratti [this message]
2017-05-23 19:35       ` Pablo Neira Ayuso
2017-05-23 21:29         ` Pablo Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1495547465.3148.10.camel@redhat.com \
    --to=dcaratti@redhat.com \
    --cc=fw@strlen.de \
    --cc=marcelo.leitner@gmail.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.