Skip to content

Ecryptfs does not recognize files and directories after last update #2013

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ufa opened this issue May 15, 2017 · 11 comments
Closed

Ecryptfs does not recognize files and directories after last update #2013

ufa opened this issue May 15, 2017 · 11 comments

Comments

@ufa
Copy link

ufa commented May 15, 2017

Hi,
I have a USB thumb encrypted with ecryptfs and after the update I cannot access my files anymore.
I can mount it normally, but when I access it, it throws me:
ufa@picam:~ $ cd /bau
ufa@picam:/bau $ ls
ls: cannot access programas: No such file or directory
ls: cannot access imagens: No such file or directory
ls: cannot access jogos: No such file or directory
ls: cannot access tmp: No such file or directory
ls: cannot access backup: No such file or directory
d????????? ? ? ? ? ? .Trash-1001
d????????? ? ? ? ? ? tmp
d????????? ? ? ? ? ? programas
d????????? ? ? ? ? ? jogos

etc

Is there a way to fix this or to downgrade the kernel?
@ufa
Copy link
Author

ufa commented May 15, 2017

$uname -a
Linux picam 4.9.24+ #993 Wed Apr 26 17:56:54 BST 2017 armv6l GNU/Linux

@ufa
Copy link
Author

ufa commented May 15, 2017

Just an update.
Plugging the USB thumb in another not updated pi, I could mount and see the files and folders, so the issue is with the new kernel (almost certain with the 4.9).

As it appears to me as a critical bug (one cannot rollback the kernel version), it should have high priority on the bug fix list.

Thanks for all the hard work making Raspbian/Pixel a great OS.

@popcornmix
Copy link
Collaborator 

sudo rpi-update 52241088c1da59a359110d39c1875cda56496764

will get you the last kernel before we moved to 4.9. Does that work?

@popcornmix
Copy link
Collaborator

Capturing dmesg output on 4.9 after mounting the drive and trying to access it would be useful.

@ufa
Copy link
Author

ufa commented May 16, 2017

I will try to downgrade the kernel and attatch the DMESG output too, but I did saw the messages and there wasn't nothing wrong there.
Just to clarify, it does mount the partition without visible errors, but the file names and directories are messed up,so I cannot see or navigate in it.

@popcornmix
Copy link
Collaborator

I'd be interested what lsmod shows after mounting on both 4.4 and 4.9 kernels.
It may be worth trying sudo modprobe ecryptfs on 4.9 before mounting.

I did find a report that 4.7 works and 4.8 does not for one user:
https://forum.manjaro.org/t/kernel-4-8-breaks-encryption/11971

@popcornmix
Copy link
Collaborator

Another similar report:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1682410

@popcornmix
Copy link
Collaborator

Possibly this:

The ability to look up plaintext and encrypted filenames, under the same eCryptfs mount point, has been disabled with the following commit in 4.7

https://unix.stackexchange.com/questions/314255/ecryptfs-mounting-failure-from-kernel-4-7-onwards/314266

@ufa
Copy link
Author

ufa commented May 16, 2017

Yeah, that could well be the case here. I have plain and encrypted file names.
So, I will try to rename the ones unencrypted to see if it gets fixed.

@ufa
Copy link
Author

ufa commented May 16, 2017

Ok, I'm moving the files to another partition, and then move them to the all filename encrypted partition again. It will take a while, but I will post results as soon as it finishes

@ufa
Copy link
Author

ufa commented May 18, 2017

Just a follow up, I confirm that the problem is related with kernel changes on 4.7 and above. After making all files filename-encrypted, it worked again.
So you cannot mix files with plain and encrypted filenames in the same partition.
Maybe a warning should be added in the update from kernels below 4.7.

@ufa ufa closed this as completed May 18, 2017
popcornmix pushed a commit that referenced this issue Nov 11, 2019
@idosch @davem330
netdevsim: Fix use-after-free during device dismantle
6d6f038 
Commit da58f90 ("netdevsim: Add devlink-trap support") added
delayed work to netdevsim that periodically iterates over the registered
netdevsim ports and reports various packet traps via devlink.

While the delayed work takes the 'port_list_lock' mutex to protect
against concurrent addition / deletion of ports, during device creation
/ dismantle ports are added / deleted without this lock, which can
result in a use-after-free [1].

Fix this by making sure that the ports list is always modified under the
lock.

[1]
[   59.205543] ==================================================================
[   59.207748] BUG: KASAN: use-after-free in nsim_dev_trap_report_work+0xa67/0xad0
[   59.210247] Read of size 8 at addr ffff8883cbdd3398 by task kworker/3:1/38
[   59.212584]
[   59.213148] CPU: 3 PID: 38 Comm: kworker/3:1 Not tainted 5.4.0-rc3-custom-16119-ge6abb5f0261e #2013
[   59.215896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20180724_192412-buildhw-07.phx2.fedoraproject.org-1.fc29 04/01/2014
[   59.218384] Workqueue: events nsim_dev_trap_report_work
[   59.219428] Call Trace:
[   59.219924]  dump_stack+0xa9/0x10e
[   59.220623]  print_address_description.constprop.4+0x21/0x340
[   59.221976]  ? vprintk_func+0x66/0x240
[   59.222752]  __kasan_report.cold.8+0x78/0x91
[   59.223602]  ? nsim_dev_trap_report_work+0xa67/0xad0
[   59.224603]  kasan_report+0xe/0x20
[   59.225296]  nsim_dev_trap_report_work+0xa67/0xad0
[   59.226435]  ? rcu_read_lock_sched_held+0xaf/0xe0
[   59.227512]  ? trace_event_raw_event_rcu_quiescent_state_report+0x360/0x360
[   59.228851]  process_one_work+0x98f/0x1760
[   59.229684]  ? pwq_dec_nr_in_flight+0x330/0x330
[   59.230656]  worker_thread+0x91/0xc40
[   59.231587]  ? process_one_work+0x1760/0x1760
[   59.232451]  kthread+0x34a/0x410
[   59.233104]  ? __kthread_queue_delayed_work+0x240/0x240
[   59.234141]  ret_from_fork+0x3a/0x50
[   59.234982]
[   59.235371] Allocated by task 187:
[   59.236189]  save_stack+0x19/0x80
[   59.236853]  __kasan_kmalloc.constprop.5+0xc1/0xd0
[   59.237822]  kmem_cache_alloc_trace+0x14c/0x380
[   59.238769]  __nsim_dev_port_add+0xaf/0x5c0
[   59.239627]  nsim_dev_probe+0x4fc/0x1140
[   59.240550]  really_probe+0x264/0xc00
[   59.241418]  driver_probe_device+0x208/0x2e0
[   59.242255]  __device_attach_driver+0x215/0x2d0
[   59.243150]  bus_for_each_drv+0x154/0x1d0
[   59.243944]  __device_attach+0x1ba/0x2b0
[   59.244923]  bus_probe_device+0x1dd/0x290
[   59.245805]  device_add+0xbac/0x1550
[   59.246528]  new_device_store+0x1f4/0x400
[   59.247306]  bus_attr_store+0x7b/0xa0
[   59.248047]  sysfs_kf_write+0x10f/0x170
[   59.248941]  kernfs_fop_write+0x283/0x430
[   59.249843]  __vfs_write+0x81/0x100
[   59.250546]  vfs_write+0x1ce/0x510
[   59.251190]  ksys_write+0x104/0x200
[   59.251873]  do_syscall_64+0xa4/0x4e0
[   59.252642]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   59.253837]
[   59.254203] Freed by task 187:
[   59.254811]  save_stack+0x19/0x80
[   59.255463]  __kasan_slab_free+0x125/0x170
[   59.256265]  kfree+0x100/0x440
[   59.256870]  nsim_dev_remove+0x98/0x100
[   59.257651]  nsim_bus_remove+0x16/0x20
[   59.258382]  device_release_driver_internal+0x20b/0x4d0
[   59.259588]  bus_remove_device+0x2e9/0x5a0
[   59.260551]  device_del+0x410/0xad0
[   59.263777]  device_unregister+0x26/0xc0
[   59.264616]  nsim_bus_dev_del+0x16/0x60
[   59.265381]  del_device_store+0x2d6/0x3c0
[   59.266295]  bus_attr_store+0x7b/0xa0
[   59.267192]  sysfs_kf_write+0x10f/0x170
[   59.267960]  kernfs_fop_write+0x283/0x430
[   59.268800]  __vfs_write+0x81/0x100
[   59.269551]  vfs_write+0x1ce/0x510
[   59.270252]  ksys_write+0x104/0x200
[   59.270910]  do_syscall_64+0xa4/0x4e0
[   59.271680]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   59.272812]
[   59.273211] The buggy address belongs to the object at ffff8883cbdd3200
[   59.273211]  which belongs to the cache kmalloc-512 of size 512
[   59.275838] The buggy address is located 408 bytes inside of
[   59.275838]  512-byte region [ffff8883cbdd3200, ffff8883cbdd3400)
[   59.278151] The buggy address belongs to the page:
[   59.279215] page:ffffea000f2f7400 refcount:1 mapcount:0 mapping:ffff8883ecc0ce00 index:0x0 compound_mapcount: 0
[   59.281449] flags: 0x200000000010200(slab|head)
[   59.282356] raw: 0200000000010200 ffffea000f2f3a08 ffffea000f2fd608 ffff8883ecc0ce00
[   59.283949] raw: 0000000000000000 0000000000150015 00000001ffffffff 0000000000000000
[   59.285608] page dumped because: kasan: bad access detected
[   59.286981]
[   59.287337] Memory state around the buggy address:
[   59.288310]  ffff8883cbdd3280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   59.289763]  ffff8883cbdd3300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   59.291452] >ffff8883cbdd3380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[   59.292945]                             ^
[   59.293815]  ffff8883cbdd3400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   59.295220]  ffff8883cbdd3480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   59.296872] ==================================================================

Fixes: da58f90 ("netdevsim: Add devlink-trap support")
Signed-off-by: Ido Schimmel <[email protected]>
Reported-by: [email protected]
Acked-by: Jakub Kicinski <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@popcornmix @ufa