{"id":"DEBIAN-CVE-2024-53171","details":"In the Linux kernel, the following vulnerability has been resolved:  ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit  After an insertion in TNC, the tree might split and cause a node to change its `znode-\u003eparent`. A further deletion of other nodes in the tree (which also could free the nodes), the aforementioned node's `znode-\u003ecparent` could still point to a freed node. This `znode-\u003ecparent` may not be updated when getting nodes to commit in `ubifs_tnc_start_commit()`. This could then trigger a use-after-free when accessing the `znode-\u003ecparent` in `write_index()` in `ubifs_tnc_end_commit()`.  This can be triggered by running    rm -f /etc/test-file.bin   dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync  in a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then reports:    BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950   Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153    Call trace:    dump_backtrace+0x0/0x340    show_stack+0x18/0x24    dump_stack_lvl+0x9c/0xbc    print_address_description.constprop.0+0x74/0x2b0    kasan_report+0x1d8/0x1f0    kasan_check_range+0xf8/0x1a0    memcpy+0x84/0xf4    ubifs_tnc_end_commit+0xa5c/0x1950    do_commit+0x4e0/0x1340    ubifs_bg_thread+0x234/0x2e0    kthread+0x36c/0x410    ret_from_fork+0x10/0x20    Allocated by task 401:    kasan_save_stack+0x38/0x70    __kasan_kmalloc+0x8c/0xd0    __kmalloc+0x34c/0x5bc    tnc_insert+0x140/0x16a4    ubifs_tnc_add+0x370/0x52c    ubifs_jnl_write_data+0x5d8/0x870    do_writepage+0x36c/0x510    ubifs_writepage+0x190/0x4dc    __writepage+0x58/0x154    write_cache_pages+0x394/0x830    do_writepages+0x1f0/0x5b0    filemap_fdatawrite_wbc+0x170/0x25c    file_write_and_wait_range+0x140/0x190    ubifs_fsync+0xe8/0x290    vfs_fsync_range+0xc0/0x1e4    do_fsync+0x40/0x90    __arm64_sys_fsync+0x34/0x50    invoke_syscall.constprop.0+0xa8/0x260    do_el0_svc+0xc8/0x1f0    el0_svc+0x34/0x70    el0t_64_sync_handler+0x108/0x114    el0t_64_sync+0x1a4/0x1a8    Freed by task 403:    kasan_save_stack+0x38/0x70    kasan_set_track+0x28/0x40    kasan_set_free_info+0x28/0x4c    __kasan_slab_free+0xd4/0x13c    kfree+0xc4/0x3a0    tnc_delete+0x3f4/0xe40    ubifs_tnc_remove_range+0x368/0x73c    ubifs_tnc_remove_ino+0x29c/0x2e0    ubifs_jnl_delete_inode+0x150/0x260    ubifs_evict_inode+0x1d4/0x2e4    evict+0x1c8/0x450    iput+0x2a0/0x3c4    do_unlinkat+0x2cc/0x490    __arm64_sys_unlinkat+0x90/0x100    invoke_syscall.constprop.0+0xa8/0x260    do_el0_svc+0xc8/0x1f0    el0_svc+0x34/0x70    el0t_64_sync_handler+0x108/0x114    el0t_64_sync+0x1a4/0x1a8  The offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free when a node becomes root in TNC but still has a `cparent` to an already freed node. More specifically, consider the following TNC:           zroot          /         /       zp1       /      /     zn  Inserting a new node `zn_new` with a key smaller then `zn` will trigger a split in `tnc_insert()` if `zp1` is full:           zroot          /   \\         /     \\       zp1     zp2       /         \\      /           \\   zn_new          zn  `zn-\u003eparent` has now been moved to `zp2`, *but* `zn-\u003ecparent` still points to `zp1`.  Now, consider a removal of all the nodes _except_ `zn`. Just when `tnc_delete()` is about to delete `zroot` and `zp2`:           zroot              \\               \\               zp2                 \\                  \\                  zn  `zroot` and `zp2` get freed and the tree collapses:             zn  `zn` now becomes the new `zroot`.  `get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and `write_index()` will check its `znode-\u003ecparent` that wrongly points to the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called with `znode-\u003ecparent-\u003ezbranch[znode-\u003eiip].hash` that triggers the use-after-free!  Fix this by explicitly setting `znode-\u003ecparent` to `NULL` in `get_znodes_to_commit()` for the root node. The search for the dirty nodes ---truncated---","modified":"2026-09-15T09:02:59.826079879Z","published":"2024-12-27T14:15:24.300Z","upstream":["CVE-2024-53171"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2024-53171"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:12","purl":"pkg:deb/debian/linux?arch=source&distro=bookworm"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.123-1"}]}],"versions":["6.1.106-1","6.1.106-2","6.1.106-3","6.1.112-1","6.1.115-1","6.1.119-1","6.1.27-1","6.1.37-1","6.1.38-1","6.1.38-2","6.1.38-2~bpo11+1","6.1.38-3","6.1.38-4","6.1.38-4~bpo11+1","6.1.52-1","6.1.55-1","6.1.55-1~bpo11+1","6.1.64-1","6.1.66-1","6.1.67-1","6.1.69-1","6.1.69-1~bpo11+1","6.1.76-1","6.1.76-1~bpo11+1","6.1.82-1","6.1.85-1","6.1.90-1","6.1.90-1~bpo11+1","6.1.94-1","6.1.94-1~bpo11+1","6.1.98-1","6.1.99-1"],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2024-53171.json"}},{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.12.3-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2024-53171.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.12.3-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2024-53171.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}]}