All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Colin King <colin.king@canonical.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	"David S . Miller" <davem@davemloft.net>,
	linux-can@vger.kernel.org, netdev <netdev@vger.kernel.org>,
	kernel-janitors@vger.kernel.org,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] can: check for null sk before deferencing it via the call to sock_net
Date: Mon, 16 Oct 2017 19:32:25 +0200	[thread overview]
Message-ID: <c50ebff0-233c-7dcf-1b80-19ac0369803a@hartkopp.net> (raw)
In-Reply-To: <CA+5PVA7fJfZmN-XLuqARGkWL6eY54HaRAj19K_Und3K7vAVfpg@mail.gmail.com>

On 10/16/2017 06:37 PM, Josh Boyer wrote:
> On Fri, Sep 8, 2017 at 1:46 PM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>>
>>
>> On 09/08/2017 05:02 PM, Colin King wrote:
>>>
>>> From: Colin Ian King <colin.king@canonical.com>
>>>
>>> The assignment of net via call sock_net will dereference sk. This
>>> is performed before a sanity null check on sk, so there could be
>>> a potential null dereference on the sock_net call if sk is null.
>>> Fix this by assigning net after the sk null check. Also replace
>>> the sk == NULL with the more usual !sk idiom.
>>>
>>> Detected by CoverityScan CID#1431862 ("Dereference before null check")
>>>
>>> Fixes: 384317ef4187 ("can: network namespace support for CAN_BCM
>>> protocol")
>>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>>
>>
>> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
> 
> I don't see this one queued up in the net or net-next trees.  Did it
> fall through the cracks or did it get queued up elsewhere?  Seems like
> it's a good candidate to get into 4.14?

It definitely is!

Marc is our responsible guy for CAN related upstreams - but he seems to 
be busy as I already poked him here:

https://marc.info/?l=linux-can&m=150771819505097&w=2

If he doesn't send a pull request by beginning of next week, I would ask 
Dave to grab these patches - to get them into 4.14.

Best regards,
Oliver

WARNING: multiple messages have this Message-ID (diff)
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Colin King <colin.king@canonical.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	"David S . Miller" <davem@davemloft.net>,
	linux-can@vger.kernel.org, netdev <netdev@vger.kernel.org>,
	kernel-janitors@vger.kernel.org,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] can: check for null sk before deferencing it via the call to sock_net
Date: Mon, 16 Oct 2017 17:32:25 +0000	[thread overview]
Message-ID: <c50ebff0-233c-7dcf-1b80-19ac0369803a@hartkopp.net> (raw)
In-Reply-To: <CA+5PVA7fJfZmN-XLuqARGkWL6eY54HaRAj19K_Und3K7vAVfpg@mail.gmail.com>

On 10/16/2017 06:37 PM, Josh Boyer wrote:
> On Fri, Sep 8, 2017 at 1:46 PM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>>
>>
>> On 09/08/2017 05:02 PM, Colin King wrote:
>>>
>>> From: Colin Ian King <colin.king@canonical.com>
>>>
>>> The assignment of net via call sock_net will dereference sk. This
>>> is performed before a sanity null check on sk, so there could be
>>> a potential null dereference on the sock_net call if sk is null.
>>> Fix this by assigning net after the sk null check. Also replace
>>> the sk = NULL with the more usual !sk idiom.
>>>
>>> Detected by CoverityScan CID#1431862 ("Dereference before null check")
>>>
>>> Fixes: 384317ef4187 ("can: network namespace support for CAN_BCM
>>> protocol")
>>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>>
>>
>> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
> 
> I don't see this one queued up in the net or net-next trees.  Did it
> fall through the cracks or did it get queued up elsewhere?  Seems like
> it's a good candidate to get into 4.14?

It definitely is!

Marc is our responsible guy for CAN related upstreams - but he seems to 
be busy as I already poked him here:

https://marc.info/?l=linux-can&m\x150771819505097&w=2

If he doesn't send a pull request by beginning of next week, I would ask 
Dave to grab these patches - to get them into 4.14.

Best regards,
Oliver



  reply	other threads:[~2017-10-16 17:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-08 15:02 [PATCH] can: check for null sk before deferencing it via the call to sock_net Colin King
2017-09-08 15:02 ` Colin King
2017-09-08 17:46 ` Oliver Hartkopp
2017-09-08 17:46   ` Oliver Hartkopp
     [not found]   ` <CABATaM548q4dghmPgrh9qd7+q9Nq1UgA+ESXOrW+45gBWxdq3w@mail.gmail.com>
2017-10-11 10:35     ` Oliver Hartkopp
2017-10-16 16:37   ` Josh Boyer
2017-10-16 16:37     ` Josh Boyer
2017-10-16 17:32     ` Oliver Hartkopp [this message]
2017-10-16 17:32       ` Oliver Hartkopp
2017-10-17  5:49 ` Marc Kleine-Budde
2017-10-17  5:49   ` Marc Kleine-Budde

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=c50ebff0-233c-7dcf-1b80-19ac0369803a@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=colin.king@canonical.com \
    --cc=davem@davemloft.net \
    --cc=jwboyer@fedoraproject.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.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.