Linux has a security team/list that does handle disclosures and fixing of reported problems. It usually does this by just dragging in the responsible parties, but many times it just fixes the problems themselves and submits the patches to the proper part of the kernel.
>It usually does this by just dragging in the responsible parties, but many times it just fixes the problems themselves and submits the patches to the proper part of the kernel.
I think this is the key - once the patches are submitted they go through the normal workflow and aren't any different from a typical patch, right?
Yes, once the patches are generated, they get submitted just like any other kernel change, sent to the responsible subsystem and maintainer for inclusion like any other kernel change.
I think this is where the problems becomes apparent. The change then has to go through the subsystem's patch flow (in public) then into the merge window (in public) and sit in the release pipeline (in public) until the window closes and all of the rc's are through.
Personally I don't think this is a huge deal, but it's where the disconnect between the security person's ideal worldview and the reality of how Linux is built colllide.
Distros could speed this up. If the security team notifies RedHat, Ubuntu, etc and they can apply the patch for their kernels immediately. They probably need to backport it anyways, because no distro (well, maybe Arch?) just uses the latest Linux release.
Breaking embargoes generally leads to easy, packaged exploits appearing that many days earlier than they otherwise would have. Obviously patches being delayed gets you on the other end. How are either of those not a huge deal? Do you just think it's not important to have patched systems against published vulnerabilities?
For details on how this works, please see the kernel documentation itself: https://www.kernel.org/doc/html/latest/admin-guide/security-...