From: Marcelo Ricardo Leitner <mleitner@redhat.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] Make use of pr_fmt where applicable
Date: Tue, 28 Oct 2014 18:16:47 -0200 [thread overview]
Message-ID: <544FF9AF.10105@redhat.com> (raw)
In-Reply-To: <20141028201220.GA26565@salvia>
On 28-10-2014 18:12, Pablo Neira Ayuso wrote:
> On Tue, Oct 28, 2014 at 05:56:31PM -0200, Marcelo Ricardo Leitner wrote:
>> Hi Pablo,
>>
>> While we are at this, what about this one, does it really have to be a BUG() one?
>>
>> __build_packet_message()
>> ...
>> if (data_len) {
>> struct nlattr *nla;
>> int size = nla_attr_size(data_len);
>>
>> if (skb_tailroom(inst->skb) < nla_total_size(data_len))
>> goto nla_put_failure; <-- already changed
>>
>> nla = (struct nlattr *)skb_put(inst->skb, nla_total_size(data_len));
>> nla->nla_type = NFULA_PAYLOAD;
>> nla->nla_len = size;
>>
>> if (skb_copy_bits(skb, 0, nla_data(nla), data_len))
>> BUG(); <--
>> }
>>
>> Seems we could just put a goto nla_put_failure there too instead of
>> bringing everything down. skb_copy_bits will only fail if we try to
>> copy too much from the skb.. We could leave a WARN_ONCE in there if
>> the idea is to catch nasty bugs in there. WDYT? I'm thinking in just
>> sticking with a goto in there too.
>
> I think this is most likely catching a malformed skbuff coming from
> the driver, in that case we shouldn't go further. There's similar
> handling in other part of the kernel.
>
> This may also trigger the BUG() if data_len is miscalculated as you
> said, but that seems less likely to happen to me.
>
> I would leave that one as it is.
Cool, thanks.
Marcelo
next prev parent reply other threads:[~2014-10-28 20:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 12:59 [PATCH 1/3] Introduce nft_log_dereference() macro Marcelo Ricardo Leitner
2014-10-24 12:59 ` [PATCH v2 2/3] netfilter: log: protect nf_log_register against double registering Marcelo Ricardo Leitner
2014-10-27 22:09 ` Pablo Neira Ayuso
2014-10-28 12:51 ` Marcelo Ricardo Leitner
2014-10-24 12:59 ` [PATCH 3/3] Make use of pr_fmt where applicable Marcelo Ricardo Leitner
2014-10-24 18:11 ` Marcelo Ricardo Leitner
2014-10-24 18:27 ` Marcelo Ricardo Leitner
[not found] ` <12a99ae77aa9969692d847d8d2929deb13485e72.1414175014.git.mleitner@redhat.com>
2014-10-24 18:46 ` [PATCH v2 " Marcelo Ricardo Leitner
2014-10-27 22:23 ` Pablo Neira Ayuso
2014-10-28 12:59 ` Marcelo Ricardo Leitner
2014-10-28 19:56 ` Marcelo Ricardo Leitner
2014-10-28 20:12 ` Pablo Neira Ayuso
2014-10-28 20:16 ` Marcelo Ricardo Leitner [this message]
2014-10-27 22:03 ` [PATCH 1/3] Introduce nft_log_dereference() macro Pablo Neira Ayuso
2014-10-28 12:47 ` Marcelo Ricardo Leitner
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=544FF9AF.10105@redhat.com \
--to=mleitner@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).