From: Jiri Slaby <jirislaby@kernel.org>
To: Osama Abdelkader <osama.abdelkader@gmail.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sjur Braendeland <sjur.brandeland@stericsson.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: syzbot+f9d847b2b84164fa69f3@syzkaller.appspotmail.com,
stable@vger.kernel.org
Subject: Re: [PATCH v2] net: caif: fix memory leak in ldisc_receive
Date: Mon, 19 Jan 2026 08:00:37 +0100 [thread overview]
Message-ID: <ed294369-e463-4d4b-83c8-43df0e24c014@kernel.org> (raw)
In-Reply-To: <9a7c53ac-d208-457f-9940-ca821b08df1e@kernel.org>
On 19. 01. 26, 7:58, Jiri Slaby wrote:
> On 18. 01. 26, 18:44, Osama Abdelkader wrote:
>> Add NULL pointer checks for ser and ser->dev in ldisc_receive() to
>> prevent memory leaks when the function is called during device close
>> or in race conditions where tty->disc_data or ser->dev may be NULL.
>>
>> The memory leak occurred because ser->dev was accessed before checking
>> if ser or ser->dev was NULL, which could cause a NULL pointer
>> dereference or use of freed memory. Additionally, set tty->disc_data
>> to NULL in ldisc_close() to prevent receive_buf() from using a freed
>> ser pointer after the line discipline is closed.
>>
>> Reported-by: syzbot+f9d847b2b84164fa69f3@syzkaller.appspotmail.com
>> Closes: https://syzkaller.appspot.com/bug?extid=f9d847b2b84164fa69f3
>> Fixes: 9b27105b4a44 ("net-caif-driver: add CAIF serial driver (ldisc)")
>> CC: stable@vger.kernel.org
>> Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
>> ---
>> v2:
>> 1.Combine NULL pointer checks for ser and ser->dev in ldisc_receive()
>> 2.Set tty->disc_data = NULL in ldisc_close() to prevent receive_buf()
>> from using a freed ser pointer after close.
>> 3.Add NULL pointer check for ser in ldisc_close()
>> ---
>> drivers/net/caif/caif_serial.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/
>> caif_serial.c
>> index c398ac42eae9..970237a3ccca 100644
>> --- a/drivers/net/caif/caif_serial.c
>> +++ b/drivers/net/caif/caif_serial.c
>> @@ -152,6 +152,8 @@ static void ldisc_receive(struct tty_struct *tty,
>> const u8 *data,
>> int ret;
>> ser = tty->disc_data;
>> + if (!ser || !ser->dev)
>> + return;
>> /*
>> * NOTE: flags may contain information about break or overrun.
>> @@ -170,8 +172,6 @@ static void ldisc_receive(struct tty_struct *tty,
>> const u8 *data,
>> return;
>> }
>> - BUG_ON(ser->dev == NULL);
>> -
>> /* Get a suitable caif packet and copy in data. */
>> skb = netdev_alloc_skb(ser->dev, count+1);
>
> Wait, the reported error is memory leak of mem allocated here. So both
> ser and ser->dev appear to be valid?
>
> So instead, does netif_rx() return an error few lines below for some
> reason? So should skb just be freed in that path?
>
> if (skb == NULL)
> return;
> skb_put_data(skb, data, count);
>
> skb->protocol = htons(ETH_P_CAIF);
> skb_reset_mac_header(skb);
> debugfs_rx(ser, data, count);
> /* Push received packet up the stack. */
> ret = netif_rx(skb);
> if (!ret) {
> ser->dev->stats.rx_packets++;
> ser->dev->stats.rx_bytes += count;
> } else
> ++ser->dev->stats.rx_dropped;
>
> Not calling skb_free() in this else path _is_ a BUG™ in any case IMO.
No, it's not: netif_rx() always eats the buffer. So care to elaborate
why the socket buffer is actually leaked?
> thanks,
--
js
suse labs
next prev parent reply other threads:[~2026-01-19 7:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-18 17:44 [PATCH v2] net: caif: fix memory leak in ldisc_receive Osama Abdelkader
2026-01-19 6:25 ` Jiri Slaby
2026-01-19 6:36 ` Greg Kroah-Hartman
2026-01-19 6:58 ` Jiri Slaby
2026-01-19 7:00 ` Jiri Slaby [this message]
2026-01-24 19:10 ` Osama Abdelkader
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=ed294369-e463-4d4b-83c8-43df0e24c014@kernel.org \
--to=jirislaby@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=osama.abdelkader@gmail.com \
--cc=pabeni@redhat.com \
--cc=sjur.brandeland@stericsson.com \
--cc=stable@vger.kernel.org \
--cc=syzbot+f9d847b2b84164fa69f3@syzkaller.appspotmail.com \
/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.