This is clone of a bug found in the Red Hat 2.6 kernel:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113555
with the following analysis from Ajran and Al:

From: Al Viro
On Mon, Jan 19, 2004 at 09:27:06AM +0100, Arjan van de Ven wrote:
> basically what happens is that in ec.c this code triggers:
>        if (ec_ecdt && ec_ecdt->uid == uid) {
>                 acpi_remove_address_space_handler(ACPI_ROOT_OBJECT,
>                         ACPI_ADR_SPACE_EC, &acpi_ec_space_handler);
>                                                                    
>                 acpi_remove_gpe_handler(NULL, ec_ecdt->gpe_bit, 
&acpi_ec_gpe_handler);
>                                                         
>                 kfree(ec_ecdt);
>         }
> 
> where acpi_remove_gpe_handler() forgets to remove outstanding work/wait for
> outstanding work, so such work keeps polluting ec_ecdt even though it's 
freed (and in
> this bug's case, reallocated for something else leading to an oops in /proc
> later).
> 
> Remove interfaces ideally are synchronous with the thing they remove, like
> del_timer_sync() is in linux....

It's a bit worse than that - removal of acpi_ec_gpe_handler is not what bites
us here; what happens is:
	acpi_ec_gpe_handler is scheduled
	acpi_ec_gpe_handler runs and schedules acpi_ec_gpe_query
	we remove acpi_ec_gpe_handler, which leaves acpi_ec_gpe_query scheduled
	we kfree the thing tha is the argument of acpi_ec_gpe_handler _AND_
the argument of scheduled acpi_ec_gpe_handler
	acpi_ec_gpe_handler runs
	*BOOM*

So whether there are issues in acpi_remove_gpe_handler() behaviour or not
(and they can easily create similar races with narrower windows), here we
are getting screwed since the caller of acpi_remove_gpe_handler() has no
idea that acpi_ec_gpe_handler() had left something behind.