GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2024-1837 (CVE-2021-47618)

Vulnerability from osv_openeuler – Published: 2024-07-12 11:07 – Updated: 2026-08-06 11:07 – Source website
VLAI
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ARM: 9170/1: fix panic when kasan and kprobe are enabled

arm32 uses software to simulate the instruction replaced by kprobe. some instructions may be simulated by constructing assembly functions. therefore, before executing instruction simulation, it is necessary to construct assembly function execution environment in C language through binding registers. after kasan is enabled, the register binding relationship will be destroyed, resulting in instruction simulation errors and causing kernel panic.

the kprobe emulate instruction function is distributed in three files: actions-common.c actions-arm.c actions-thumb.c, so disable KASAN when compiling these files.

for example, use kprobe insert on cap_capable+20 after kasan enabled, the cap_capable assembly code is as follows: <cap_capable>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c add r0, r0, #108 ; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [pc, #144] ; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108] ; 0x6c e2859014 add r9, r5, #20 ...... The emulate_ldr assembly code after enabling kasan is as follows: c06f1384 <emulate_ldr>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c add r8, r2, #60 ; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f and sl, r5, #15 0a000001 beq c06f13bc <emulate_ldr+0x38> e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, r4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 add r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 1a000014 bne c06f1430 <emulate_ldr+0xac> e1a06000 mov r6, r0 e2840040 add r0, r4, #64 ; 0x40 ......

when running in emulate_ldr to simulate the ldr instruction, panic occurred, and the log is as follows: Unable to handle kernel NULL pointer dereference at virtual address 00000090 pgd = ecb46400 [00000090] pgd=2e0fa003, pmd=00000000 Internal error: Oops: 206 [#1] SMP ARM PC is at cap_capable+0x14/0xb0 LR is at emulate_ldr+0x50/0xc0 psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 32c5387d Table: 2d546400 DAC: 55555555 Process bash (pid: 1643, stack limit = 0xecd60190) (cap_capable) from (kprobe_handler+0x218/0x340) (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) (do_undefinstr) from (__und_svc_finish+0x0/0x30) (__und_svc_finish) from (cap_capable+0x18/0xb0) (cap_capable) from (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) from (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) from (copy_process.constprop.5+0x16b4/0x25c8) (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) (_do_fork) from (SyS_clone+0x1c/0x24) (SyS_clone) from (__sys_trace_return+0x0/0x10) Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)(CVE-2021-47618)

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

ax25: Fix reference count leak issue of net_device

There is a reference count leak issue of the object "net_device" in ax25_dev_device_down(). When the ax25 device is shutting down, the ax25_dev_device_down() drops the reference count of net_device one or zero times depending on if we goto unlock_put or not, which will cause memory leak.

In order to solve the above issue, decrease the reference count of net_device after dev->ax25_ptr is set to null.(CVE-2024-38554)

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

nilfs2: fix potential hang in nilfs_detach_log_writer()

Syzbot has reported a potential hang in nilfs_detach_log_writer() called during nilfs2 unmount.

Analysis revealed that this is because nilfs_segctor_sync(), which synchronizes with the log writer thread, can be called after nilfs_segctor_destroy() terminates that thread, as shown in the call trace below:

nilfs_detach_log_writer nilfs_segctor_destroy nilfs_segctor_kill_thread --> Shut down log writer thread flush_work nilfs_iput_work_func nilfs_dispose_list iput nilfs_evict_inode nilfs_transaction_commit nilfs_construct_segment (if inode needs sync) nilfs_segctor_sync --> Attempt to synchronize with log writer thread *** DEADLOCK ***

Fix this issue by changing nilfs_segctor_sync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates.

The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)

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

nilfs2: fix use-after-free of timer for log writer thread

Patch series "nilfs2: fix log writer related issues".

This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log.

This patch (of 3):

A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure.

The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime.

Fix this issue by limiting the use of sc_timer only while the log writer thread is alive.(CVE-2024-38583)

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

fs/ntfs3: Check 'folio' pointer for NULL

It can be NULL if bmap is called.(CVE-2024-38625)

Severity
7.0 (High)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-218.0.0.117.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-218.0.0.117.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nARM: 9170/1: fix panic when kasan and kprobe are enabled\r\n\r\narm32 uses software to simulate the instruction replaced\nby kprobe. some instructions may be simulated by constructing\nassembly functions. therefore, before executing instruction\nsimulation, it is necessary to construct assembly function\nexecution environment in C language through binding registers.\nafter kasan is enabled, the register binding relationship will\nbe destroyed, resulting in instruction simulation errors and\ncausing kernel panic.\r\n\r\nthe kprobe emulate instruction function is distributed in three\nfiles: actions-common.c actions-arm.c actions-thumb.c, so disable\nKASAN when compiling these files.\r\n\r\nfor example, use kprobe insert on cap_capable+20 after kasan\nenabled, the cap_capable assembly code is as follows:\n\u0026lt;cap_capable\u0026gt;:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne1a05000\tmov\tr5, r0\ne280006c\tadd\tr0, r0, #108    ; 0x6c\ne1a04001\tmov\tr4, r1\ne1a06002\tmov\tr6, r2\ne59fa090\tldr\tsl, [pc, #144]  ;\nebfc7bf8\tbl\tc03aa4b4 \u0026lt;__asan_load4\u0026gt;\ne595706c\tldr\tr7, [r5, #108]  ; 0x6c\ne2859014\tadd\tr9, r5, #20\n......\nThe emulate_ldr assembly code after enabling kasan is as follows:\nc06f1384 \u0026lt;emulate_ldr\u0026gt;:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne282803c\tadd\tr8, r2, #60     ; 0x3c\ne1a05000\tmov\tr5, r0\ne7e37855\tubfx\tr7, r5, #16, #4\ne1a00008\tmov\tr0, r8\ne1a09001\tmov\tr9, r1\ne1a04002\tmov\tr4, r2\nebf35462\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne357000f\tcmp\tr7, #15\ne7e36655\tubfx\tr6, r5, #12, #4\ne205a00f\tand\tsl, r5, #15\n0a000001\tbeq\tc06f13bc \u0026lt;emulate_ldr+0x38\u0026gt;\ne0840107\tadd\tr0, r4, r7, lsl #2\nebf3545c\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne084010a\tadd\tr0, r4, sl, lsl #2\nebf3545a\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne2890010\tadd\tr0, r9, #16\nebf35458\tbl\tc03c6530 \u0026lt;__asan_load4\u0026gt;\ne5990010\tldr\tr0, [r9, #16]\ne12fff30\tblx\tr0\ne356000f\tcm\tr6, #15\n1a000014\tbne\tc06f1430 \u0026lt;emulate_ldr+0xac\u0026gt;\ne1a06000\tmov\tr6, r0\ne2840040\tadd\tr0, r4, #64     ; 0x40\n......\r\n\r\nwhen running in emulate_ldr to simulate the ldr instruction, panic\noccurred, and the log is as follows:\nUnable to handle kernel NULL pointer dereference at virtual address\n00000090\npgd = ecb46400\n[00000090] *pgd=2e0fa003, *pmd=00000000\nInternal error: Oops: 206 [#1] SMP ARM\nPC is at cap_capable+0x14/0xb0\nLR is at emulate_ldr+0x50/0xc0\npsr: 600d0293 sp : ecd63af8  ip : 00000004  fp : c0a7c30c\nr10: 00000000  r9 : c30897f4  r8 : ecd63cd4\nr7 : 0000000f  r6 : 0000000a  r5 : e59fa090  r4 : ecd63c98\nr3 : c06ae294  r2 : 00000000  r1 : b7611300  r0 : bf4ec008\nFlags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user\nControl: 32c5387d  Table: 2d546400  DAC: 55555555\nProcess bash (pid: 1643, stack limit = 0xecd60190)\n(cap_capable) from (kprobe_handler+0x218/0x340)\n(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)\n(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)\n(do_undefinstr) from (__und_svc_finish+0x0/0x30)\n(__und_svc_finish) from (cap_capable+0x18/0xb0)\n(cap_capable) from (cap_vm_enough_memory+0x38/0x48)\n(cap_vm_enough_memory) from\n(security_vm_enough_memory_mm+0x48/0x6c)\n(security_vm_enough_memory_mm) from\n(copy_process.constprop.5+0x16b4/0x25c8)\n(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)\n(_do_fork) from (SyS_clone+0x1c/0x24)\n(SyS_clone) from (__sys_trace_return+0x0/0x10)\nCode: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)(CVE-2021-47618)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nax25: Fix reference count leak issue of net_device\r\n\r\nThere is a reference count leak issue of the object \u0026quot;net_device\u0026quot; in\nax25_dev_device_down(). When the ax25 device is shutting down, the\nax25_dev_device_down() drops the reference count of net_device one\nor zero times depending on if we goto unlock_put or not, which will\ncause memory leak.\r\n\r\nIn order to solve the above issue, decrease the reference count of\nnet_device after dev-\u0026gt;ax25_ptr is set to null.(CVE-2024-38554)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential hang in nilfs_detach_log_writer()\r\n\r\nSyzbot has reported a potential hang in nilfs_detach_log_writer() called\nduring nilfs2 unmount.\r\n\r\nAnalysis revealed that this is because nilfs_segctor_sync(), which\nsynchronizes with the log writer thread, can be called after\nnilfs_segctor_destroy() terminates that thread, as shown in the call trace\nbelow:\r\n\r\nnilfs_detach_log_writer\n  nilfs_segctor_destroy\n    nilfs_segctor_kill_thread  --\u0026gt; Shut down log writer thread\n    flush_work\n      nilfs_iput_work_func\n        nilfs_dispose_list\n          iput\n            nilfs_evict_inode\n              nilfs_transaction_commit\n                nilfs_construct_segment (if inode needs sync)\n                  nilfs_segctor_sync  --\u0026gt; Attempt to synchronize with\n                                          log writer thread\n                           *** DEADLOCK ***\r\n\r\nFix this issue by changing nilfs_segctor_sync() so that the log writer\nthread returns normally without synchronizing after it terminates, and by\nforcing tasks that are already waiting to complete once after the thread\nterminates.\r\n\r\nThe skipped inode metadata flushout will then be processed together in the\nsubsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix use-after-free of timer for log writer thread\r\n\r\nPatch series \u0026quot;nilfs2: fix log writer related issues\u0026quot;.\r\n\r\nThis bug fix series covers three nilfs2 log writer-related issues,\nincluding a timer use-after-free issue and potential deadlock issue on\nunmount, and a potential freeze issue in event synchronization found\nduring their analysis.  Details are described in each commit log.\r\n\r\n\nThis patch (of 3):\r\n\r\nA use-after-free issue has been reported regarding the timer sc_timer on\nthe nilfs_sc_info structure.\r\n\r\nThe problem is that even though it is used to wake up a sleeping log\nwriter thread, sc_timer is not shut down until the nilfs_sc_info structure\nis about to be freed, and is used regardless of the thread\u0026apos;s lifetime.\r\n\r\nFix this issue by limiting the use of sc_timer only while the log writer\nthread is alive.(CVE-2024-38583)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Check \u0026apos;folio\u0026apos; pointer for NULL\r\n\r\nIt can be NULL if bmap is called.(CVE-2024-38625)",
  "id": "OESA-2024-1837",
  "modified": "2026-08-06T11:07:18Z",
  "published": "2024-07-12T11:07:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1837"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47618"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38554"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38582"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38583"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38625"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47618",
    "CVE-2024-38554",
    "CVE-2024-38582",
    "CVE-2024-38583",
    "CVE-2024-38625"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.