{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2022-49721 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2022-49721 is a medium-severity denial of service vulnerability in Linux kernel, published on 26 Feb 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-49721 and fix it if it is affected.\n\nWhat it is: CVE-2022-49721 is a medium-severity denial of service vulnerability in Linux kernel, published on 26 Feb 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-49721 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-49721/ (Markdown: https://insights.sbomify.com/CVE-2022-49721/index.md)","id":"CVE-2022-49721","markdown":"https://insights.sbomify.com/CVE-2022-49721/index.md","name":"CVE-2022-49721","record":{"aliases":["DEBIAN-CVE-2022-49721","GHSA-w33r-f5q6-967f","UBUNTU-CVE-2022-49721"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"low_privilege","summary":"A bug in the Linux kernel's arm64 ftrace implementation can cause a kernel panic when modifying function calls that require PLT entries.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":5.5,"severity":"medium","source":"nvd","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\narm64: ftrace: consistently handle PLTs.\n\nSometimes it is necessary to use a PLT entry to call an ftrace\ntrampoline. This is handled by ftrace_make_call() and ftrace_make_nop(),\nwith each having *almost* identical logic, but this is not handled by\nftrace_modify_call() since its introduction in commit:\n\n  3b23e4991fb66f6d (\"arm64: implement ftrace with regs\")\n\nDue to this, if we ever were to call ftrace_modify_call() for a callsite\nwhich requires a PLT entry for a trampoline, then either:\n\na) If the old addr requires a trampoline, ftrace_modify_call() will use\n   an out-of-range address to generate the 'old' branch instruction.\n   This will result in warnings from aarch64_insn_gen_branch_imm() and\n   ftrace_modify_code(), and no instructions will be modified. As\n   ftrace_modify_call() will return an error, this will result in\n   subsequent internal ftrace errors.\n\nb) If the old addr does not require a trampoline, but the new addr does,\n   ftrace_modify_call() will use an out-of-range address to generate the\n   'new' branch instruction. This will result in warnings from\n   aarch64_insn_gen_branch_imm(), and ftrace_modify_code() will replace\n   the 'old' branch with a BRK. This will result in a kernel panic when\n   this BRK is later executed.\n\nPractically speaking, case (a) is vastly more likely than case (b), and\ntypically this will result in internal ftrace errors that don't\nnecessarily affect the rest of the system. This can be demonstrated with\nan out-of-tree test module which triggers ftrace_modify_call(), e.g.\n\n| # insmod test_ftrace.ko\n| test_ftrace: Function test_function raw=0xffffb3749399201c, callsite=0xffffb37493992024\n| branch_imm_common: offset out of range\n| branch_imm_common: offset out of range\n| ------------[ ftrace bug ]------------\n| ftrace failed to modify\n| [\u003cffffb37493992024\u003e] test_function+0x8/0x38 [test_ftrace]\n|  actual:   1d:00:00:94\n| Updating ftrace call site to call a different ftrace function\n| ftrace record flags: e0000002\n|  (2) R\n|  expected tramp: ffffb374ae42ed54\n| ------------[ cut here ]------------\n| WARNING: CPU: 0 PID: 165 at kernel/trace/ftrace.c:2085 ftrace_bug+0x280/0x2b0\n| Modules linked in: test_ftrace(+)\n| CPU: 0 PID: 165 Comm: insmod Not tainted 5.19.0-rc2-00002-g4d9ead8b45ce #13\n| Hardware name: linux,dummy-virt (DT)\n| pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : ftrace_bug+0x280/0x2b0\n| lr : ftrace_bug+0x280/0x2b0\n| sp : ffff80000839ba00\n| x29: ffff80000839ba00 x28: 0000000000000000 x27: ffff80000839bcf0\n| x26: ffffb37493994180 x25: ffffb374b0991c28 x24: ffffb374b0d70000\n| x23: 00000000ffffffea x22: ffffb374afcc33b0 x21: ffffb374b08f9cc8\n| x20: ffff572b8462c000 x19: ffffb374b08f9000 x18: ffffffffffffffff\n| x17: 6c6c6163202c6331 x16: ffffb374ae5ad110 x15: ffffb374b0d51ee4\n| x14: 0000000000000000 x13: 3435646532346561 x12: 3437336266666666\n| x11: 203a706d61727420 x10: 6465746365707865 x9 : ffffb374ae5149e8\n| x8 : 336266666666203a x7 : 706d617274206465 x6 : 00000000fffff167\n| x5 : ffff572bffbc4a08 x4 : 00000000fffff167 x3 : 0000000000000000\n| x2 : 0000000000000000 x1 : ffff572b84461e00 x0 : 0000000000000022\n| Call trace:\n|  ftrace_bug+0x280/0x2b0\n|  ftrace_replace_code+0x98/0xa0\n|  ftrace_modify_all_code+0xe0/0x144\n|  arch_ftrace_update_code+0x14/0x20\n|  ftrace_startup+0xf8/0x1b0\n|  register_ftrace_function+0x38/0x90\n|  test_ftrace_init+0xd0/0x1000 [test_ftrace]\n|  do_one_initcall+0x50/0x2b0\n|  do_init_module+0x50/0x1f0\n|  load_module+0x17c8/0x1d64\n|  __do_sys_finit_module+0xa8/0x100\n|  __arm64_sys_finit_module+0x2c/0x3c\n|  invoke_syscall+0x50/0x120\n|  el0_svc_common.constprop.0+0xdc/0x100\n|  do_el0_svc+0x3c/0xd0\n|  el0_svc+0x34/0xb0\n|  el0t_64_sync_handler+0xbc/0x140\n|  el0t_64_sync+0x18c/0x190\n| ---[ end trace 0000000000000000 ]---\n\nWe can solve this by consistently determining whether to use a PLT entry\nfor an address.\n\nNote that since (the earlier) commit:\n\n  f1a54ae9\n---truncated---","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":"arm64: ftrace: consistently handle PLTs.","id":"CVE-2022-49721","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"denial_of_service","year":"2022"},"n_packages":0,"n_references":4,"next":{"headline":"ice: Fix memory corruption in VF driver","id":"CVE-2022-49722"},"packages":[],"prev":{"headline":"block: Fix handling of offline queues in blk_mq_alloc_request_hctx()","id":"CVE-2022-49720"},"products":["Linux"],"published":"2025-02-26","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":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-05-11","vendors":["Linux"]},"summary":"A bug in the Linux kernel's arm64 ftrace implementation can cause a kernel panic when modifying function calls that require PLT entries.","url":"https://insights.sbomify.com/CVE-2022-49721/"}