Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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.

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 /> net/sched: sch_ets: don&amp;#39;t remove idle classes from the round-robin list<br /> <br /> Shuang reported that the following script:<br /> <br /> 1) tc qdisc add dev ddd0 handle 10: parent 1: ets bands 8 strict 4 priomap 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7<br /> 2) mausezahn ddd0 -A 10.10.10.1 -B 10.10.10.2 -c 0 -a own -b 00:c1:a0:c1:a0:00 -t udp &amp;<br /> 3) tc qdisc change dev ddd0 handle 10: ets bands 4 strict 2 quanta 2500 2500 priomap 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3<br /> <br /> crashes systematically when line 2) is commented:<br /> <br /> list_del corruption, ffff8e028404bd30-&gt;next is LIST_POISON1 (dead000000000100)<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:47!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 954 Comm: tc Not tainted 5.16.0-rc4+ #478<br /> Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014<br /> RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47<br /> Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe<br /> RSP: 0018:ffffae46807a3888 EFLAGS: 00010246<br /> RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202<br /> RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff<br /> RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff<br /> R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800<br /> R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400<br /> FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000682f48 CR3: 00000001058be000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> ets_qdisc_change+0x58b/0xa70 [sch_ets]<br /> tc_modify_qdisc+0x323/0x880<br /> rtnetlink_rcv_msg+0x169/0x4a0<br /> netlink_rcv_skb+0x50/0x100<br /> netlink_unicast+0x1a5/0x280<br /> netlink_sendmsg+0x257/0x4d0<br /> sock_sendmsg+0x5b/0x60<br /> ____sys_sendmsg+0x1f2/0x260<br /> ___sys_sendmsg+0x7c/0xc0<br /> __sys_sendmsg+0x57/0xa0<br /> do_syscall_64+0x3a/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7efdc8031338<br /> Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55<br /> RSP: 002b:00007ffdf1ce9828 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 0000000061b37a97 RCX: 00007efdc8031338<br /> RDX: 0000000000000000 RSI: 00007ffdf1ce9890 RDI: 0000000000000003<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000078a940<br /> R10: 000000000000000c R11: 0000000000000246 R12: 0000000000000001<br /> R13: 0000000000688880 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common joydev pcspkr i2c_i801 virtio_balloon i2c_smbus lpc_ich ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel ahci libahci libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: sch_ets]<br /> ---[ end trace f35878d1912655c2 ]---<br /> RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47<br /> Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe<br /> RSP: 0018:ffffae46807a3888 EFLAGS: 00010246<br /> RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202<br /> RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff<br /> RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff<br /> R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800<br /> R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400<br /> FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix use-after-free bug in hclgevf_send_mbx_msg<br /> <br /> Currently, the hns3_remove function firstly uninstall client instance,<br /> and then uninstall acceletion engine device. The netdevice is freed in<br /> client instance uninstall process, but acceletion engine device uninstall<br /> process still use it to trace runtime information. This causes a use after<br /> free problem.<br /> <br /> So fixes it by check the instance register state to avoid use after free.