Vulnerabilities

Missing Authorization vulnerability in ThimPress LearnPress.This issue affects LearnPress: from n/a through 4.2.3.

Missing Authorization vulnerability in Hennessey Digital Attorney attorney allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Attorney: from n/a through 3.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vduse: fix memory corruption in vduse_dev_ioctl()<br /> <br /> The "config.offset" comes from the user. There needs to a check to<br /> prevent it being out of bounds. The "config.offset" and<br /> "dev-&gt;config_size" variables are both type u32. So if the offset if<br /> out of bounds then the "dev-&gt;config_size - config.offset" subtraction<br /> results in a very high u32 value. The out of bounds offset can result<br /> in memory corruption.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: netlink: af_netlink: Prevent empty skb by adding a check on len.<br /> <br /> Adding a check on len parameter to avoid empty skb. This prevents a<br /> division error in netem_enqueue function which is caused when skb-&gt;len=0<br /> and skb-&gt;data_len=0 in the randomized corruption step as shown below.<br /> <br /> skb-&gt;data[prandom_u32() % skb_headlen(skb)] ^= 1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix kernel address leakage in atomic cmpxchg&amp;#39;s r0 aux reg<br /> <br /> The implementation of BPF_CMPXCHG on a high level has the following parameters:<br /> <br /> .-[old-val] .-[new-val]<br /> BPF_R0 = cmpxchg{32,64}(DST_REG + insn-&gt;off, BPF_R0, SRC_REG)<br /> `-[mem-loc] `-[old-val]<br /> <br /> Given a BPF insn can only have two registers (dst, src), the R0 is fixed and<br /> used as an auxilliary register for input (old value) as well as output (returning<br /> old value from memory location). While the verifier performs a number of safety<br /> checks, it misses to reject unprivileged programs where R0 contains a pointer as<br /> old value.<br /> <br /> Through brute-forcing it takes about ~16sec on my machine to leak a kernel pointer<br /> with BPF_CMPXCHG. The PoC is basically probing for kernel addresses by storing the<br /> guessed address into the map slot as a scalar, and using the map value pointer as<br /> R0 while SRC_REG has a canary value to detect a matching address.<br /> <br /> Fix it by checking R0 for pointers, and reject if that&amp;#39;s the case for unprivileged<br /> programs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix kernel address leakage in atomic fetch<br /> <br /> The change in commit 37086bfdc737 ("bpf: Propagate stack bounds to registers<br /> in atomics w/ BPF_FETCH") around check_mem_access() handling is buggy since<br /> this would allow for unprivileged users to leak kernel pointers. For example,<br /> an atomic fetch/and with -1 on a stack destination which holds a spilled<br /> pointer will migrate the spilled register type into a scalar, which can then<br /> be exported out of the program (since scalar != pointer) by dumping it into<br /> a map value.<br /> <br /> The original implementation of XADD was preventing this situation by using<br /> a double call to check_mem_access() one with BPF_READ and a subsequent one<br /> with BPF_WRITE, in both cases passing -1 as a placeholder value instead of<br /> register as per XADD semantics since it didn&amp;#39;t contain a value fetch. The<br /> BPF_READ also included a check in check_stack_read_fixed_off() which rejects<br /> the program if the stack slot is of __is_pointer_value() if dst_regno

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scpi: Fix string overflow in SCPI genpd driver<br /> <br /> Without the bound checks for scpi_pd-&gt;name, it could result in the buffer<br /> overflow when copying the SCPI device name from the corresponding device<br /> tree node as the name string is set at maximum size of 30.<br /> <br /> Let us fix it by using devm_kasprintf so that the string buffer is<br /> allocated dynamically.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix null ptr access msm_ioctl_gem_submit()<br /> <br /> Fix the below null pointer dereference in msm_ioctl_gem_submit():<br /> <br /> 26545.260705: Call trace:<br /> 26545.263223: kref_put+0x1c/0x60<br /> 26545.266452: msm_ioctl_gem_submit+0x254/0x744<br /> 26545.270937: drm_ioctl_kernel+0xa8/0x124<br /> 26545.274976: drm_ioctl+0x21c/0x33c<br /> 26545.278478: drm_compat_ioctl+0xdc/0xf0<br /> 26545.282428: __arm64_compat_sys_ioctl+0xc8/0x100<br /> 26545.287169: el0_svc_common+0xf8/0x250<br /> 26545.291025: do_el0_svc_compat+0x28/0x54<br /> 26545.295066: el0_svc_compat+0x10/0x1c<br /> 26545.298838: el0_sync_compat_handler+0xa8/0xcc<br /> 26545.303403: el0_sync_compat+0x188/0x1c0<br /> 26545.307445: Code: d503201f d503201f 52800028 4b0803e8 (b8680008)<br /> 26545.318799: Kernel panic - not syncing: Oops: Fatal exception

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: validate extended element ID is present<br /> <br /> Before attempting to parse an extended element, verify that<br /> the extended element ID is present.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: fix segfault in nfc_genl_dump_devices_done<br /> <br /> When kmalloc in nfc_genl_dump_devices() fails then<br /> nfc_genl_dump_devices_done() segfaults as below<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014<br /> Workqueue: events netlink_sock_destruct_work<br /> RIP: 0010:klist_iter_exit+0x26/0x80<br /> Call Trace:<br /> <br /> class_dev_iter_exit+0x15/0x20<br /> nfc_genl_dump_devices_done+0x3b/0x50<br /> genl_lock_done+0x84/0xd0<br /> netlink_sock_destruct+0x8f/0x270<br /> __sk_destruct+0x64/0x3b0<br /> sk_destruct+0xa8/0xd0<br /> __sk_free+0x2e8/0x3d0<br /> sk_free+0x51/0x90<br /> netlink_sock_destruct_work+0x1c/0x20<br /> process_one_work+0x411/0x710<br /> worker_thread+0x6fd/0xa80

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: virtio: fix completion handling<br /> <br /> The driver currently assumes that the notify callback is only received<br /> when the device is done with all the queued buffers.<br /> <br /> However, this is not true, since the notify callback could be called<br /> without any of the queued buffers being completed (for example, with<br /> virtio-pci and shared interrupts) or with only some of the buffers being<br /> completed (since the driver makes them available to the device in<br /> multiple separate virtqueue_add_sgs() calls).<br /> <br /> This can lead to incorrect data on the I2C bus or memory corruption in<br /> the guest if the device operates on buffers which are have been freed by<br /> the driver. (The WARN_ON in the driver is also triggered.)<br /> <br /> BUG kmalloc-128 (Tainted: G W ): Poison overwritten<br /> First byte 0x0 instead of 0x6b<br /> Allocated in i2cdev_ioctl_rdwr+0x9d/0x1de age=243 cpu=0 pid=28<br /> memdup_user+0x2e/0xbd<br /> i2cdev_ioctl_rdwr+0x9d/0x1de<br /> i2cdev_ioctl+0x247/0x2ed<br /> vfs_ioctl+0x21/0x30<br /> sys_ioctl+0xb18/0xb41<br /> Freed in i2cdev_ioctl_rdwr+0x1bb/0x1de age=68 cpu=0 pid=28<br /> kfree+0x1bd/0x1cc<br /> i2cdev_ioctl_rdwr+0x1bb/0x1de<br /> i2cdev_ioctl+0x247/0x2ed<br /> vfs_ioctl+0x21/0x30<br /> sys_ioctl+0xb18/0xb41<br /> <br /> Fix this by calling virtio_get_buf() from the notify handler like other<br /> virtio drivers and by actually waiting for all the buffers to be<br /> completed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix a user-after-free in add_pble_prm<br /> <br /> When irdma_hmc_sd_one fails, &amp;#39;chunk&amp;#39; is freed while its still on the PBLE<br /> info list.<br /> <br /> Add the chunk entry to the PBLE info list only after successful setting of<br /> the SD in irdma_hmc_sd_one.