[hvidgaard]

What should they do instead? You have to rush to patch in any case. If the maintainers start to label commits with "security patch" the logical step is that it doesn't require immediate action when the label is not there. Never mind that the bug might actually be exploitable but undiscovered by white hats.

If you do not want to rush to patch more than you have to, use a LTS kernel and know that updates matter and should be applied asap regardless of the reason for the patch.

[staticassertion]

> What should they do instead?

When someone submits a patch for a vulnerability label the commit with that information.

> You have to rush to patch in any case.

The difference is how much of a head start attackers have. Attackers are incentivized to read commits for obfuscated vulns - asking defenders to do that is just adding one more thing to our plates.

That's a huge difference.

> the logical step is that it doesn't require immediate action when the label is not there.

So I can go about my patch cycle as normal.

> Never mind that the bug might actually be exploitable but undiscovered by white hats.

OK? So? First of all, it's usually really obvious when a bug might be exploitable, or at least it would be if we didn't have commits obfuscating the details. Second, I'm not suggesting that you only apply security labeled patches.

[roddux]

Don't know why your other comment got downvoted. Silently patching bugs has left many LTS kernels vulnerable to old bugs, because they weren't tagged as security fixes. Also leads to other issues..: https://grsecurity.net/the_life_of_a_bad_security_fix

See also: https://twitter.com/spendergrsec

[sirdarckcat]

for what is worth, the link gregkh pointed you to explains the answer for your first 2 points.

Your last point is wrong. Simple example, which of the following thousand bugs are exploitable? https://syzkaller.appspot.com/upstream

If you can exploit them, you can earn 20,000 to 90,000 USD on https://google.github.io/kctf/vrp

[hvidgaard]

I think you missed my point. Attackers will go through commits regardless of a "Security Patch" tag.

But going about your normal patch cycle as normal for things not labelled "Security Patch", just means if the patch for some reason should have been tagged but wasn't, you're in the same situation.

I do see the value in your approach, but it just does not change anything for applications where security is top priority.

[gwd]

> What should they do instead?

Well Xen for instance includes a reference to the relevant security advisory; either "This is XSA-nnn" or "This is part of XSA-nnn".

> If the maintainers start to label commits with "security patch" the logical step is that it doesn't require immediate action when the label is not there. Never mind that the bug might actually be exploitable but undiscovered by white hats. If you do not want to rush to patch more than you have to, use a LTS kernel and know that updates matter and should be applied asap regardless of the reason for the patch.

So reading between the lines, there are two general approaches one might take:

1. Take the most recent release, and then only security fixes; perhaps only security fixes which are relevant to you.

2. Take all backported fixes, regardless of whether they're relevant to you.

Both Xen and Linux actually recommend #2: when we issue a security advisory, we recommend people build from the most recent stable tip. That's the combination of patches which has actually gotten the most testing; using something else introduces the risk that there are subtle dependencies between the patches that hasn't been identified. Additionally, as you say, there's a risk that some bug has been fixed whose security implications have been missed.

Nonethess, that approach has its downsides. Every time you change anything, you risk breaking something. In Linux in particular, many patches are chosen for backport by a neural network, without any human intervention whatsoever. Several times I've updated a point release of Linux to discover that some backport actually broke some other feature I was using.

In Xen's case, we give downstreams the information to make the decisions themselves: If companies feel the risk of additional churn is higher than the risk of missing potential fixes, we give them the tools do to so. Linux more or less forces you to take the first approach.

Then again, Linux's development velocity is way higher; from a practical perspective it may not be possible to catch the security angle of enough commits; so forcing downstreams to update may be the only reasonable solution.