I’ve categorised this as ‘Development’ but it’s not about Gramps, it’s about the Linux kernel:
GhostLock requires local access for exploitation, which serves as a mitigating factor. An attacker must first gain some level of access to the system before using GhostLock to escalate privileges.
Well, and Gramps should fix any possible GhostLock issue during a local session?
I know nothing about Linux but my understanding of the article is that the only fix for GhostLock is to update the Linux kernel to v7.1.
What about offline desktop? Sure, one could also knock on your door, push you out of your chair for having one local access and run its bad code. Note, you are also free to run any kernel (custom or not)…
So, by only safe with kernel 7.1, you often need to add exceptions under Linux.
The bug was introduced by
8161239a8bccin v2.6.39 (2011) and fixed in v7.1 by3bfdc63936dd(rtmutex: Use waiter::task instead of current in remove_waiter()). Because it dates to 2.6.39, the practical exploitable window is every kernel from 2.6.39 through 7.0; distro adoption of the backport is tracked below.
Great, I still have very old kernel versions… ![]()
- fix 3bfdc63936dd (first in v7.1); introduced 8161239a8bcc (v2.6.39), so every kernel 2.6.39 through 7.0 is in-window - stable backports 6.1.177, 6.6.144, 6.12.95, 6.18.36, 7.0.13; 5.15.y and 5.10.y not backported
etc.