Hello Julia,
On Fri, Feb 8, 2019 at 1:57 AM Julia Lawall wrote:
>
> > - is this important enough to ping back to authors of affected modules?
> > - should this be added to the kernel as part of 'make coccicheck' ?
> > - does this result make people "feel better" about devm_init_work() ?
>
> If
Hi Miguel,
On Wed, Feb 13, 2019 at 8:11 PM Miguel Ojeda
wrote:
>
> Indeed! Note that I didn't mean to say they are trivial issues or that
> the solution is simply to replace cancel_delayed_work() with the
> _sync() version in all cases -- only that it might be a good idea to
> suggest its
Hi Sven,
On Sun, Feb 10, 2019 at 7:05 PM Sven Van Asbroeck wrote:
>
> For relatively straightforward problems, I'd say yes.
>
> However, the problems flagged by this script are not trivial at all.
> In many cases, the missing _sync is just a symptom of general
> synchronization issues on
Hi Miguel,
On Thu, Feb 7, 2019 at 11:30 PM Miguel Ojeda
wrote:
>
> Similarly, in drivers/auxdisplay/ht16k33.c, the cancel_delayed_work()
> is there, instead of cancel_delayed_work_sync(). Having the script
> suggest this change would be useful, too (i.e. instead of the devm_
> change, assuming
On Wed, Feb 06, 2019 at 09:30:29AM -0800, Dmitry Torokhov wrote:
> On Wed, Feb 6, 2019 at 8:47 AM Greg KH wrote:
> >
> > On Tue, Feb 05, 2019 at 02:12:31PM -0500, Sven Van Asbroeck wrote:
> > > On Tue, Feb 5, 2019 at 1:43 PM Greg KH wrote:
> > > >
> > > >
> > > > It really should happen when the
On Thu, Feb 7, 2019 at 11:33 PM Sven Van Asbroeck wrote:
>
> On Thu, Feb 7, 2019 at 5:21 PM Dmitry Torokhov
> wrote:
> >
> > > ./drivers//input/keyboard/matrix_keypad.c:512:1-18: missing clean-up
> > > of INIT_WORK/INIT_DELAYED_WORK initialized here
> >
> > This is not as simple.
> >
>
> PS If
On Thu, Feb 7, 2019 at 2:32 PM Sven Van Asbroeck wrote:
>
> On Thu, Feb 7, 2019 at 5:21 PM Dmitry Torokhov
> wrote:
> >
> > > ./drivers//input/keyboard/matrix_keypad.c:512:1-18: missing clean-up
> > > of INIT_WORK/INIT_DELAYED_WORK initialized here
> >
> > This is not as simple.
> >
>
> PS If
On Thu, Feb 7, 2019 at 5:21 PM Dmitry Torokhov
wrote:
>
> > ./drivers//input/keyboard/matrix_keypad.c:512:1-18: missing clean-up
> > of INIT_WORK/INIT_DELAYED_WORK initialized here
>
> This is not as simple.
>
PS If you change
flush_work(>work.work);
to
flush_delayed_work(>work);
then the
On Thu, Feb 7, 2019 at 5:21 PM Dmitry Torokhov
wrote:
>
> > ./drivers//input/keyboard/matrix_keypad.c:512:1-18: missing clean-up
> > of INIT_WORK/INIT_DELAYED_WORK initialized here
>
> This is not as simple.
[...]
> So in effect we do not actually leak work
> past driver remove().
That's
Hi Sven,
On Thu, Feb 7, 2019 at 1:49 PM Sven Van Asbroeck wrote:
>
> On Tue, Feb 5, 2019 at 9:57 AM Kees Cook wrote:
> >
> > Can a Coccinelle script get written to find module-use of the non-devm
> > work init?
>
> Ok so I hacked together a Coccinelle script to find these
> user-after-free
On Tue, Feb 5, 2019 at 9:57 AM Kees Cook wrote:
>
> Can a Coccinelle script get written to find module-use of the non-devm
> work init?
Ok so I hacked together a Coccinelle script to find these
user-after-free issues,
related to work left running when the device or module is removed.
As far as
On Wed, Feb 6, 2019 at 12:30 PM Dmitry Torokhov
wrote:
>
> Yeah. But devm irq gave most trouble because we did not have enough
> devm APIs so we often ended up with mixed devm/non-devm usage and that
> is what was causing most of the issues. If we can switch everything to
> devm then devm irq is
On Wed, Feb 6, 2019 at 8:47 AM Greg KH wrote:
>
> On Tue, Feb 05, 2019 at 02:12:31PM -0500, Sven Van Asbroeck wrote:
> > On Tue, Feb 5, 2019 at 1:43 PM Greg KH wrote:
> > >
> > >
> > > It really should happen when the device is removed (if it is a driver
> > > that binds to a device.)
> >
> >
On Tue, Feb 05, 2019 at 02:12:31PM -0500, Sven Van Asbroeck wrote:
> On Tue, Feb 5, 2019 at 1:43 PM Greg KH wrote:
> >
> >
> > It really should happen when the device is removed (if it is a driver
> > that binds to a device.)
>
> Absolutely. That's why I'm advocating adding a devm_init_work(),
>
On Tue, Feb 5, 2019 at 1:43 PM Greg KH wrote:
>
>
> It really should happen when the device is removed (if it is a driver
> that binds to a device.)
Absolutely. That's why I'm advocating adding a devm_init_work(),
which will take care of this automatically.
But it's of course not universally
On Tue, Feb 05, 2019 at 10:22:50AM -0500, Sven Van Asbroeck wrote:
> On Tue, Feb 5, 2019 at 9:57 AM Kees Cook wrote:
> >
> >
> > Can a Coccinelle script get written to find module-use of the non-devm
> > work init?
>
> My thoughts exactly ! But sadly I'm not a Coccinelle expert. I did
> look
On Tue, Feb 05, 2019 at 02:57:11PM +, Kees Cook wrote:
> On Mon, Feb 4, 2019 at 10:09 PM Sven Van Asbroeck wrote:
> >
> > I think there _might_ be potential use-after-free issues on module unload.
There are loads of issues with module unloading, which is why it pretty
much is a "best effort"
On Tue, Feb 5, 2019 at 9:57 AM Kees Cook wrote:
>
>
> Can a Coccinelle script get written to find module-use of the non-devm
> work init?
My thoughts exactly ! But sadly I'm not a Coccinelle expert. I did
look briefly at
its syntax, but I didn't immediately "get" how Cocci could find this class
On Mon, Feb 4, 2019 at 10:09 PM Sven Van Asbroeck wrote:
>
> I think there _might_ be potential use-after-free issues on module unload.
>
> They are hard to trigger, but I think I've seen them bring the whole
> kernel down when they do occur. Can be triggered by doing an insmod of
> a vulnerable
I think there _might_ be potential use-after-free issues on module unload.
They are hard to trigger, but I think I've seen them bring the whole
kernel down when they do occur. Can be triggered by doing an insmod of
a vulnerable module, rapidly followed by an rmmod.
Caused by drivers which
20 matches
Mail list logo
