Skip to content

tty: n_gsm: fix possible out-of-bounds in gsm0_receive()

Steve Best requested to merge sfbest/centos-stream-9:39354 into main

JIRA: https://issues.redhat.com/browse/RHEL-39354
CVE: CVE-2024-36016

Build Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=61572658
Tested: Did sanity boot testing Intel (intel-arrowlake-s-02) system.

commit 47388e807f85948eefc403a8a5fdc5b406a65d5a
Author: Daniel Starke daniel.starke@siemens.com
Date: Wed Apr 24 07:48:41 2024 +0200

tty: n_gsm: fix possible out-of-bounds in gsm0_receive()  

Assuming the following:  
- side A configures the n_gsm in basic option mode  
- side B sends the header of a basic option mode frame with data length 1  
- side A switches to advanced option mode  
- side B sends 2 data bytes which exceeds gsm->len  
  Reason: gsm->len is not used in advanced option mode.  
- side A switches to basic option mode  
- side B keeps sending until gsm0_receive() writes past gsm->buf  
  Reason: Neither gsm->state nor gsm->len have been reset after  
  reconfiguration.  

Fix this by changing gsm->count to gsm->len comparison from equal to less  
than. Also add upper limit checks against the constant MAX_MRU in  
gsm0_receive() and gsm1_receive() to harden against memory corruption of  
gsm->len and gsm->mru.  

All other checks remain as we still need to limit the data according to the  
user configuration and actual payload size.  

Reported-by: j51569436@gmail.com  
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218708  
Tested-by: j51569436@gmail.com  
Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")  
Cc: stable@vger.kernel.org  
Signed-off-by: Daniel Starke <daniel.starke@siemens.com>  
Link: https://lore.kernel.org/r/20240424054842.7741-1-daniel.starke@siemens.com  
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Steve Best sbest@redhat.com

Merge request reports