The same way they prevent disclosing the report: by not disclosing it.
Since you mentioned the Linux kernel specifically: only a vanishingly small number of users build their kernels directly from the master branch of Linus Torvald's Git repository. The vast majority of users simply use whatever kernel their distribution's automatic updater installs.
In turn, the vast majority of distributions don't build their kernels directly from the master branch of Linus Torvald's Git repository either. They use some official release version as the base, backport some new features and fixes from newer kernels, integrate some third-party patches that are not part of Linus's repository, integrate some distribution-specific patches, etc.
Since they integrate patches that are not part of Linus's repository anyway, it makes no difference to them to integrate just one more patch for the most recent vulnerability.
So, basically what happens is that the release of the patch is coordinated such that at the time the vulnerability is fixed in Linus's Git repository and publicly announced, patched kernel images are already pushed out to users from the distribution's update servers.
Note that generally, the Linux developers prefer to publish fixes as quickly as possible, but if you check out the chapter on Security Bugs in the Linux Kernel Documentation, you will find the paragraph on Coordination, which I think explains the specific process for the Linux Kernel pretty well, and is also representative of how some other large projects handle the issue:
Fixes for sensitive bugs […] may need to be coordinated with the private [linux-distros] mailing list so that distribution vendors are well prepared to issue a fixed kernel upon public disclosure of the upstream fix. Distros will need some time to test the proposed patch and will generally request at least a few days of embargo […]. When appropriate, the security team can assist with this coordination, or the reporter can include linux-distros from the start.
So, the trick is:
- Coordinate with each other to make sure that all distribution vendors are ready to push out updates. This would, for example, also include something like Google coordinating with the downstream handset vendors, etc.
- Release the fix and the information that it is a serious security vulnerability, but do not necessarily release the nature of the vulnerability. (A serious attacker will be able to figure it out from the patch, but you buy yourself a little bit of time.)
How much of this is done, and what the timeframes are, depends on the nature of the vulnerability. A remotely-exploitable privilege escalation will be treated differently than a DoS that can only be exploited by someone who is already logged into the machine locally.
In the best possible case, the experience of the end user will be that by the time the vulnerability becomes public, their computer will already have greeted them with a message informing them that the system has been rebooted overnight for the installation of a critical security update, and that's it.