netdev - Re: [PATCH v2] Fix NULL pointer deref due to filtering on fork

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49E824D9-6D96-4FFA-99BD-A1301CE351C0@oracle.com>
Date: Fri, 13 Oct 2023 16:16:20 +0000
From: Anjali Kulkarni <anjali.k.kulkarni@...cle.com>
To: Simon Horman <horms@...nel.org>
CC: open list <linux-kernel@...r.kernel.org>,
        "davem@...emloft.net"
	<davem@...emloft.net>,
        Liam Howlett <liam.howlett@...cle.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "oliver.sang@...el.com"
	<oliver.sang@...el.com>
Subject: Re: [PATCH v2] Fix NULL pointer deref due to filtering on fork



> On Oct 13, 2023, at 5:01 AM, Simon Horman <horms@...nel.org> wrote:
> 
> On Tue, Oct 10, 2023 at 10:12:25PM -0700, Anjali Kulkarni wrote:
>> cn_netlink_send_mult() should be called with filter & filter_data only
>> for EXIT case. For all other events, filter & filter_data should be
>> NULL.
>> 
>> Fixes: 2aa1f7a1f47c ("connector/cn_proc: Add filtering to fix some bugs")
>> Reported-by: kernel test robot <oliver.sang@...el.com>
>> Closes: https://urldefense.com/v3/__https://lore.kernel.org/oe-lkp/202309201456.84c19e27-oliver.sang@intel.com__;!!ACWV5N9M2RV99hQ!PgqlHq_nOe_KlyKkB9Mm_S8QstTJvicjuENwskatuuQK05KPuFw-KvRZeOH8iuEAMjRhkxEMPKJJnLcaT8zrPf9aqNs$
> 
> For the record, this got a bit mangled. I believe it should be:
> 
> Closes: https://lore.kernel.org/oe-lkp/202309201456.84c19e27-oliver.sang@intel.com/
> 
> Also, there is probably no need to resend because of this,
> but no blank line here, please.

Ok.

> 
>> Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@...cle.com>
>> ---
>> drivers/connector/cn_proc.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
>> index 05d562e9c8b1..01e17f18d187 100644
>> --- a/drivers/connector/cn_proc.c
>> +++ b/drivers/connector/cn_proc.c
>> @@ -104,13 +104,13 @@ static inline void send_msg(struct cn_msg *msg)
>> if (filter_data[0] == PROC_EVENT_EXIT) {
>> filter_data[1] =
>> ((struct proc_event *)msg->data)->event_data.exit.exit_code;
>> + cn_netlink_send_mult(msg, msg->len, 0, CN_IDX_PROC, GFP_NOWAIT,
>> +      cn_filter, (void *)filter_data);
>> } else {
>> - filter_data[1] = 0;
>> + cn_netlink_send_mult(msg, msg->len, 0, CN_IDX_PROC, GFP_NOWAIT,
>> +      NULL, NULL);
>> }
>> 
>> - cn_netlink_send_mult(msg, msg->len, 0, CN_IDX_PROC, GFP_NOWAIT,
>> -      cn_filter, (void *)filter_data);
>> -
> 
> I am wondering if you considered making cn_filter slightly smarter.
> It seems it already understands not to do very much for PROC_EVENT_ALL.

I could, but then we would be unnecessarily make an extra function call to cn_filter, and re-check this condition, which can be avoided if we do the check here. 

> 
>> local_unlock(&local_event.lock);
>> }
>> 
>> -- 
>> 2.42.0