Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#62678 - [kernel] [ecryptfs] module not loading in Kernel 5.1.2

Attached to Project: Arch Linux
Opened by SK (skos) - Sunday, 19 May 2019, 09:42 GMT
Last edited by freswa (frederik) - Thursday, 20 February 2020, 21:25 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To No-one
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No



ecryptfs not working, unable to load kernel module

Additional info:
* package version(s)

Linux 5.1.2-arch1-1-AR

* reproduce:

user@Zelos ~]# ecryptfs-mount-private
mount: No such device

[root@Zelos ~]# modprobe ecryptfs
modprobe: ERROR: could not insert 'ecryptfs': Bad address

see also:

use Kernel 4.19.43-1-lts

This task depends upon

Closed by  freswa (frederik)
Thursday, 20 February 2020, 21:25 GMT
Reason for closing:  Fixed
Additional comments about closing:  5.2.10
Comment by Antonio Rojas (arojas) - Sunday, 19 May 2019, 09:52 GMT
Have you restarted after updating the kernel?
Comment by SK (skos) - Sunday, 19 May 2019, 20:21 GMT
well, of course. Linux 5.1.2-arch1-1-AR is the active kernel, according to uname -r

Also I'm not the only one who has this issue - see link to the forum
Comment by Antonio Rojas (arojas) - Monday, 20 May 2019, 11:37 GMT
status with 5.1.3?
Comment by SK (skos) - Monday, 20 May 2019, 18:36 GMT
same error ...

[user@ ~]$ ecryptfs-mount-private
Enter your login passphrase:
Inserted auth tok with sig [ ] into the user session keyring
mount: No such device
[user@ ~]$ su -

[root@ ~]# modprobe ecryptfs
modprobe: ERROR: could not insert 'ecryptfs': Bad address
[root@ ~]# uname -r
[root@Zelos ~]#
Comment by SK (skos) - Saturday, 25 May 2019, 15:56 GMT
and the same with 5.1.4.
Comment by YP (knedlyk) - Sunday, 02 June 2019, 18:36 GMT
The same is for 5.1.6.
Comment by SK (skos) - Wednesday, 05 June 2019, 16:49 GMT
and in 5.1.6

why is is bug still unconfirmed? we now have 3 people (see also forum) with the same problem. Is there some information missing?
Comment by YP (knedlyk) - Wednesday, 05 June 2019, 19:55 GMT
and in 5.1.7 the same. I also tried linux-zen 5.1.7, ecryptfs is broken.
Comment by CrazyT (CrazyT) - Tuesday, 25 June 2019, 16:15 GMT
Can confirm this.

Problem is that the dependend modul "trusted" can not be loaded.
Reason for this seems to be an invalid handling if the bios-setting TPM(Trusted Platform Module) is inactive.
Setting it to disabled instead solves the problem.

I have no idea why "inactive" seems to be the default, since it just makes the module visible to the operating system.
But the module is not working under this state.
But i guess the trusted-module makes no difference between active and inactive and thats the source for the problem.
Comment by loqs (loqs) - Tuesday, 25 June 2019, 18:48 GMT
@CrazyT if you revert c78719203fc629421a0d91d3d22240c36ae0119c , 0b6cf6b97b7ef1fa3c7fefab0cac897a1c4a3400 and 240730437deb213a58915830884e1a99045624dc
in that order can you then load the trusted module with the TPM set to inactive?
Comment by CrazyT (CrazyT) - Wednesday, 26 June 2019, 17:36 GMT
At the moment i do not have the time for compiling.

But i'm already 90% shure that the following new line (line 1251):
causes the problem.
Because there should be a check if the TPM-module is inactive.
Else it would probably just return a fault-code at line 1229 or 1231.
(wich explains why init_module returns EFAULT wich later gets returned as "Bad Address")
Comment by loqs (loqs) - Wednesday, 26 June 2019, 19:16 GMT
I think fixed the issue when a TPM was not present but missed the case of an inactive TPM

@CrazyT could you please contact upstream about the issue, from

perl scripts/ security/keys/trusted.c
James Bottomley <> (supporter:KEYS-TRUSTED)
Jarkko Sakkinen <> (supporter:KEYS-TRUSTED)
Mimi Zohar <> (supporter:KEYS-TRUSTED)
David Howells <> (maintainer:KEYS/KEYRINGS:)
James Morris <> (supporter:SECURITY SUBSYSTEM)
"Serge E. Hallyn" <> (supporter:SECURITY SUBSYSTEM) (open list:KEYS-TRUSTED) (open list:KEYS-TRUSTED) (open list:SECURITY SUBSYSTEM) (open list)

I would suggest the mailing list with a CC to the commit author with CC's also to the supporters listed for keys-trusted
Comment by loqs (loqs) - Monday, 01 July 2019, 17:15 GMT
test.patch first attempt at fixing the issue. Any errors in initialization of the TPM cause the TPM to not be used instead of raising an error.
src.tar.gz included for easier testing.
Build tested only.
Comment by danieltetraquark (danieltetraquark) - Monday, 01 July 2019, 17:32 GMT
I opened a bug a while ago

Currently building, will report back (I'm juphu2Va over at the forum)
Comment by danieltetraquark (danieltetraquark) - Monday, 01 July 2019, 23:33 GMT
The patch works for me, loading the ecryptfs module works fine with it and also mounting directories works as expected.
Comment by CrazyT (CrazyT) - Tuesday, 02 July 2019, 17:37 GMT
I informed upstream and they already told they are working on it.

Your fix is nice, but probably not perfect.
The chip-object will still stay in memory for example.
But as a workaround it should not matter much, since you won't load/unload the module several times during a session.
Comment by loqs (loqs) - Friday, 05 July 2019, 20:52 GMT Comment by loqs (loqs) - Friday, 16 August 2019, 11:03 GMT Comment by SK (skos) - Thursday, 29 August 2019, 19:31 GMT
installed 5.2.10-arch1-1-ARCH and now I can access my ecryptfs protected files again.
The fix seems to work :)
Comment by danieltetraquark (danieltetraquark) - Monday, 02 September 2019, 18:51 GMT
Can confirm that it works with 5.2.10 upwards