ghsa-xx7j-2fqw-vv47
Vulnerability from github
Published
2025-09-22 21:30
Modified
2025-09-22 21:30
Details

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix a btf decl_tag bug when tagging a function

syzbot reported a btf decl_tag bug with stack trace below:

general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 3592 Comm: syz-executor914 Not tainted 5.16.0-syzkaller-11424-gb7892f7d5cb2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:btf_type_vlen include/linux/btf.h:231 [inline] RIP: 0010:btf_decl_tag_resolve+0x83e/0xaa0 kernel/bpf/btf.c:3910 ... Call Trace: btf_resolve+0x251/0x1020 kernel/bpf/btf.c:4198 btf_check_all_types kernel/bpf/btf.c:4239 [inline] btf_parse_type_sec kernel/bpf/btf.c:4280 [inline] btf_parse kernel/bpf/btf.c:4513 [inline] btf_new_fd+0x19fe/0x2370 kernel/bpf/btf.c:6047 bpf_btf_load kernel/bpf/syscall.c:4039 [inline] __sys_bpf+0x1cbb/0x5970 kernel/bpf/syscall.c:4679 __do_sys_bpf kernel/bpf/syscall.c:4738 [inline] __se_sys_bpf kernel/bpf/syscall.c:4736 [inline] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4736 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae

The kasan error is triggered with an illegal BTF like below: type 0: void type 1: int type 2: decl_tag to func type 3 type 3: func to func_proto type 8 The total number of types is 4 and the type 3 is illegal since its func_proto type is out of range.

Currently, the target type of decl_tag can be struct/union, var or func. Both struct/union and var implemented their own 'resolve' callback functions and hence handled properly in kernel. But func type doesn't have 'resolve' callback function. When btf_decl_tag_resolve() tries to check func type, it tries to get vlen of its func_proto type, which triggered the above kasan error.

To fix the issue, btf_decl_tag_resolve() needs to do btf_func_check() before trying to accessing func_proto type. In the current implementation, func type is checked with btf_func_check() in the main checking function btf_check_all_types(). To fix the above kasan issue, let us implement 'resolve' callback func type properly. The 'resolve' callback will be also called in btf_check_all_types() for func types.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2022-49228"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:00:59Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a btf decl_tag bug when tagging a function\n\nsyzbot reported a btf decl_tag bug with stack trace below:\n\n  general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN\n  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n  CPU: 0 PID: 3592 Comm: syz-executor914 Not tainted 5.16.0-syzkaller-11424-gb7892f7d5cb2 #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n  RIP: 0010:btf_type_vlen include/linux/btf.h:231 [inline]\n  RIP: 0010:btf_decl_tag_resolve+0x83e/0xaa0 kernel/bpf/btf.c:3910\n  ...\n  Call Trace:\n   \u003cTASK\u003e\n   btf_resolve+0x251/0x1020 kernel/bpf/btf.c:4198\n   btf_check_all_types kernel/bpf/btf.c:4239 [inline]\n   btf_parse_type_sec kernel/bpf/btf.c:4280 [inline]\n   btf_parse kernel/bpf/btf.c:4513 [inline]\n   btf_new_fd+0x19fe/0x2370 kernel/bpf/btf.c:6047\n   bpf_btf_load kernel/bpf/syscall.c:4039 [inline]\n   __sys_bpf+0x1cbb/0x5970 kernel/bpf/syscall.c:4679\n   __do_sys_bpf kernel/bpf/syscall.c:4738 [inline]\n   __se_sys_bpf kernel/bpf/syscall.c:4736 [inline]\n   __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4736\n   do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n   do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe kasan error is triggered with an illegal BTF like below:\n   type 0: void\n   type 1: int\n   type 2: decl_tag to func type 3\n   type 3: func to func_proto type 8\nThe total number of types is 4 and the type 3 is illegal\nsince its func_proto type is out of range.\n\nCurrently, the target type of decl_tag can be struct/union, var or func.\nBoth struct/union and var implemented their own \u0027resolve\u0027 callback functions\nand hence handled properly in kernel.\nBut func type doesn\u0027t have \u0027resolve\u0027 callback function. When\nbtf_decl_tag_resolve() tries to check func type, it tries to get\nvlen of its func_proto type, which triggered the above kasan error.\n\nTo fix the issue, btf_decl_tag_resolve() needs to do btf_func_check()\nbefore trying to accessing func_proto type.\nIn the current implementation, func type is checked with\nbtf_func_check() in the main checking function btf_check_all_types().\nTo fix the above kasan issue, let us implement \u0027resolve\u0027 callback\nfunc type properly. The \u0027resolve\u0027 callback will be also called\nin btf_check_all_types() for func types.",
  "id": "GHSA-xx7j-2fqw-vv47",
  "modified": "2025-09-22T21:30:15Z",
  "published": "2025-09-22T21:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49228"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/796d5666f6422ddadc938fb888044fcc16f2dbe3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a3bcd2110c087bc62e90fddd4a93237b049d6e68"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d7e7b42f4f956f2c68ad8cda87d750093dbba737"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…