On Mon, Jun 20, 2016 at 02:52:27PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> > On Mon, Jun 20, 2016 at 02:42:59PM +0200, Pablo Neira Ayuso wrote:
> > > On Mon, Jun 20, 2016 at 01:19:52PM +0200, Florian Westphal wrote:
> > > > nfq_open_nfnl uses an intermediate static object, so when
> > > > it is invoked by distinct threads at the same time there is a small
> > > > chance that some threads end up with another threads nfq_handle pointer
> > > > stored in ->data.
> > > >
> > > > Tested-by: Michal Tesar <mtesar@xxxxxxxxxx>
> > > > Signed-off-by: Florian Westphal <fw@xxxxxxxxx>
> > >
> > > Acked-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
> >
> > Wait wait...
>
> Sorry, already pushed it after seeing the Ack...
>
> > This is allocated in this stack?
> >
> > struct nfq_handle *nfq_open_nfnl(struct nfnl_handle *nfnlh)
> > {
> > + struct nfnl_callback pkt_cb = {
> > + .call = __nfq_rcv_pkt,
> > + .attr_count = NFQA_MAX,
> > + };
> >
> > Then accessed out of it?
> >
> > I mean, this is passed by reference to the callback registration.
>
> AFAICS nfnl_callback_register() memcpy's the thing into nfnl_handle,
> which is malloc'd in nfq_open_nfnl.
Right, sorry for the noise.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
