regression or not
Posted Dec 16, 2006 1:11 UTC (Sat) by giraffedata
Parent article: Another kernel core dump security issue
This particular bug is not technically a regression as there never was a bug that allowed this behavior until it was introduced in the patch.
The technical definition of regression doesn't require a formerly existing bug. A regression is a case where Release N+1 is worse than Release N. From the latin meaning, "to step backward." In most contexts, the definition is narrowed to: Something that works in Release N does not in Release N+1.
Regressions are separated from other bugs because a regression is a reason not to upgrade to N+1, whereas other bugs are not.
In this case, it's hard to cast the bug in any light in which it is not a regression. 2.6.18 is secure from hackers; 2.6.19 is not. A step backward. A reason to regret going to 2.6.19.
I've also heard of code regression, which might be more applicable here. That's where you accidentally overwrite new code with old code, which happens if multiple simultaneous developers aren't careful. A cursory glance it this bug might give you the impression is was caused by a code regression.
to post comments)