netdev - Re: Passive OS fingerprint xtables match.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20090129150343.GB28669@ioremap.net>
Date:	Thu, 29 Jan 2009 18:03:43 +0300
From:	Evgeniy Polyakov <zbr@...emap.net>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>
Subject: Re: Passive OS fingerprint xtables match.

Hi Paul.

On Wed, Jan 28, 2009 at 07:36:13PM -0800, Paul E. McKenney (paulmck@...ux.vnet.ibm.com) wrote:
> > Passive OS fingerprint homepage (archives, examples):
> > http://www.ioremap.net/projects/osf
> 
> Cool stuff!!!

Thank you :)

> However, I believe you need an rcu_barrier() in the module-exit function
> as noted below.

> > +static void __devexit ipt_osf_fini(void)
> > +{
> > +	struct ipt_osf_finger *f;
> > +	int i;
> > +
> > +	cn_del_callback(&cn_osf_id);
> > +	xt_unregister_match(&ipt_osf_match);
> > +
> > +	rcu_read_lock();
> > +	for (i=0; i<ARRAY_SIZE(ipt_osf_fingers); ++i) {
> > +		struct ipt_osf_finger_storage *st = &ipt_osf_fingers[i];
> > +
> > +		list_for_each_entry_rcu(f, &st->finger_list, finger_entry) {
> > +			list_del_rcu(&f->finger_entry);
> > +			call_rcu(&f->rcu_head, ipt_osf_finger_free_rcu);
> > +		}
> > +	}
> > +	rcu_read_unlock();
> 
> Don't we need an rcu_barrier() here so that the preceding RCU callbacks
> are guaranteed to complete before the module text/data/bss vanish?
> 
> Whatever does the rmmod is responsible for making sure that there are no
> additional callers into the various entry points once the rmmod starts,
> I take it?  I don't see anything here that prevents something like that
> from happening (though I easily could be missing something).

All objects freed there were dynamically allocated, so we just
kfree()'ing some data not accessing static data potentially destroyed by
the rmmod and not accessing statically created, so there should be no
problems as far as I can see.

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html