dirty COW

[nagtiny]

hi,
i post this one here because i use the 64bit port of tinycore, even if the problem exists also for the 32bit kernel.
are there any plans to update the current kernel to mitigate the 'dirty cow' bug?
and if so, what will be the time scale? i like the the tinycore approach very much, as in my opinion a nearly stateless readonly system with such a small footprint is an ideal base for all sorts of (security) appliances, so this fix would be very important for me.
i could build the kernel myself, but i would prefer to use an unmodified system for supporting purpose.
thank you very much!
regards
roger

[curaga]

No plans. The next version is planned in a few months, and it would ship with a kernel new enough to not have that bug, if you can wait.

Generally we keep the same kernel in a version, unless there's severe functional bugs. This is both for the embedded focus, where no kernel changes helps keeping things stable (the support argument you also mention), as well as due to limited manpower.

Standard disclaimer: there's always bugs, including security bugs. Dirty cow is a local one, meaning attackers have a shell or physical access.

[curaga]

Oh, addition to the standard disclaimer: if security is worth more than performance, you should run the grsecurity kernels.

[nagtiny]

thank you very much for your answer.
using grsecurity would be a great way to improve security, i will test this and post my findings.

for the moment, i just patched the current 4.2.9 kernel and recompiled it - even if this flaw is a "local one", one never knows if there are other flaws which may give a shell to an attacker.

did i understand you correctly, the reason not patching the kernel with such severe security fixes is due to limited manpower?
how may I help with this?

[curaga]

Even with manpower, each patch may cause regressions, as well as incompatibilities with out-of-tree modules - which would then cause trouble for some users.

[netnomad]

hi nagtiny,

i really appreciate your approach and awareness in security.
if you want to offer this forum alternative kernels for dcore,
you will find in me an active partner for heavy testing :-)

thank you for your help and contributions to the community.