linux-kernel - RE: [PATCH 7/9] tty: n_gsm: increase gsm_mux unsupported counted where appropriate

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: <AS4PR10MB58955AB89CC251446B7509CBE0919@AS4PR10MB5895.EURPRD10.PROD.OUTLOOK.COM>
Date:   Thu, 6 Apr 2023 05:57:05 +0000
From:   "Starke, Daniel" <daniel.starke@...mens.com>
To:     Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
CC:     linux-serial <linux-serial@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 7/9] tty: n_gsm: increase gsm_mux unsupported counted
 where appropriate

> > From: Daniel Starke <daniel.starke@...mens.com>
> > 
> > The structure gsm_mux contains the 'unsupported' field. However, there is
> > currently no place in the code which increases this counter.
> > 
> > Increase the 'unsupported' statistics counter in the following case:
> > - an unsupported frame type has been requested by the peer via parameter
> >   negotiation
> > - a control frame with an unsupported but known command has been received
> 
> So inconsistent/unsupported adaptation doesn't fall under the second 
> bullet?
> 
> (Please excuse my ignorance, I'm trying to review your patches with 
> somewhat limited knowledge about how things work).

A wrong adaption is nothing we can detect with sufficient accuracy as this
changes the structure of the UI/UIH frames. E.g. a one byte header is added
in case of convergence layer type 2 instead of 1 and contains the modem
signal octet with the state of the signal lines. There is no checksum or
other value which indicates of this field is correct or should be present.
Therefore, we can only assume protocol correctness here.
See also function 'gsm_dlci_data' where this is handled.

Best regards,
Daniel Starke