That's bonkers.
This sounds like a reasonable definition, but quickly it turns out to be completely insane.
Lets start somewhere far away from Linux, as far away as possible.
Windows XP SP2 blocked access to raw sockets for non-administrators. It also blocked access to \Device\PhysicalMemory to all user-mode code, regardless of the user running it. Linus would say this is a regression.
Fine, lets try something else.
I wrote some C++ code that violated the strict aliasing rule. It worked for me 15 years ago when compilers weren't optimizing so aggressively. I tried to compile it using the latest GCC and got strange results. Should I file a bug with GCC? Sounds like a bug according to Linus's definition. It used to work and now it doesn't. Who cares that I violated the rules in the first place?
"Now, hold on" I head you say. "We were talking about kernel and user, not compiling C++ code. That completely different!"
Well, sure, it's different. But it's also similar. I maintain that the point is the same, but lets go back to Windows for a second.
Lets say we have a program that used to parse the PEB.Ldr structs for whatever reason. In Windows 8 they went through a major change. This program no longer works. Is this a regression?
Raymond Chen has had to deal with this nonsense enough. For example: https://blogs.msdn.microsoft.com/oldnewthing/20031223-00/?p=... And his blog is full of example of dumb programmers counting on internal, undocumented, subject to change and actually changing structs.
If you, the reader, think you're very clever and say it's dissimilar because the LDR structs are user- rather than kernel-owned and -managed structs I give you the same example with EPROCESS. Take a look: http://terminus.rewolf.pl/terminus/structures/ntdll/_EPROCES...
The point is that "breaking" code that does things it wasn't supposed to to should be - and can reasonably be - considered a regression.
The very first example - with raw sockets - may be considered a regression, though I prefer the term "breaking change", since "regression" is a form of a bug, and this is not a bug, even if you think it's a bad policy.
The other examples don't even fall under the "Breaking change" the category. Nothing THAT WAS GUARANTEED was changed. If you counted on things that nobody promised you that would remain the same to actually remain the same that's your problem.
And back to Windows for a moment. Lets say someone uses the UpdateProcThreadAttribute API to set the mitigation policy on a child process it creates. Instead of only setting the bits he want (like PROCESS_CREATION_MITIGATION_POLICY_FORCE_RELOCATE_IMAGES_ALWAYS_ON to force ASLR on all modules, PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON to block win32k calls and PROCESS_CREATION_MITIGATION_POLICY_EXTENSION_POINT_DISABLE_ALWAYS_ON to prevent injection by the system of a couple sorts of plugins) he goes on to pass 0xFFFFFFFFFFFFFFFF. He wants all the possible mitigations! He's that smart!
Then comes along Windows 10 with its binary signature policy mitigation and (0x00000003ui64 From what I understand the situation is very similar to this. I'm quoting from John Johansen message on the thread:
It is entirely possible to use the 4.14 kernel on suse without having
to modify policy if the policy version/feature set is pinned. However
this is not a feature that suse seems to be using. Instead suse policy
is tracking and enforcing all kernel supported features when they
become available, regardless of whether the policy has been updated.
The clever folks at SUSE decided to enable all the protections/mitigations/features/whatever of AppArmor, including those that didn't even exist when they wrote this stupid policy. It's completely reasonable to think that a program restriction infrastructure's new feature won't restrict programs more. Sure. If it does that's a regression.