CVSS: 6.7EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47609 – firmware: arm_scpi: Fix string overflow in SCPI genpd driver
https://notcve.org/view.php?id=CVE-2021-47609
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scpi: Fix string overflow in SCPI genpd driver Without the bound checks for scpi_pd->name, it could result in the buffer overflow when copying the SCPI device name from the corresponding device tree node as the name string is set at maximum size of 30. Let us fix it by using devm_kasprintf so that the string buffer is allocated dynamically. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scpi: corrige el desbordamiento de cadena en el controlador SCPI genpd. Sin las comprobaciones vinculadas para scpi_pd->name, podría provocar un desbordamiento del búfer al copiar el nombre del dispositivo SCPI del dispositivo correspondiente. El nodo del árbol como cadena de nombre se establece en un tamaño máximo de 30. Arreglemoslo usando devm_kasprintf para que el búfer de cadena se asigne dinámicamente. • https://git.kernel.org/stable/c/8bec4337ad4023b26de35d3b0c3a3b2735ffc5c7 https://git.kernel.org/stable/c/639901b9429a3195e0fead981ed74b51f5f31538 https://git.kernel.org/stable/c/4694b1ec425a2d20d6f8ca3db594829fdf5f2672 https://git.kernel.org/stable/c/7e8645ca2c0046f7cd2f0f7d569fc036c8abaedb https://git.kernel.org/stable/c/802a1a8501563714a5fe8824f4ed27fec04a0719 https://git.kernel.org/stable/c/f0f484714f35d24ffa0ecb4afe3df1c5b225411d https://git.kernel.org/stable/c/976389cbb16cee46847e5d06250a3a0b5506781e https://git.kernel.org/stable/c/865ed67ab955428b9aa771d8b4f1e4fb7 • CWE-787: Out-of-bounds Write •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47608 – bpf: Fix kernel address leakage in atomic fetch
https://notcve.org/view.php?id=CVE-2021-47608
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix kernel address leakage in atomic fetch The change in commit 37086bfdc737 ("bpf: Propagate stack bounds to registers in atomics w/ BPF_FETCH") around check_mem_access() handling is buggy since this would allow for unprivileged users to leak kernel pointers. For example, an atomic fetch/and with -1 on a stack destination which holds a spilled pointer will migrate the spilled register type into a scalar, which can then be exported out of the program (since scalar != pointer) by dumping it into a map value. The original implementation of XADD was preventing this situation by using a double call to check_mem_access() one with BPF_READ and a subsequent one with BPF_WRITE, in both cases passing -1 as a placeholder value instead of register as per XADD semantics since it didn't contain a value fetch. The BPF_READ also included a check in check_stack_read_fixed_off() which rejects the program if the stack slot is of __is_pointer_value() if dst_regno < 0. The latter is to distinguish whether we're dealing with a regular stack spill/ fill or some arithmetical operation which is disallowed on non-scalars, see also 6e7e63cbb023 ("bpf: Forbid XADD on spilled pointers for unprivileged users") for more context on check_mem_access() and its handling of placeholder value -1. One minimally intrusive option to fix the leak is for the BPF_FETCH case to initially check the BPF_READ case via check_mem_access() with -1 as register, followed by the actual load case with non-negative load_reg to propagate stack bounds to registers. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige la fuga de la dirección del kernel en la recuperación atómica. • https://git.kernel.org/stable/c/37086bfdc737ea6f66bf68dcf16757004d68e1e1 https://git.kernel.org/stable/c/423628125a484538111c2c6d9bb1588eb086053b https://git.kernel.org/stable/c/7d3baf0afa3aa9102d6a521a8e4c41888bb79882 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47607 – bpf: Fix kernel address leakage in atomic cmpxchg's r0 aux reg
https://notcve.org/view.php?id=CVE-2021-47607
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix kernel address leakage in atomic cmpxchg's r0 aux reg The implementation of BPF_CMPXCHG on a high level has the following parameters: .-[old-val] .-[new-val] BPF_R0 = cmpxchg{32,64}(DST_REG + insn->off, BPF_R0, SRC_REG) `-[mem-loc] `-[old-val] Given a BPF insn can only have two registers (dst, src), the R0 is fixed and used as an auxilliary register for input (old value) as well as output (returning old value from memory location). While the verifier performs a number of safety checks, it misses to reject unprivileged programs where R0 contains a pointer as old value. Through brute-forcing it takes about ~16sec on my machine to leak a kernel pointer with BPF_CMPXCHG. The PoC is basically probing for kernel addresses by storing the guessed address into the map slot as a scalar, and using the map value pointer as R0 while SRC_REG has a canary value to detect a matching address. Fix it by checking R0 for pointers, and reject if that's the case for unprivileged programs. • https://git.kernel.org/stable/c/5ffa25502b5ab3d639829a2d1e316cff7f59a41e https://git.kernel.org/stable/c/f87a6c160ecc8c7b417d25f508d3f076fe346136 https://git.kernel.org/stable/c/a82fe085f344ef20b452cd5f481010ff96b5c4cd •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47606 – net: netlink: af_netlink: Prevent empty skb by adding a check on len.
https://notcve.org/view.php?id=CVE-2021-47606
In the Linux kernel, the following vulnerability has been resolved: net: netlink: af_netlink: Prevent empty skb by adding a check on len. Adding a check on len parameter to avoid empty skb. This prevents a division error in netem_enqueue function which is caused when skb->len=0 and skb->data_len=0 in the randomized corruption step as shown below. skb->data[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8); Crash Report: [ 343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family 0 port 6081 - 0 [ 343.216110] netem: version 1.3 [ 343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+ [ 343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 [ 343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem] [ 343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff ff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f 74 <f7> f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03 [ 343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246 [ 343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX: 0000000000000000 [ 343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI: ffff88800f8eda40 [ 343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09: ffffffff94fb8445 [ 343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12: 0000000000000000 [ 343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15: 0000000000000020 [ 343.247291] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000) knlGS:0000000000000000 [ 343.248350] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4: 00000000000006e0 [ 343.250076] Call Trace: [ 343.250423] <TASK> [ 343.250713] ? memcpy+0x4d/0x60 [ 343.251162] ? netem_init+0xa0/0xa0 [sch_netem] [ 343.251795] ? __sanitizer_cov_trace_pc+0x21/0x60 [ 343.252443] netem_enqueue+0xe28/0x33c0 [sch_netem] [ 343.253102] ? • https://git.kernel.org/stable/c/c54a60c8fbaa774f828e26df79f66229a8a0e010 https://git.kernel.org/stable/c/40cf2e058832d9cfaae98dfd77334926275598b6 https://git.kernel.org/stable/c/54e785f7d5c197bc06dbb8053700df7e2a093ced https://git.kernel.org/stable/c/ff3f517bf7138e01a17369042908a3f345c0ee41 https://git.kernel.org/stable/c/c0315e93552e0d840e9edc6abd71c7db82ec8f51 https://git.kernel.org/stable/c/dadce61247c6230489527cc5e343b6002d1114c5 https://git.kernel.org/stable/c/4c986072a8c9249b9398c7a18f216dc26a9f0e35 https://git.kernel.org/stable/c/f123cffdd8fe8ea6c7fded4b88516a427 • CWE-369: Divide By Zero •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47605 – vduse: fix memory corruption in vduse_dev_ioctl()
https://notcve.org/view.php?id=CVE-2021-47605
In the Linux kernel, the following vulnerability has been resolved: vduse: fix memory corruption in vduse_dev_ioctl() The "config.offset" comes from the user. There needs to a check to prevent it being out of bounds. The "config.offset" and "dev->config_size" variables are both type u32. So if the offset if out of bounds then the "dev->config_size - config.offset" subtraction results in a very high u32 value. The out of bounds offset can result in memory corruption. • https://git.kernel.org/stable/c/c8a6153b6c59d95c0e091f053f6f180952ade91e https://git.kernel.org/stable/c/e6c67560b4341914bec32ec536e931c22062af65 https://git.kernel.org/stable/c/ff9f9c6e74848170fcb45c8403c80d661484c8c9 •