bitwarden
Bitwarden AppImage crashes, cant get in to my vault
Steps To Reproduce
Version 2025.1.1 SDK ‘main (28c7e29)’ Shell 33.2.1 Renderer 130.0.6723.137 Node 20.18.1 Architecture x64
I have been using bitwarden (bitwarden.com server) without an issue on fedora (40 Workstation, gnome 46 wayland Linux 6.12.9-100.fc40.x86_64) with AppImages for quite a while but since last update just after pressing enter after my password it crashes without any warning and closes. I did increased my encryption key settings but years ago I use: Argon2id, KDF iterations 6, KDF memory 1024, KDF parallelism 4. My guess is last update did something that limits maybe memory or something? As I could not find anything about this on the internet is not a common issue. I did erase the .config/Bitwarden folder to see if there was a corruption or something there but the crash persists.
To reproduce try to login with your data and it crashes after pressing enter after typing your password
last part of app.log (the last thing i did was try to log and it crashed so it should be here at the end) [2025-01-22 16:34:34.896] [info] Migrator PasswordOptionsMigrator (to version 63) should migrate: false - up [2025-01-22 16:34:34.897] [info] Migrator GeneratorHistoryMigrator (to version 64) should migrate: false - up [2025-01-22 16:34:34.897] [info] Migrator ForwarderOptionsMigrator (to version 65) should migrate: false - up [2025-01-22 16:34:34.897] [info] Migrator MoveFinalDesktopSettingsMigrator (to version 66) should migrate: false - up [2025-01-22 16:34:34.897] [info] Migrator RemoveUnassignedItemsBannerDismissed (to version 67) should migrate: false - up [2025-01-22 16:34:34.897] [info] Migrator MoveLastSyncDate (to version 68) should migrate: false - up [2025-01-22 16:34:35.238] [info] Coredumps are disabled in renderer process [2025-01-22 16:34:37.735] [info] State version: 68 [2025-01-22 16:34:37.829] [info] Retrieving application id [2025-01-22 16:34:40.381] [info] Checking for update [2025-01-22 16:34:41.615] [info] Update for version 2025.1.1 is not available (latest version: 2025.1.1, downgrade is disallowed). [2025-01-22 16:34:46.130] [info] Retrieving application id
Expected Result
I should be asked for my 2fa and let me login afterwards.
Actual Result
the software crashes without a popup or warning it just disappears from screen.
https://github.com/user-attachments/assets/61ce51ec-6fa9-4a22-aeb6-5c356ed75ead
Screenshots or Videos
No response
Additional Context
No response
Operating System
Linux
Operating System Version
Fedora 40 Workstation, gnome 46, wayland, Linux 6.12.9-100.fc40.x86_64
Installation method
Direct Download (from bitwarden.com)
Build Version
Version 2025.1.1 SDK 'main (28c7e29)' Shell 33.2.1 Renderer 130.0.6723.137 Node 20.18.1 Architecture x64
Issue Tracking Info
- [ ] I understand that work is tracked outside of GitHub. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.
Thank you for reporting this issue! We've added this to our internal tracking system. ID: PM-17450
I just tried with a new account without changing key settings and I was able to login so it has to do with something related to memory or something that is now limited. then i tried changing to argon and this different options:
KDF iterations 6, KDF memory 64, KDF parallelism 4/ KDF iterations 6, KDF memory 512, KDF parallelism 4/ KDF iterations 6, KDF memory 768, KDF parallelism 4/ KDF iterations 6, KDF memory 896, KDF parallelism 4/ KDF iterations 6, KDF memory 999, KDF parallelism 4/ KDF iterations 6, KDF memory 1000, KDF parallelism 4/ KDF iterations 6, KDF memory 1012, KDF parallelism 4/ KDF iterations 6, KDF memory 1018, KDF parallelism 4/ KDF iterations 6, KDF memory 1021, KDF parallelism 4/ KDF iterations 6, KDF memory 1023, KDF parallelism 4/ KDF iterations 6, KDF memory 1024, KDF parallelism 4X
just the one with 1024 memory did not let me get in being 1024 the limit of KDF memory allowed to use but the AppImage does not allowed the 1024 but it does 1023 of memory.
I can reproduce this on Ubuntu Desktop 22.04.5 with the AppImage versions 2025.1.3, 2025.1.2, 2025.1.1, and 2025.1.0. After entering the master password, it should prompt for 2fa from my yubikey, but it immediately crashes. This happens even if an incorrect password is used: it doesn't prompt to retry with a new password, it just crashes with "Trace/breakpoint trap (core dumped)".
Clearing $HOME/.config/Bitwarden and $HOME/.cache/com.bitwarden.desktop doesn't result in any changes to the behavior. Reverting back to 2024.12.1 restores functionality:
Version 2024.12.1 SDK 'main (edee180)' Shell 32.1.1 Renderer 128.0.6613.137 Node 20.17.0 Architecture x64
Using the latest release (2025.1.3) and looking at the journal, the issue seems to have something to do with tokio:
Jan 28 15:08:00 kernel: traps: tokio-runtime-w[9018] trap int3 ip:560a01d71ecd sp:72fd33bfd820 error:0 in bitwarden-app[5609fdcce000+8998000] Jan 28 15:08:00 gsd-media-keys[8965]: Trace/breakpoint trap (core dumped) Jan 28 15:08:00 systemd[1]: tmp-.mount_Bitwar5WSLTD.mount: Deactivated successfully. Jan 28 15:08:00 gsd-media-keys[8958]: /home/****/.local/bin/bitwarden: 6: exit: Illegal number: 15:03:55.613 Jan 28 15:08:00 gnome-shell[1919]: ../../../gobject/gsignal.c:2765: instance '0x5bcac52a7b10' has no handler with id '76007'
This log snippet was produced using AppImage 2025.1.3:
Version 2025.1.3 SDK 'main (28c7e29)' Shell 33.2.1 Renderer 130.0.6723.137 Node 20.18.1 Architecture x64
Operating System
Linux
Operating System Version
Ubuntu 22.04.5 LTS, gnome-shell 42.9-0ubuntu2.2, x11, Linux 6.8.0-52-generic (upstream 6.8.12)
Additional Context
I see that commits e8d8a816dd799 and f16bfa4cd2136 have significant changes to the use of tokio between 2024.12.1 and 2025.1.0.
I built the tip of the main branch and the problem persists. It appears there is an unhandled exception. Here's the console output after entering the password and the application crashes:
[Elec] /home/toms/clients/node_modules/electron/dist/electron exited with signal SIGTRAP
[Elec] npx wait-on ./build/main.js && npx electron --no-sandbox --inspect=5858 ./build --watch exited with code 1
--> Sending SIGTERM to other processes..
[Main] [webpack-cli] Gracefully shutting down. To force exit, press ^C again. Please wait...
[Prel] [webpack-cli] Gracefully shutting down. To force exit, press ^C again. Please wait...
[Prel] npm run build:preload:watch exited with code SIGTERM
--> Sending SIGTERM to other processes..
[Main] npm run build:main:watch exited with code SIGTERM
--> Sending SIGTERM to other processes..
[Rend] [webpack-cli] Gracefully shutting down. To force exit, press ^C again. Please wait...
[Rend] npm run build:renderer:watch exited with code SIGTERM
node:internal/process/promises:246
triggerUncaughtException(err, true /* fromPromise */);
^
[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "[object Array]".] {
code: 'ERR_UNHANDLED_REJECTION'
}
I'm not very familiar with the use of promises or debugging of TypeScript and JavaScript. Is there a way to run this with higher granularity debug output?
The issue is tied to the await call on the formPromise for login.. As soon as the await happens, it crashes with the UnhandledPromiseRejectionWarning. The chromium debugger appears to show something regarding "preLogin" in the network tab just before the crash.
Problem still persists as of the latest commit f17cb61183c64 on main.
Yes, that was mentioned previously as the last functional release. Unfortunately, that can still be a pain when first starting the AppImage and the prompt to update appears while entering the password. It's very easy to inadvertently update resulting in the AppImage being replaced with a non-functional image.
@snowplow569's mention of memory was correct. A memory value >= 1024 results in the hash_into_password call failing, resulting in a SIGTRAP. Rust's implementation has a min/max of 8kb to (2^32-1)kb, so an input of 1024 which is converted to 1048576 falls within the acceptable range. Further testing revealed that the max value for the memory parameter that functions without a crash is 1048575, or 1024 * 1024 - 1 (2^20 - 1).
@quexten I was initially correct that the offending commit that introduced the bug is e8d8a816dd799. The Bitwarden implementation for using Rust's Argon2 class looks correct and follows Rust's documentation. It's unclear if it's the constructor that initially consumes the parameters or the hash_into_password() call that is the issue. This change should be reverted or at least partially so until the Rust Argon2 implementation is fully tested with larger memory blocks.
Hello everyone,
Thank you all for your input. This has been flagged internally to Engineering; please feel free to post additional information, such as screenshots or a screen video recordings, if you wish.
Thank you all again,
The root cause of this is in the rust argon2 implementation. It's now been fixed upstream.
The issue was that it was attempting to allocate a vector in the hash_password_into call and it would fail and crash. Either commit e8d8a816dd799 should be reverted so that this doesn't use rust (broken) or manually allocate the memory using the same steps as the library (https://github.com/RustCrypto/password-hashes/blob/0b8ff354d6e42730ee45c9d7d5e582c58b3f5a8c/argon2/src/lib.rs#L288) and call hash_password_into_with_memory. Unless this is done, the fix likely won't come for a very long time.
I'm seeing the same logs on Fedora 42 but I'm not even able to get to the login screen. Just the Migrator messages and no window opening.
