Join GitHub today
POK kernel security vulnerability #9
We discovered a serious vulnerability in the POK kernel. A patch is ready for a PR.
I forked POK (check my github), do you want me to push my commit ? If I initiate the PR, before acceptance you would be able to have a check on it. But as I said, it would make vulnerability public before official POK repository fix.
Would you like me to send you a patch instead (email + GPG ?)
Etienne, Julien Perfect, I send you the PR so that it will be easy to merge :) Thank you guys for your reactivity. Le dim. 30 sept. 2018 à 08:50, Etienne Borde <firstname.lastname@example.org> a écrit :…
Stephane, Julien, after receiving a description of the patch by email I would say I am ok for its integration as I believe it will not impact functionalities. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAy9lFa4dG8I4QjKOQL3LyoIBayi4n4dks5ugGmkgaJpZM4W6I6R> .
added a commit
Oct 2, 2018
The merge contains a problem: at link time of the object files, I have the following error message.
syscall.c:290: undefined reference to `pok_ports_names_max_len'
Indeed, pok_ports_names_max_len is defined as extern in syscall.c.
I guess the variable definition has to be generated by third party tools, but how to compute the expected value? If it is a constant, why wouldn't we use maccros like for most configuration parameters of POK?
Appart from this, and after setting pok_ports_names_max_len to an arbitrary value, it works fine.
While this is related to the change of this issue, this is not a security vulnerability per say (some generated code will work - the one generating the
Let' keep track of that in another issue so that we can clearly address one problem per issue.