{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2022-49899 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2022-49899 is a high-severity use after free vulnerability in Linux kernel, published on 1 May 2025. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2022-49899 and fix it if it is affected.\n\nWhat it is: CVE-2022-49899 is a high-severity use after free vulnerability in Linux kernel, published on 1 May 2025. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2022-49899 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2022-49899/ (Markdown: https://insights.sbomify.com/CVE-2022-49899/index.md)","id":"CVE-2022-49899","markdown":"https://insights.sbomify.com/CVE-2022-49899/index.md","name":"CVE-2022-49899","record":{"aliases":["DEBIAN-CVE-2022-49899","GHSA-6xrp-v9gf-f7mv","UBUNTU-CVE-2022-49899"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["code_execution","denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel fscrypt","requires_auth":"low_privilege","summary":"A use-after-free vulnerability in the Linux kernel's fscrypt subsystem allows attackers to potentially execute code or cause a denial of service.","user_interaction":"not_required","vuln_class":"use_after_free"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nfscrypt: stop using keyrings subsystem for fscrypt_master_key\n\nThe approach of fs/crypto/ internally managing the fscrypt_master_key\nstructs as the payloads of \"struct key\" objects contained in a\n\"struct key\" keyring has outlived its usefulness.  The original idea was\nto simplify the code by reusing code from the keyrings subsystem.\nHowever, several issues have arisen that can't easily be resolved:\n\n- When a master key struct is destroyed, blk_crypto_evict_key() must be\n  called on any per-mode keys embedded in it.  (This started being the\n  case when inline encryption support was added.)  Yet, the keyrings\n  subsystem can arbitrarily delay the destruction of keys, even past the\n  time the filesystem was unmounted.  Therefore, currently there is no\n  easy way to call blk_crypto_evict_key() when a master key is\n  destroyed.  Currently, this is worked around by holding an extra\n  reference to the filesystem's request_queue(s).  But it was overlooked\n  that the request_queue reference is *not* guaranteed to pin the\n  corresponding blk_crypto_profile too; for device-mapper devices that\n  support inline crypto, it doesn't.  This can cause a use-after-free.\n\n- When the last inode that was using an incompletely-removed master key\n  is evicted, the master key removal is completed by removing the key\n  struct from the keyring.  Currently this is done via key_invalidate().\n  Yet, key_invalidate() takes the key semaphore.  This can deadlock when\n  called from the shrinker, since in fscrypt_ioctl_add_key(), memory is\n  allocated with GFP_KERNEL under the same semaphore.\n\n- More generally, the fact that the keyrings subsystem can arbitrarily\n  delay the destruction of keys (via garbage collection delay, or via\n  random processes getting temporary key references) is undesirable, as\n  it means we can't strictly guarantee that all secrets are ever wiped.\n\n- Doing the master key lookups via the keyrings subsystem results in the\n  key_permission LSM hook being called.  fscrypt doesn't want this, as\n  all access control for encrypted files is designed to happen via the\n  files themselves, like any other files.  The workaround which SELinux\n  users are using is to change their SELinux policy to grant key search\n  access to all domains.  This works, but it is an odd extra step that\n  shouldn't really have to be done.\n\nThe fix for all these issues is to change the implementation to what I\nshould have done originally: don't use the keyrings subsystem to keep\ntrack of the filesystem's fscrypt_master_key structs.  Instead, just\nstore them in a regular kernel data structure, and rework the reference\ncounting, locking, and lifetime accordingly.  Retain support for\nRCU-mode key lookups by using a hash table.  Replace fscrypt_sb_free()\nwith fscrypt_sb_delete(), which releases the keys synchronously and runs\na bit earlier during unmount, so that block devices are still available.\n\nA side effect of this patch is that neither the master keys themselves\nnor the filesystem keyrings will be listed in /proc/keys anymore.\n(\"Master key users\" and the master key users keyrings will still be\nlisted.)  However, this was mostly an implementation detail, and it was\nintended just for debugging purposes.  I don't know of anyone using it.\n\nThis patch does *not* change how \"master key users\" (-\u003emk_users) works;\nthat still uses the keyrings subsystem.  That is still needed for key\nquotas, and changing that isn't necessary to solve the issues listed\nabove.  If we decide to change that too, it would be a separate patch.\n\nI've marked this as fixing the original commit that added the fscrypt\nkeyring, but as noted above the most important issue that this patch\nfixes wasn't introduced until the addition of inline encryption support.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"fscrypt: stop using keyrings subsystem for fscrypt_master_key","id":"CVE-2022-49899","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"use_after_free","year":"2022"},"n_packages":0,"n_references":4,"next":{"headline":"i2c: piix4: Fix adapter not be removed in piix4_remove()","id":"CVE-2022-49900"},"packages":[],"prev":{"headline":"btrfs: fix tree mod log mishandling of reallocated nodes","id":"CVE-2022-49898"},"products":["Linux"],"published":"2025-05-01","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"A use-after-free vulnerability in the Linux kernel's fscrypt subsystem allows attackers to potentially execute code or cause a denial of service.","url":"https://insights.sbomify.com/CVE-2022-49899/"}