# v5.14.0 kernel compile fails: __write_overflow

## shoober420

[Moderator edit: Changed title to try to attract relevant answers. Original title was borked kernel compile, which specified neither the kernel version nor the nature of the problem. -Hu]

Is anyone else getting this build error when they compile 5.14.0 kernel?

```
                                                                                             

./include/linux/fortify-string.h:172:17: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object passed as 1st parameter                         

  172 |                 __write_overflow();                                                                                                                                                    

      |                 ^~~~~~~~~~~~~~~~~~                    

```

I get this error several times during compilation then the kernel stops building. full log linked

https://bugzilla.kernel.org/attachment.cgi?id=298565

[Moderator edit: See also the associated bug report: https://bugzilla.kernel.org/show_bug.cgi?id=214253 -Hu]

```

CC      arch/x86/entry/vdso/vdso-image-x32.o

In file included from ./include/linux/string.h:262,                                                                                                                                            

                 from ./include/linux/bitmap.h:10,                                                                                                                                             

                 from ./include/linux/cpumask.h:12,                                                                                                                                            

                 from ./arch/x86/include/asm/cpumask.h:5,                                                                                                                                      

                 from ./arch/x86/include/asm/msr.h:11,                                                                                                                                         

                 from ./arch/x86/include/asm/processor.h:22,                                                                                                                                   

                 from ./arch/x86/include/asm/timex.h:5,                                                                                                                                        

                 from ./include/linux/timex.h:65,                                                                                                                                              

                 from ./include/linux/time32.h:13,                                                                                                                                             

                 from ./include/linux/time.h:60,                                                                                                                                               

                 from ./include/linux/stat.h:19,                                                                                                                                               

                 from ./include/linux/module.h:13,                                                                                                                                             

                 from crypto/asymmetric_keys/public_key.c:11:                                                                                                                                  

In function 'memcpy',                                                                                                                                                                          

    inlined from 'pkey_pack_u32.part.0' at crypto/asymmetric_keys/public_key.c:100:2:                                                                                                          

./include/linux/fortify-string.h:185:25: error: call to '__write_overflow' declared with attribute error: detected write beyond size of object passed as 1st parameter                         

  185 |                         __write_overflow();                                                                                                                                            

      |                         ^~~~~~~~~~~~~~~~~~           

make[2]: *** [scripts/Makefile.build:271: crypto/asymmetric_keys/public_key.o] Error 1

make[2]: *** Waiting for unfinished jobs....

```

----------

## alamahant

Plz wait for 5.14.1

----------

## Hu

 *alamahant wrote:*   

> Plz wait for 5.14.1

 Is this general advice, or are you aware of a specific patch that misssed 5.14.0 that you expect will resolve this?

----------

## alamahant

Hu

It is a general advice.

Same thing happened with 5.13.0 rememeber?

Something with nfs if my memory serves me.

----------

## Hu

5.13.0 had a last minute patch for memory management that caused an issue for NFS, yes.  However, shoober420 has demonstrated an interest in running live-from-vcs everything.  For that reason, I'm a bit surprised he's using v5.14.0 instead of the latest commit from Linus' tree.

----------

## shoober420

I would try out the kernel git master branch, but its not compatible with the BMQ CPU scheduler. For this reason, I use latest stable.

----------

## shoober420

Im still getting this error with the new 5.14.1 kernel that just released.

----------

## shoober420

Ive borked compilation of the kernel on my system. This doesnt have anything to do with the kernel version. I've updated something recently that must have broke kernel building on my system. I've tried to downgrade numerous packages like, util-linux, coreutils, binutils, and elfutils. Downgrading these packages still produces the error. Can anyone think of a way I can debug this? Do i need to build the toolchain against stable GCC only? I have recently upgraded to GCC 12 git master, but forced GCC stable using "CC=/usr/bin/gcc", so im runnning out of ideas. Everything else builds fine on my system, even with GCC 12.

----------

## Goverp

No real insights, but some thoughts that might help; apologies if you've already considered them:

fortify-string seems on brief ill-educated Googling to be some security stuff added/moved in the kernel, and also related to glibc, and headers. So, have you changed headers or glibc?

Also, gentoo-sources added a new security configuration item that enables a raft of security flags in your .config.  If you "make olddefconfig" or similar, you may have selected this by default, and maybe that triggered the fortify stuff.

The other one that occurs to me is changes to make.conf and /etc/portage tree, and of course .config itself; I assume you have backups you can compare with.

----------

## shoober420

I was googling the error yesterday and came across people who said "FORTIFY_SOURCE=0" would work, but it still would show that error. I do use glibc-9999, which i was hoping wasnt the issue. I just updated the linux-headers package to use 5.14.1, minus the patches since the gentoo linux-headers package is still on 5.13, and that didnt work either unfortunately. I was just using my previous config from 5.13.13, but of course used "make oldconfig" to tweak the new kernel options. I havent tried with a default config yet. I'll give that a shot. If a default config doesnt work, im going to have to draw the conclusion that glibc-9999 borked something and im going to have to bisect glibc.

----------

## shoober420

it just hit me, i think i know whats going on. so i was using the 5.13 linux-headers, with its patchset when i was on 5.13.13 kernel version. since linux-headers hasnt released a 5.14 patchset for the linux-headers package, my oldconfig is probably configured to work with the old 5.13 gentoo patchset. so any config changes from the gentoo 5.13 patchset from linux-headers package would effect my config file. ive then backed up my normal config and ran "make defconfig" to generate a default config. So far compilation hasnt shown the fortify error at all. so i'll post back if it indeed has to do with the linux-headers 5.13 patchset changing my config options.

EDIT:

THATS IT!!! its because of the patchset which is included in the linux-headers package. since im on 5.14 and linux-headers is still on 5.13, the patches dont work so i had to skip them. but this in return will bork kernel compile since my config options are now tainted by the gentoo 5.13 patchset.

Does anyone know what kernel config settings are changed when using the linux-headers 5.13 patchset on your config?

----------

## DaggyStyle

correct me if I'm wrong, you think this issue is because you are using kernel 5.14.x with linux-headers-5.13?

if so, why I'm not having the same issue? I'd bet glibc is the issue, glibc-9999 is using latest dev head/master/whatever it is called.

logically specking that should be the issue.

why do need glibc-9999 in the first place?

----------

## shoober420

I was manually updating the linux-headers package in my own localrepo to use latest stable, instead of 5.13.0 when i was on 5.13.13 kernel version. that was working fine, but when i tried to use the 5.14 kernel with the linux-headers 5.13 patchset, the patches would fail. i then had to skip the patchset for now and just use 5.14.1 linux-headers which i manually update in my own localrepo. its literally the same linux-headers file, just tweaked to use latest stable instead of 5.13.0 kernel version.

https://github.com/shoober420/shoober420-overlay/blob/main/sys-kernel/linux-headers/linux-headers-5.13.13.ebuild

so i couldnt use the 5.13 linux-headers patchset with the 5.14.1 headers since the patches are incompatible. I tried to do that and it failed unfortunately. so i commented out the patches line in the linux-headers ebuild and just built vanilla 5.14.1 headers for now since there is no 5.14 patchset yet.

https://github.com/shoober420/shoober420-overlay/blob/main/sys-kernel/linux-headers/linux-headers-5.14.1.ebuild#L27

i use glibc-9999 because it feelsgoodman. theres no other feeling in the world having a mostly live 9999 system. my computer is in a completely different dimension.

----------

## DaggyStyle

 *shoober420 wrote:*   

> I was manually updating the linux-headers package in my own localrepo to use latest stable, instead of 5.13.0 when i was on 5.13.13 kernel version. that was working fine, but when i tried to use the 5.14 kernel with the linux-headers 5.13 patchset, the patches would fail. i then had to skip the patchset for now and just use 5.14.1 linux-headers which i manually update in my own localrepo. its literally the same linux-headers file, just tweaked to use latest stable instead of 5.13.0 kernel version.
> 
> https://github.com/shoober420/shoober420-overlay/blob/main/sys-kernel/linux-headers/linux-headers-5.13.13.ebuild
> 
> so i couldnt use the 5.13 linux-headers patchset with the 5.14.1 headers since the patches are incompatible. I tried to do that and it failed unfortunately. so i commented out the patches line in the linux-headers ebuild and just built vanilla 5.14.1 headers for now since there is no 5.14 patchset yet.
> ...

 

why do you need kernel-headers to match the version of the kernel? did you encountered any issues with it?

 *shoober420 wrote:*   

> 
> 
> i use glibc-9999 because it feelsgoodman. theres no other feeling in the world having a mostly live 9999 system.
> 
> 

 

walking on the edge has it benefits, but it has it's drawbacks too...

 *shoober420 wrote:*   

> my computer is in a completely different dimension.

 

I truly don't understand this line, sorry.

----------

## shoober420

using newer kernel-headers makes it easier to open the portal between me and my computer which is in a different dimension

----------

## DaggyStyle

 *shoober420 wrote:*   

> using newer kernel-headers makes it easier to open the portal between me and my computer which is in a different dimension

 

still not following...

do you mean that you and you computer are on different physical dimensions which requires a special kernel based portal to connect?

----------

## Hu

As I understand it, the kernel should not use the headers from sys-kernel/linux-headers, because those are an extracted copy of the kernel's headers.  The kernel should be using the headers it keeps in its own source tree.  The output of the failed compile seems to agree with this: none of the shown paths look like files from sys-kernel/linux-headers; they are all source-relative.

Source fortification is a security feature.  Have you checked whether the warning is actually right?  Maybe you found a real bug.

----------

## DaggyStyle

if my memory serve me right, wasn't there an intention on inject the headers into /proc?

if that is still in motion, it will deprecate linu-headres on later versions, right?

----------

## DaggyStyle

infact, it is already there, see:

```
dagg@NCC-5001D ~/workspace/linux.git $ zgrep IKHEADERS /proc/config.gz 

# CONFIG_IKHEADERS is not set

```

so if I enable it, is there any need for sys-kernel/linux-headers?

----------

## Hu

It might, but it might not.  I can see some people wanting linux-headers deliberately out of phase with the kernel, so that they can build a libc that knows about kernel features they plan to have soon, but do not have now.  I could also see keeping them out of phase so as to build test a libc for use on older kernels, without requiring the development system to run an older kernel.

----------

## shoober420

my computer is basically in its own reality. so for me to be able to reach its plane to interact with it, i need live packages to open the portal

i tried to disable the FORTIFY_SOURCE=0, but that unfortunately didnt work. i also cant compile 5.13.13 anymore, so im not sure what broke. i think its glibc honestly. i would have to bisect glibc some commits back and then rebuild my system and hope for the best at this point. glibc is the only package i havent downgraded yet since its not recommended to do so.

----------

## Hu

Rather than bisect it, why not debug the error?  Check whether the code really will cause an overflow.  Once you've proved it cannot, that may help you understand why this test says it can.

----------

## shoober420

I did some @smart-live-rebuild updates, and a --sync / -DNuav since then, and the 5.14.1 kernel is now compiling without that error message, and compiles as before. no more write overflow error.

----------

## shoober420

wait nevermind, im still getting the error. its for sure something in my .config file, since if i use a default config, the error doesnt show.

does anyone know what possible kernel config option would keep triggering that write overflow error?

----------

## DaggyStyle

disable ASYMMETRIC_PUBLIC_KEY_SUBTYPE

----------

## shoober420

unfortunately, disabling that setting, and symmetric_public_key_subtype and even the symmetric_public_keytype as a whole, didn't fix the error. I'm font going to disable as much cryptography API stuff as possible to see if that fixes it.

EDIT:

disabling as much kernel cryptography APIs settings as possible with my config, which was most of the options, did not fix the error either.

----------

## Hu

As I read the Makefile, DaggyStyle's suggestion should have prevented the affected file from building at all.  How is that file being built if you did as instructed?

```
obj-$(CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE) += public_key.o

```

Also, I see there are only 6 calls in that file to the function which is triggering the warning.  I suggested earlier that you debug this.  Have you tried identifying which of the 6 is an error?

----------

## shoober420

im getting this write overflow error for numerous kernel src files that are built. some build ok, some will show that error.

i downloaded the default config file for arch linux 5.14.1 and tried that out, and still got the error. when i run "make defconfig" and use a vanilla config, it does compile without the error.

it looks like it will be a sesh of enabling and disabling kernel options and building the kernel from here to see which exact setting is causing the error. i'll post back when i find it

'

----------

## Hu

I expect you will find that the option which triggers the error report is the one which enables checking for errors.  If the check for errors is disabled, no error will be detected or reported.  If you just want not to know how many potentially erroneous copies are in the kernel, disable CONFIG_FORTIFY_SOURCE.  If you want to enable that detection, and not build files that fail, disable the configuration options that build those files.  (DaggyStyle gave you one such.  You may need others, since you have unposted other errors.)  If you want your report to be useful, then you should find why source fortification is causing this diagnostic.  Are the copies actually wrong?  Are they right, but written in a way that confuses the source fortification rules?

----------

## shoober420

so ive started a new config config from scratch, using "make defconfig", and have been tweaking from there. ive enable and disabled most of the kernel options that its close enough for now to my old default kernel config. it compiles without the error, with most of the kernel option tweaks i desire.

so i tried to take my old broken kernel config and use "make olddefconfig", to see if that would fix the error, but it still occurs. even a default arch linux kernel config will produce the error as mentioned.

i have linked the full kernel log with all the write_overflow errors here.

https://bugzilla.kernel.org/attachment.cgi?id=298565

more than likely, with how many write_overflow errors there were, i would ndisable something i actually use. i remember i saw amdgpu have a write_overflow error, and theres no way im disabling that.

ive made this new config that compiles without the write_overflow errors, but it doesnt want to boot. can anyone see what option im missing to boot my system? i must mention i use EFI.

https://github.com/shoober420/rootscripts/blob/main/usr/src/linux/.configradeon

----------

## shoober420

nevermind, disabling CONFIG_FORTIFY_SOURCE fixed the issue. although feelsbad less security, this setting is apparently not enabled by default when making a new default config, so i will leave it disabled.

----------

## Hu

 *shoober420 wrote:*   

> ive made this new config that compiles without the write_overflow errors

 

```
# CONFIG_FORTIFY_SOURCE is not set
```

This is probably why there are no more write_overflow errors.  You disabled the option that attempts to detect them, so now they cannot be detected.  In my opinion, this option should be enabled on systems that run untrusted workloads.

Now that you have a working configuration, will you try to find why FORTIFY_SOURCE is reporting errors?

----------

## shoober420

yes, after you mentioned that kernel option, i disabled it and it worked. ive done some considerable debugging and honestly feel it has to do with glibc-9999. i would bisect it, but that could break my system.

----------

## Hu

Why not debug it without bisecting then?  Generate post-processed source from a good system and a bad system, and compare for relevant differences.

----------

