Refer to: https://lore.kernel.org/all/CAPh3n83zb1PwFBFijJKChBqY95zzpYh=2iPf8tmh=YTS6e3...
Looks like this should be backported to all LTS kernels where FORTIFY_SOURCE is expected to be enabled.
/jeff
On Wed, Jun 26, 2024 at 11:32:22AM -0700, Jeff Johnson wrote:
Refer to: https://lore.kernel.org/all/CAPh3n83zb1PwFBFijJKChBqY95zzpYh=2iPf8tmh=YTS6e3...
Please provide the information in the email, for those of us traveling with store-and-forward email systems, links don't always work.
Looks like this should be backported to all LTS kernels where FORTIFY_SOURCE is expected to be enabled.
And where would that exactly be? Have you verified that it will apply properly to those unnamed kernel trees?
thanks,
greg k-h
On 6/27/2024 12:18 AM, Greg KH wrote:
On Wed, Jun 26, 2024 at 11:32:22AM -0700, Jeff Johnson wrote:
Refer to: https://lore.kernel.org/all/CAPh3n83zb1PwFBFijJKChBqY95zzpYh=2iPf8tmh=YTS6e3...
Please provide the information in the email, for those of us traveling with store-and-forward email systems, links don't always work.
Apologies. I was trying to be concise, but over did it.
The issue reported is a splat in 6.6 due to FORTIFY_SOURCE complaining about access to an "old style" variable array declared with size 1: u8 virtual_map[1];
Looks like this should be backported to all LTS kernels where FORTIFY_SOURCE is expected to be enabled.
And where would that exactly be? Have you verified that it will apply properly to those unnamed kernel trees?
I don't know which trees are actively enabling FORTIFY_SOURCE. Since the report is coming from 6.6, I would expect we should backport at least to there.
I've cc'd Kees in case he has more definite information, as well as the wireless maintainers and the reporter in case they have anything else to add.
The actual fix is trivial, containing just a change to a data structure along with a related documentation change. Any conflicts would more likely occur due to the documentation rather than the code, since that code definition had been unchanged since 2012 but the documentation has been refined over time.
/jeff
On Thu, Jun 27, 2024 at 07:44:48AM -0700, Jeff Johnson wrote:
On 6/27/2024 12:18 AM, Greg KH wrote:
On Wed, Jun 26, 2024 at 11:32:22AM -0700, Jeff Johnson wrote:
Refer to: https://lore.kernel.org/all/CAPh3n83zb1PwFBFijJKChBqY95zzpYh=2iPf8tmh=YTS6e3...
Please provide the information in the email, for those of us traveling with store-and-forward email systems, links don't always work.
Apologies. I was trying to be concise, but over did it.
The issue reported is a splat in 6.6 due to FORTIFY_SOURCE complaining about access to an "old style" variable array declared with size 1: u8 virtual_map[1];
Looks like this should be backported to all LTS kernels where FORTIFY_SOURCE is expected to be enabled.
And where would that exactly be? Have you verified that it will apply properly to those unnamed kernel trees?
I don't know which trees are actively enabling FORTIFY_SOURCE. Since the report is coming from 6.6, I would expect we should backport at least to there.
FWIW, FORTIFY_SOURCE is enabled in every distro kernel config I know of (and has been for a very long time).
I've cc'd Kees in case he has more definite information, as well as the wireless maintainers and the reporter in case they have anything else to add.
The actual fix is trivial, containing just a change to a data structure along with a related documentation change. Any conflicts would more likely occur due to the documentation rather than the code, since that code definition had been unchanged since 2012 but the documentation has been refined over time.
Right, this is fixing the splat -- no other behavioral changes were seen.
-Kees
On Thu, Jun 27, 2024 at 07:44:48AM -0700, Jeff Johnson wrote:
On 6/27/2024 12:18 AM, Greg KH wrote:
On Wed, Jun 26, 2024 at 11:32:22AM -0700, Jeff Johnson wrote:
Refer to: https://lore.kernel.org/all/CAPh3n83zb1PwFBFijJKChBqY95zzpYh=2iPf8tmh=YTS6e3...
Please provide the information in the email, for those of us traveling with store-and-forward email systems, links don't always work.
Apologies. I was trying to be concise, but over did it.
The issue reported is a splat in 6.6 due to FORTIFY_SOURCE complaining about access to an "old style" variable array declared with size 1: u8 virtual_map[1];
Looks like this should be backported to all LTS kernels where FORTIFY_SOURCE is expected to be enabled.
And where would that exactly be? Have you verified that it will apply properly to those unnamed kernel trees?
I don't know which trees are actively enabling FORTIFY_SOURCE. Since the report is coming from 6.6, I would expect we should backport at least to there.
It does not apply to 6.6.y, sorry, please provide a working backport for any tree you wish to see this applied to.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org