linux-kernel - Re: [PATCH 2/2] firewire: core: fix race at address

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:	Sat, 18 Feb 2012 20:11:39 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	linux1394-devel@...ts.sourceforge.net
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] firewire: core: fix race at address_handler
 unregistration

On Feb 18 Stefan Richter wrote:
> Fix the following unlikely but possible race:
> 
> CPU 1                             CPU 2
> ------------------------------------------------------------------------
> AR-request tasklet
>     lookup handler
>                                   unregister handler
> 				  free handler->callback_data or handler
>     call handler->callback
> 
> The application which registered the handler has no way to stop nodes
> sending new requests to their address range, hence cannot prevent this
> race.
> 
> Fix it simply by extending the address_handler_lock-protected region
> from only around the lookup to around both lookup and call.  We only
> need to do so in the exclusive region handler; the FCP region handler
> already holds the lock around the handler->callback call.
> 
> Alas this removes the current ability to execute the callback in
> parallel on different CPUs if it was called for different FireWire cards
> at the same time.  (For a single card, the handler is already
> serialized.)  If this loss of a rather obscure feature is not tolerable,
> a more complex fix would be required:  Add a handler reference counter;
> wait in fw_core_remove_address_handler() for this conter to become zero.

Oh, and the other downside is that the region in which local IRQs are
disabled is extended.  So I guess I should at least the core, maybe also
the application layer drivers, to spin_lock_bh instead, sooner than later.
-- 
Stefan Richter
-=====-===-- --=- =--=-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/