Richard Weinberger wrote:
> Am 01.07.2017 um 12:35 schrieb Florian Westphal:
> > The compare on removal is not needed afaics, and its also not used when
> > doing lookup to begin with, so we can just recompute it?
>
> Isn't this a way too much overhead?
I don't think so. This computation only o
Florian,
Am 01.07.2017 um 12:35 schrieb Florian Westphal:
>>> Perhaps we can place that in a new extension (its not needed in any
>>> fastpath ops)?
>>
>> To get rid of the infoleak we have to re-introduce the id field in struct
>> nf_conn
>> and struct nf_conntrack_expect.
>
> Why will this not
Richard Weinberger wrote:
> Florian,
>
> Am 30.06.2017 um 21:55 schrieb Florian Westphal:
> >>> Why not use a hash of the address?
> >>
> >> Would also work. Or xor it with a random number.
> >>
> >> On the other hand, for user space it would be more useful when the
> >> conntrack id
> >> does n
On Fri, Jun 30, 2017 at 10:23:24PM +0200, Richard Weinberger wrote:
> Florian,
>
> Am 30.06.2017 um 21:55 schrieb Florian Westphal:
> >>> Why not use a hash of the address?
> >>
> >> Would also work. Or xor it with a random number.
> >>
> >> On the other hand, for user space it would be more usefu
Florian,
Am 30.06.2017 um 21:55 schrieb Florian Westphal:
>>> Why not use a hash of the address?
>>
>> Would also work. Or xor it with a random number.
>>
>> On the other hand, for user space it would be more useful when the conntrack
>> id
>> does not repeat that often. That's why I favor the go
Richard Weinberger wrote:
> Florian,
>
> Am 30.06.2017 um 21:35 schrieb Florian Westphal:
> > Richard Weinberger wrote:
> >> Hi!
> >>
> >> I noticed that nf_conntrack leaks kernel addresses, it uses the memory
> >> address
> >> as identifier used for generating conntrack and expect ids..
> >> S
Florian,
Am 30.06.2017 um 21:35 schrieb Florian Westphal:
> Richard Weinberger wrote:
>> Hi!
>>
>> I noticed that nf_conntrack leaks kernel addresses, it uses the memory
>> address
>> as identifier used for generating conntrack and expect ids..
>> Since these ids are also visible to unprivileged
Richard Weinberger wrote:
> Hi!
>
> I noticed that nf_conntrack leaks kernel addresses, it uses the memory address
> as identifier used for generating conntrack and expect ids..
> Since these ids are also visible to unprivileged users via network namespaces
> I suggest reverting these commits:
W
Hi!
I noticed that nf_conntrack leaks kernel addresses, it uses the memory address
as identifier used for generating conntrack and expect ids..
Since these ids are also visible to unprivileged users via network namespaces
I suggest reverting these commits:
commit 7f85f914721ffcef382a57995182916bd
