Homepage

Use After Free Affecting cluster-md-kmp-default package, versions <6.4.0-150600.23.22.1

Severity

 Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.04% (6th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about Use After Free vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-SLES156-CLUSTERMDKMPDEFAULT-8074973
  • published24 Sept 2024
  • disclosed23 Sept 2024
Report a new vulnerability Found a mistake?

Introduced: 23 Sep 2024

CVE-2024-39510  (opens in a new tab)
CWE-416  (opens in a new tab)

How to fix?

Upgrade SLES:15.6 cluster-md-kmp-default to version 6.4.0-150600.23.22.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream cluster-md-kmp-default package and not the cluster-md-kmp-default package as distributed by SLES. See How to fix? for SLES:15.6 relevant fixed versions and status.

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

cachefiles: fix slab-use-after-free in cachefiles_ondemand_daemon_read()

We got the following issue in a fuzz test of randomly issuing the restore command:

================================================================== BUG: KASAN: slab-use-after-free in cachefiles_ondemand_daemon_read+0xb41/0xb60 Read of size 8 at addr ffff888122e84088 by task ondemand-04-dae/963

CPU: 13 PID: 963 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #564 Call Trace: kasan_report+0x93/0xc0 cachefiles_ondemand_daemon_read+0xb41/0xb60 vfs_read+0x169/0xb50 ksys_read+0xf5/0x1e0

Allocated by task 116: kmem_cache_alloc+0x140/0x3a0 cachefiles_lookup_cookie+0x140/0xcd0 fscache_cookie_state_machine+0x43c/0x1230 [...]

Freed by task 792: kmem_cache_free+0xfe/0x390 cachefiles_put_object+0x241/0x480 fscache_cookie_state_machine+0x5c8/0x1230 [...]

Following is the process that triggers the issue:

 mount  |   daemon_thread1    |    daemon_thread2

cachefiles_withdraw_cookie cachefiles_ondemand_clean_object(object) cachefiles_ondemand_send_req REQ_A = kzalloc(sizeof(*req) + data_len) wait_for_completion(&REQ_A->done)

        cachefiles_daemon_read
         cachefiles_ondemand_daemon_read
          REQ_A = cachefiles_ondemand_select_req
          msg-&gt;object_id = req-&gt;object-&gt;ondemand-&gt;ondemand_id
                              ------ restore ------
                              cachefiles_ondemand_restore
                              xas_for_each(&amp;xas, req, ULONG_MAX)
                               xas_set_mark(&amp;xas, CACHEFILES_REQ_NEW)


                          cachefiles_daemon_read
                           cachefiles_ondemand_daemon_read
                            REQ_A = cachefiles_ondemand_select_req
      copy_to_user(_buffer, msg, n)
       xa_erase(&amp;amp;cache-&amp;gt;reqs, id)
       complete(&amp;amp;REQ_A-&amp;gt;done)
      ------ close(fd) ------
      cachefiles_ondemand_fd_release
       cachefiles_put_object

cachefiles_put_object kmem_cache_free(cachefiles_object_jar, object) REQ_A->object->ondemand->ondemand_id // object UAF !!!

When we see the request within xa_lock, req->object must not have been freed yet, so grab the reference count of object before xa_unlock to avoid the above issue.

CVSS Scores

version 3.1