Page MenuHomeFreeBSD

pf: improve pf_state_key_attach() error handling
ClosedPublic

Authored by kp on Fri, Mar 28, 2:47 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Apr 1, 3:17 AM
Unknown Object (File)
Mon, Mar 31, 7:14 PM
Unknown Object (File)
Sun, Mar 30, 12:57 PM
Unknown Object (File)
Sun, Mar 30, 12:14 AM
Unknown Object (File)
Sat, Mar 29, 11:02 PM
Unknown Object (File)
Sat, Mar 29, 7:48 PM

Details

Summary

If we fail to attach the stack key that means we've already attached the wire
key. That means the state could be found by other cores, and given that we then
free it, be used after free.
Fix this by not releasing the ID hashrow lock and key locks, ensuring the state
cannot be found by other cores.

Reported by: markj
Submitted by: glebius
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kp requested review of this revision.Fri, Mar 28, 2:47 PM
sys/netpfil/pf/pf.c
1544–1547

Both clauses have the same epilogue:

if (skw != sks)
        uma_zfree(V_pf_state_key_z, sks);

It can be moved out.

That means the state could be found by other cores

Nitpicking, it could also happen on the same core if the current thread is preempted at the wrong moment.

sys/netpfil/pf/pf.c
1544–1547

I'd go even further. When cleaning up resources, I usually try to avoid holding unnecessary locks, even in infrequently executed code. (Or otherwise perhaps add a comment explaining the relevant locking protocol.) To that end:

  • we can PF_HASHROW_UNLOCK before the state key cleanup,
  • we can free state keys without any locks.

So:

PF_HASHROW_UNLOCK(ih);
s->timeout = PFTM_UNLINKED;
if (idx == PF_SK_STACK)
    /* Remove the wire key from the hash. Other threads can't be referencing it because we still hold the hash lock. */
    pf_state_key_detach(skw);
KEYS_UNLOCK();
if (idx == PF_SK_WIRE)
    uma_zfree(skw);
if (sks != skw)
    uma_zfree(sks);
return (EEXIST);

This makes the locking a bit clearer, at least to my taste.

This revision is now accepted and ready to land.Sat, Mar 29, 8:03 AM
sys/netpfil/pf/pf.c
1544–1547

Yep, that's even better! Thanks!

Move free operations outside the lock

This revision now requires review to proceed.Sun, Mar 30, 7:53 PM

I don't think comments are valuable at this point. The resulting code is clear by itself. Up to you whether to leave them or not. Thanks!

This revision is now accepted and ready to land.Sun, Mar 30, 11:22 PM
This revision was automatically updated to reflect the committed changes.