I'd be interested in trying to get a grsec patched kernel into 1.0 or
1.1 - how do we suppose we could make this happen? I discussed this
with another Debian developer and they felt that a kernel flavor is
the way to go.
How might we ship grsec + pax to end users? What would be useful here
for me to do? I'm happy to rebuild the kernel with the specific
patches but I'm sure that is far from enough... :)
All the best,
Jacob
On 4/4/14, Alan <alan@???> wrote:
> Hi,
>
>> anonym wrote (02 Apr 2014 14:50:51 GMT) :
>> > Looking at the Debian changelog for the Linux kernel it seems only
>> > these changes have CVE:s:
>>
> Thanks for the research.
>
>> I've had a look (details below) and my conclusion is that... I'm
>> unsure if it's worth taking the risk of introducing regressions in
>> 1.0. Other opinions?
>>
>> > * nfqueue: Orphan frags in nfqnl_zcopy() and handle errors
>> > (CVE-2014-2568)
>>
>> Info leak triggered from the LAN.
>>
> Do you know what kind of info can leak? "sensitive information from
> kernel memory" could include cryptographic keys?
>
>> > * net: fix for a race condition in the inet frag code
>> > (CVE-2014-0100)
>>
>> use-after-free => DoS and "possibly [...] unspecified other impact"
>> Over ICMP, so generally exploitable only on the LAN.
>> Requires high CPU load on the attacked system.
>> This one seems worth fixing.
>>
> [...]
>>
>> > * skbuff: skb_segment: orphan frags before copying (CVE-2014-0131)
>>
>> Info leak triggered from the LAN.
>>
>
> I'd say it's worth taking the risk of regressions, at least if the two
> info leak might include cryptographic information leak.
>
> Cheers
> _______________________________________________
> Tails-dev mailing list
> Tails-dev@???
> https://mailman.boum.org/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to
> Tails-dev-unsubscribe@???.
>
