ghsa-hwc8-wrmm-ch4w
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
tracing: Ensure visibility when inserting an element into tracing_map
Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries:
$ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc)
The warning looks as follows:
[ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracing_map_sort_entries+0x3e0/0x408 [ 2911.195220] hist_show+0x124/0x800 [ 2911.195692] seq_read_iter+0x1d4/0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [ 2911.197078] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [ 2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]---
The problem appears to be caused by CPU reordering of writes issued from __tracing_map_insert().
The check for the presence of an element with a given key in this function is:
val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ...
The write of a new entry is:
elt = get_free_elt(map); memcpy(elt->key, key, map->key_size); entry->val = elt;
The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-26645"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-26T16:15:12Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Ensure visibility when inserting an element into tracing_map\n\nRunning the following two commands in parallel on a multi-processor\nAArch64 machine can sporadically produce an unexpected warning about\nduplicate histogram entries:\n\n $ while true; do\n echo hist:key=id.syscall:val=hitcount \u003e \\\n /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger\n cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist\n sleep 0.001\n done\n $ stress-ng --sysbadaddr $(nproc)\n\nThe warning looks as follows:\n\n[ 2911.172474] ------------[ cut here ]------------\n[ 2911.173111] Duplicates detected: 1\n[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408\n[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)\n[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1\n[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01\n[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018\n[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408\n[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408\n[ 2911.185310] sp : ffff8000a1513900\n[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001\n[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008\n[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180\n[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff\n[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8\n[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731\n[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c\n[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8\n[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000\n[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480\n[ 2911.194259] Call trace:\n[ 2911.194626] tracing_map_sort_entries+0x3e0/0x408\n[ 2911.195220] hist_show+0x124/0x800\n[ 2911.195692] seq_read_iter+0x1d4/0x4e8\n[ 2911.196193] seq_read+0xe8/0x138\n[ 2911.196638] vfs_read+0xc8/0x300\n[ 2911.197078] ksys_read+0x70/0x108\n[ 2911.197534] __arm64_sys_read+0x24/0x38\n[ 2911.198046] invoke_syscall+0x78/0x108\n[ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8\n[ 2911.199157] do_el0_svc+0x28/0x40\n[ 2911.199613] el0_svc+0x40/0x178\n[ 2911.200048] el0t_64_sync_handler+0x13c/0x158\n[ 2911.200621] el0t_64_sync+0x1a8/0x1b0\n[ 2911.201115] ---[ end trace 0000000000000000 ]---\n\nThe problem appears to be caused by CPU reordering of writes issued from\n__tracing_map_insert().\n\nThe check for the presence of an element with a given key in this\nfunction is:\n\n val = READ_ONCE(entry-\u003eval);\n if (val \u0026\u0026 keys_match(key, val-\u003ekey, map-\u003ekey_size)) ...\n\nThe write of a new entry is:\n\n elt = get_free_elt(map);\n memcpy(elt-\u003ekey, key, map-\u003ekey_size);\n entry-\u003eval = elt;\n\nThe \"memcpy(elt-\u003ekey, key, map-\u003ekey_size);\" and \"entry-\u003eval = elt;\"\nstores may become visible in the reversed order on another CPU. This\nsecond CPU might then incorrectly determine that a new key doesn\u0027t match\nan already present val-\u003ekey and subse\n---truncated---",
"id": "GHSA-hwc8-wrmm-ch4w",
"modified": "2024-06-27T12:30:44Z",
"published": "2024-03-26T18:32:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26645"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b44760609e9eaafc9d234a6883d042fc21132a7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac94122331c30fb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- 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.