Vulnerabilities

Use of entitlement "com.apple.security.cs.disable-library-validation" and lack of launch and library load constraints allows to substitute a legitimate dylib with malicious one. A local attacker with unprivileged access can execute the application with altered dynamic library successfully bypassing Transparency, Consent, and Control (TCC). Acquired resource access is limited to previously granted permissions by the user. Access to other resources beyond granted-permissions requires user interaction with a system prompt asking for permission.<br /> <br /> This issue affects DaVinci Resolve on macOS in all versions.<br /> Last tested version: 19.1.3

yasm commit 9defefae was discovered to contain a NULL pointer dereference via the yasm_section_bcs_append function at section.c.

tcpreplay v4.4.4 was discovered to contain an infinite loop via the tcprewrite function at get.c.

A vulnerability classified as problematic has been found in gradio-app gradio up to 5.29.1. This affects the function is_valid_origin of the component CORS Handler. The manipulation of the argument localhost_aliases leads to erweiterte Rechte. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

HuoCMS V3.5.1 and before is vulnerable to file upload, which allows attackers to take control of the target server

HuoCMS V3.5.1 has a File Upload Vulnerability. An attacker can exploit this flaw to bypass whitelist restrictions and craft malicious files with specific suffixes, thereby gaining control of the server.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/erofs/fileio: call erofs_onlinefolio_split() after bio_add_folio()<br /> <br /> If bio_add_folio() fails (because it is full),<br /> erofs_fileio_scan_folio() needs to submit the I/O request via<br /> erofs_fileio_rq_submit() and allocate a new I/O request with an empty<br /> `struct bio`. Then it retries the bio_add_folio() call.<br /> <br /> However, at this point, erofs_onlinefolio_split() has already been<br /> called which increments `folio-&gt;private`; the retry will call<br /> erofs_onlinefolio_split() again, but there will never be a matching<br /> erofs_onlinefolio_end() call. This leaves the folio locked forever<br /> and all waiters will be stuck in folio_wait_bit_common().<br /> <br /> This bug has been added by commit ce63cb62d794 ("erofs: support<br /> unencoded inodes for fileio"), but was practically unreachable because<br /> there was room for 256 folios in the `struct bio` - until commit<br /> 9f74ae8c9ac9 ("erofs: shorten bvecs[] for file-backed mounts") which<br /> reduced the array capacity to 16 folios.<br /> <br /> It was now trivial to trigger the bug by manually invoking readahead<br /> from userspace, e.g.:<br /> <br /> posix_fadvise(fd, 0, st.st_size, POSIX_FADV_WILLNEED);<br /> <br /> This should be fixed by invoking erofs_onlinefolio_split() only after<br /> bio_add_folio() has succeeded. This is safe: asynchronous completions<br /> invoking erofs_onlinefolio_end() will not unlock the folio because<br /> erofs_fileio_scan_folio() is still holding a reference to be released<br /> by erofs_onlinefolio_end() at the end.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Fix uninitialized memcache pointer in user_mem_abort()<br /> <br /> Commit fce886a60207 ("KVM: arm64: Plumb the pKVM MMU in KVM") made the<br /> initialization of the local memcache variable in user_mem_abort()<br /> conditional, leaving a codepath where it is used uninitialized via<br /> kvm_pgtable_stage2_map().<br /> <br /> This can fail on any path that requires a stage-2 allocation<br /> without transition via a permission fault or dirty logging.<br /> <br /> Fix this by making sure that memcache is always valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> module: ensure that kobject_put() is safe for module type kobjects<br /> <br /> In &amp;#39;lookup_or_create_module_kobject()&amp;#39;, an internal kobject is created<br /> using &amp;#39;module_ktype&amp;#39;. So call to &amp;#39;kobject_put()&amp;#39; on error handling<br /> path causes an attempt to use an uninitialized completion pointer in<br /> &amp;#39;module_kobject_release()&amp;#39;. In this scenario, we just want to release<br /> kobject without an extra synchronization required for a regular module<br /> unloading process, so adding an extra check whether &amp;#39;complete()&amp;#39; is<br /> actually required makes &amp;#39;kobject_put()&amp;#39; safe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: fix region locking in hash types<br /> <br /> Region locking introduced in v5.6-rc4 contained three macros to handle<br /> the region locks: ahash_bucket_start(), ahash_bucket_end() which gave<br /> back the start and end hash bucket values belonging to a given region<br /> lock and ahash_region() which should give back the region lock belonging<br /> to a given hash bucket. The latter was incorrect which can lead to a<br /> race condition between the garbage collector and adding new elements<br /> when a hash type of set is defined with timeouts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openvswitch: Fix unsafe attribute parsing in output_userspace()<br /> <br /> This patch replaces the manual Netlink attribute iteration in<br /> output_userspace() with nla_for_each_nested(), which ensures that only<br /> well-formed attributes are processed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: m_can: m_can_class_allocate_dev(): initialize spin lock on device probe<br /> <br /> The spin lock tx_handling_spinlock in struct m_can_classdev is not<br /> being initialized. This leads the following spinlock bad magic<br /> complaint from the kernel, eg. when trying to send CAN frames with<br /> cansend from can-utils:<br /> <br /> | BUG: spinlock bad magic on CPU#0, cansend/95<br /> | lock: 0xff60000002ec1010, .magic: 00000000, .owner: /-1, .owner_cpu: 0<br /> | CPU: 0 UID: 0 PID: 95 Comm: cansend Not tainted 6.15.0-rc3-00032-ga79be02bba5c #5 NONE<br /> | Hardware name: MachineWare SIM-V (DT)<br /> | Call Trace:<br /> | [] dump_backtrace+0x1c/0x24<br /> | [] show_stack+0x28/0x34<br /> | [] dump_stack_lvl+0x4a/0x68<br /> | [] dump_stack+0x14/0x1c<br /> | [] spin_dump+0x62/0x6e<br /> | [] do_raw_spin_lock+0xd0/0x142<br /> | [] _raw_spin_lock_irqsave+0x20/0x2c<br /> | [] m_can_start_xmit+0x90/0x34a<br /> | [] dev_hard_start_xmit+0xa6/0xee<br /> | [] sch_direct_xmit+0x114/0x292<br /> | [] __dev_queue_xmit+0x3b0/0xaa8<br /> | [] can_send+0xc6/0x242<br /> | [] raw_sendmsg+0x1a8/0x36c<br /> | [] sock_write_iter+0x9a/0xee<br /> | [] vfs_write+0x184/0x3a6<br /> | [] ksys_write+0xa0/0xc0<br /> | [] __riscv_sys_write+0x14/0x1c<br /> | [] do_trap_ecall_u+0x168/0x212<br /> | [] handle_exception+0x146/0x152<br /> <br /> Initializing the spin lock in m_can_class_allocate_dev solves that<br /> problem.