linux-kernel - RE: [PATCH v2] tty: n_gsm: avoid call of sleeping functions from atomic context

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]

Date:   Wed, 5 Oct 2022 10:47:44 +0000
From:   "Starke, Daniel" <daniel.starke@...mens.com>
To:     Fedor Pchelkin <pchelkin@...ras.ru>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Alexey Khoroshilov <khoroshilov@...ras.ru>,
        "ldv-project@...uxtesting.org" <ldv-project@...uxtesting.org>,
        Pavel Machek <pavel@....cz>
Subject: RE: [PATCH v2] tty: n_gsm: avoid call of sleeping functions from
 atomic context

> >> spin_lock_irqsave(&gsm->tx_lock, flags) // taken a spinlock on TX data
> >>   con_write(...)
> >>    do_con_write(...)
> >>     console_lock()
> >>      might_sleep() // -> bug
> >>
> >> As far as console_lock() might sleep it should not be called with 
> >> spinlock held.
> >>
> >> The patch replaces tx_lock spinlock with mutex in order to avoid the 
> >> problem.
> >>
> > 
> > Do you have any hints why this might be correct?
> > 
> 
> The thing you've pointed out is actually interesting. Mutex works well in
> gsmld_write() but apparently I've missed the other contexts like in
> gsmld_receive_buf().

This patch breaks packet retransmission. Basically tx_lock and now tx_mutex
protects the transmission packet queue. This works fine as long as packets
are transmitted in a context that allows sleep. However, the retransmission
timer T2 is called from soft IRQ context and spans an additional atomic
context via control_lock within gsm_control_retransmit(). The call path
looks like this:
gsm_control_retransmit()
  spin_lock_irqsave(&gsm->control_lock, flags)
    gsm_control_transmit()
      gsm_data_queue()
        mutex_lock(&gsm->tx_mutex) // -> sleep in atomic context

I found this issue while merging our keep alive function.

Long story short: The patch via mutex does not solve the issue. It is only
shifted to another function. I suggest splitting the TX lock into packet
queue lock and underlying tty write mutex.

I would have implemented the patch if I had means to verify it.

Best regards,
Daniel Starke