[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB9PR10MB58813E33D3516BAB526156B1E0659@DB9PR10MB5881.EURPRD10.PROD.OUTLOOK.COM>
Date: Wed, 10 Aug 2022 09:08:13 +0000
From: "Starke, Daniel" <daniel.starke@...mens.com>
To: Mazin Al Haddad <mazinalhaddad05@...il.com>
CC: "jirislaby@...nel.org" <jirislaby@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-kernel-mentees@...ts.linuxfoundation.org"
<linux-kernel-mentees@...ts.linuxfoundation.org>,
"skhan@...uxfoundation.org" <skhan@...uxfoundation.org>,
"paskripkin@...il.com" <paskripkin@...il.com>,
"syzbot+e3563f0c94e188366dbb@...kaller.appspotmail.com"
<syzbot+e3563f0c94e188366dbb@...kaller.appspotmail.com>,
Greg KH <gregkh@...uxfoundation.org>
Subject: RE: [PATCH] tty: n_gsm: fix missing assignment of gsm->receive() in
gsmld_attach_gsm()
> Fix this by setting the gsm->receive() function when the line
> discipline is being attached to the terminal device, inside
> gsmld_attach_gsm(). This will guarantee that the function is assigned
> and a call to TIOCSTI, which calls gsmld_receive_buf(), will not
> reference a null pointer.
In my opinion there are only two possible ways to fix this:
a) Move the gsm->receive initialization from gsm_activate_mux() to
gsmld_attach_gsm().
b) Avoid calling gsm->receive in gsmld_receive_buf() if not initialized.
The current code might assume that gsm->receive is only called after MUX
activation. Therefore, variant a) may break the code in other places.
I see no need to initialize gsm->receive in gsm_activate_mux() and
gsmld_attach_gsm().
Best regards,
Daniel Starke
Powered by blists - more mailing lists