SO_FLOW_DIVERT_TOKEN is a socket option on the SOL_SOCKET layer. It's implemented by flow_divert_token_set(struct socket *so, struct sockopt *sopt) in flow_divert.c. The relevant code is: error = soopt_getm(sopt, &token); if (error) { goto done; } error = soopt_mcopyin(sopt, token); if (error) { goto done; }... done: if (token != NULL) { mbuf_freem(token); } soopt_getm allocates an mbuf. soopt_mcopyin, which should copyin the data for the mbuf from userspace, has the following code: error = copyin(sopt->sopt_val, mtod(m, char *), m->m_len); if (error != 0) { m_freem(m0); return (error); } This means that if the copyin fails, by for example providing an invalid userspace pointer, soopt_mcopyin will free the mbuf. flow_divert_token_set isn't aware of these semantics and if it sees that soopt_mcopyin returns an error it also calls mbuf_freem on that same mbuf which soopy_mcopyin already freed. mbufs are aggressivly cached but with sufficiently full caches m_freem will eventually fall through to freeing back to a zalloc zone, and that zone could potentially be garbage collected leading to the ability to actually exploit such an issue.
AppleIntelCapriController::GetLinkConfig trusts a user-supplied value in the structure input which it uses to index a small table of pointers without bounds checking. The OOB-read pointer is passed to AppleIntelFramebuffer::validateDisplayMode which will read a pointer to a C++ object from that buffer (at offset 2138h) and call a virtual method allowing trivial kernel code execution.
posix_spawn is a complex syscall which takes a lot of arguments from userspace. The third argument is a pointer to a further arguments descriptor in userspace with the following structure (on 32-bit): struct user32__posix_spawn_args_desc { uint32_t attr_size; /* size of attributes block */ uint32_t attrp; /* pointer to block */ uint32_t file_actions_size; /* size of file actions block */ uint32_t file_actions; /* pointer to block */ uint32_t port_actions_size; /* size of port actions block */ uint32_t port_actions; /* pointer to block */ uint32_t mac_extensions_size; uint32_t mac_extensions; uint32_t coal_info_size; uint32_t coal_info; uint32_t persona_info_size; uint32_t persona_info; } port_actions then points to another structure in userspace of this type: struct _posix_spawn_port_actions { int pspa_alloc; int pspa_count; _ps_port_action_t pspa_actions[]; } and finally _ps_port_action_t looks like this: struct _ps_port_action { pspa_t port_type; exception_mask_t mask; mach_port_name_t new_port; exception_behavior_t behavior; thread_state_flavor_t flavor; int which; } Note that pspa_actions is a zero-sized array. pspa_count is supposed to be the number of entries in this array. The following constraints are checked in posix_spawn in kern_exec.c: if (px_args.port_actions_size != 0) { /* Limit port_actions to one page of data */ if (px_args.port_actions_size < PS_PORT_ACTIONS_SIZE(1) || px_args.port_actions_size > PAGE_SIZE) { error = EINVAL; goto bad; PS_PORT_ACTIONS_SIZE is defined like this: #define PS_PORT_ACTIONS_SIZE(x) __offsetof(struct _posix_spawn_port_actions, pspa_actions[(x)]) if port_actions_size passes this then we reach the following code: MALLOC(px_spap, _posix_spawn_port_actions_t, px_args.port_actions_size, M_TEMP, M_WAITOK); if (px_spap == NULL) { error = ENOMEM; goto bad; }
Improper sanitization allows the attacker to override the settings for allowed file extensions and upload file size. This allows the attacker to upload anything they want, bypassing the filters.
The vulnerability allows an attacker to inject sql commands by sending a maliciously crafted HTTP request to the vulnerable application. The attacker can send a specially crafted request to the vulnerable application in order to execute arbitrary SQL commands in the back-end database.
The vulnerability is triggered by ./tools/pal2rgb $FILE /dev/null. The asan debug information shows that 0x611000009fe1 is located 0 bytes to the right of 225-byte region [0x611000009f00,0x611000009fe1) allocated by thread T0. This leads to a heap-buffer-overflow.
An integer overflow vulnerability exists in the kernel libproc API proc_list_uptrs. The vulnerability is caused by an attacker-supplied buffersize being divided by 8 to compute the maximum number of uint64_t's which can fit in the buffer. If the value isn't huge, the attacker-supplied buffersize is used to kalloc the kbuf buffer. The kbuf and buffersize are then passed to kevent_proc_copy_uptrs which returns the number of uint64_t's which were written into the buffer. This value is multiplied by 8 to compute the size of the data which was written into the buffer. This value is compared against the attacker-supplied buffersize and the smaller of the two is used as the size of the data to copy out.
The IOSurfaceRootUserClient external method 17 (s_set_surface_notify) will drop a reference on the wake_port (via IOUserClient::releaseAsyncReference64) then return an error code if the client has previously registered a port with the same callback function. The external method's error return value propagates via the return value of is_io_connect_async_method back to the MIG generated code which will drop a futher reference on the wake_port when only one was taken.
The getrusage() syscall handler in 64-bit processes converts a struct rusage to a struct user64_rusage using munge_user64_rusage(), then copies the struct user64_rusage to userspace. The munge_user64_rusage() performs the conversion by copying individual fields, but the struct user64_rusage contains four bytes of struct padding behind each tv_usec element. This can lead to a buffer overflow if the user does not check the size of the buffer before copying.
When getsockopt() is called on any socket with level SOL_SOCKET and optname SO_NECP_ATTRIBUTES, necp_get_socket_attributes is invoked. necp_get_socket_attributes() unconditionally calls sotoinpcb(so) which causes type confusion if so->so_pcb is of an unexpected type (because the socket is not an IPv4/IPv6 socket). To trigger this bug, compile the code, run it, and cause some system activity, e.g. by launching the browser (the PoC won't crash if so->so_pcb contains NULLs in the right spots).
Services By CQR