snd_dummy: Drain callout during detach

[christos]

Summary

If we do not enter dummy_chan_trigger() before detaching, we'll get a
use-after-free since the callout(9) callback might be called after
having been detached.

Sponsored by: The FreeBSD Foundation
MFC after: 2 days

[emaste]

callout_drain perhaps?

[christos]

In D46715#1065214, @emaste wrote:

callout_drain perhaps?

callout_drain() will wait for the callout to finish, instead of stopping it immediately. Is there an advantage to using this?

[markj]

In D46715#1065271, @christos wrote:

In D46715#1065214, @emaste wrote:

callout_drain perhaps?

callout_drain() will wait for the callout to finish, instead of stopping it immediately. Is there an advantage to using this?

Yes, it ensures that the callout won't be running while dummy_detach() runs concurrently. This patch makes the use-after-free harder to hit, but doesn't fix it completely.

[christos]

In D46715#1065298, @markj wrote:

In D46715#1065271, @christos wrote:

In D46715#1065214, @emaste wrote:

callout_drain perhaps?

callout_drain() will wait for the callout to finish, instead of stopping it immediately. Is there an advantage to using this?

Yes, it ensures that the callout won't be running while dummy_detach() runs concurrently. This patch makes the use-after-free harder to hit, but doesn't fix it completely.

If the callout stops before pcm_unregister() is called, read/write operations will have stopped already in the case of snd_dummy, so we shouldn't hit any use-after-free. That being said, I guess it could be made even more robust by check whether &sc->chans[i] is NULL in the dummy_chan_io() loop, even though the channels pointed to by sc->chans are freed in pcm_unregister().

[christos]

Use callout_drain().