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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMhUBjmGD+KH_faMJyZGBpufxPVWw7uz4tUgFtrenx-HovjxZg@mail.gmail.com>
Date:   Fri, 9 Jul 2021 22:00:32 +0800
From:   Zheyu Ma <zheyuma97@...il.com>
To:     Jiri Slaby <jirislaby@...nel.org>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] tty: serial: jsm: allocate queue buffer at probe time

On Thu, Jul 8, 2021 at 3:13 AM Jiri Slaby <jirislaby@...nel.org> wrote:
>
> On 07. 07. 21, 14:52, Andy Shevchenko wrote:
> > On Wed, Jul 7, 2021 at 10:50 AM Jiri Slaby <jirislaby@...nel.org> wrote:
> >> On 05. 07. 21, 14:53, Zheyu Ma wrote:
> >
> >> So how it comes an interrupt came before
> >> neo_param() in jsm_tty_open was called?
> >
> > If IRQ is shared we have a special debug feature to test shared IRQs
> > on freeing IRQ stage (*).
> > But it doesn't matter, the IRQ handler must survive at any stage after
> > the action has been listed.
>
> Yes, but IRQ_NONE is returned from the ISR in that case.
>
> The issue the patch is fixing is for a "malicious" device and I am not
> sure we want to fix this -- if I can put in a malicious device, I can
> use hammer to kill the box too…

Well, this threat assumption is indeed strong, but this attack may be
real. For example, some programmable USB devices (such as FaceDancer)
may exploit vulnerabilities in the USB device driver to attack. Of
course, there has not been such an attack in the real world for PCI
devices. Or, some devices with DMA functions may also send malicious
data and some previous kernel commits have also fixed such bugs.

Anyway, thanks for your patient comments.

Regards,
Zheyu Ma

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ