Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: digital: fix possible memory leak in digital_in_send_sdd_req()<br /> <br /> &amp;#39;skb&amp;#39; is allocated in digital_in_send_sdd_req(), but not free when<br /> digital_in_send_cmd() failed, which will cause memory leak. Fix it<br /> by freeing &amp;#39;skb&amp;#39; if digital_in_send_cmd() return failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: digital: fix possible memory leak in digital_tg_listen_mdaa()<br /> <br /> &amp;#39;params&amp;#39; is allocated in digital_tg_listen_mdaa(), but not free when<br /> digital_send_cmd() failed, which will cause memory leak. Fix it by<br /> freeing &amp;#39;params&amp;#39; if digital_send_cmd() return failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read<br /> <br /> In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid<br /> corruption test") the function connector_bad_edid() started assuming<br /> that the memory for the EDID passed to it was big enough to hold<br /> `edid[0x7e] + 1` blocks of data (1 extra for the base block). It<br /> completely ignored the fact that the function was passed `num_blocks`<br /> which indicated how much memory had been allocated for the EDID.<br /> <br /> Let&amp;#39;s fix this by adding a bounds check.<br /> <br /> This is important for handling the case where there&amp;#39;s an error in the<br /> first block of the EDID. In that case we will call<br /> connector_bad_edid() without having re-allocated memory based on<br /> `edid[0x7e]`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix null pointer dereference on pointer edp<br /> <br /> The initialization of pointer dev dereferences pointer edp before<br /> edp is null checked, so there is a potential null pointer deference<br /> issue. Fix this by only dereferencing edp after edp has been null<br /> checked.<br /> <br /> Addresses-Coverity: ("Dereference before null check")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/a4xx: fix error handling in a4xx_gpu_init()<br /> <br /> This code returns 1 on error instead of a negative error. It leads to<br /> an Oops in the caller. A second problem is that the check for<br /> "if (ret != -ENODATA)" cannot be true because "ret" is set to 1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/a3xx: fix error handling in a3xx_gpu_init()<br /> <br /> These error paths returned 1 on failure, instead of a negative error<br /> code. This would lead to an Oops in the caller. A second problem is<br /> that the check for "if (ret != -ENODATA)" did not work because "ret" was<br /> set to 1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix possible stall on recvmsg()<br /> <br /> recvmsg() can enter an infinite loop if the caller provides the<br /> MSG_WAITALL, the data present in the receive queue is not sufficient to<br /> fulfill the request, and no more data is received by the peer.<br /> <br /> When the above happens, mptcp_wait_data() will always return with<br /> no wait, as the MPTCP_DATA_READY flag checked by such function is<br /> set and never cleared in such code path.<br /> <br /> Leveraging the above syzbot was able to trigger an RCU stall:<br /> <br /> rcu: INFO: rcu_preempt self-detected stall on CPU<br /> rcu: 0-...!: (10499 ticks this GP) idle=0af/1/0x4000000000000000 softirq=10678/10678 fqs=1<br /> (t=10500 jiffies g=13089 q=109)<br /> rcu: rcu_preempt kthread starved for 10497 jiffies! g13089 f0x0 RCU_GP_WAIT_FQS(5) -&gt;state=0x0 -&gt;cpu=1<br /> rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.<br /> rcu: RCU grace-period kthread stack dump:<br /> task:rcu_preempt state:R running task stack:28696 pid: 14 ppid: 2 flags:0x00004000<br /> Call Trace:<br /> context_switch kernel/sched/core.c:4955 [inline]<br /> __schedule+0x940/0x26f0 kernel/sched/core.c:6236<br /> schedule+0xd3/0x270 kernel/sched/core.c:6315<br /> schedule_timeout+0x14a/0x2a0 kernel/time/timer.c:1881<br /> rcu_gp_fqs_loop+0x186/0x810 kernel/rcu/tree.c:1955<br /> rcu_gp_kthread+0x1de/0x320 kernel/rcu/tree.c:2128<br /> kthread+0x405/0x4f0 kernel/kthread.c:327<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295<br /> rcu: Stack dump where RCU GP kthread last ran:<br /> Sending NMI from CPU 0 to CPUs 1:<br /> NMI backtrace for cpu 1<br /> CPU: 1 PID: 8510 Comm: syz-executor827 Not tainted 5.15.0-rc2-next-20210920-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:84 [inline]<br /> RIP: 0010:memory_is_nonzero mm/kasan/generic.c:102 [inline]<br /> RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:128 [inline]<br /> RIP: 0010:memory_is_poisoned mm/kasan/generic.c:159 [inline]<br /> RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline]<br /> RIP: 0010:kasan_check_range+0xc8/0x180 mm/kasan/generic.c:189<br /> Code: 38 00 74 ed 48 8d 50 08 eb 09 48 83 c0 01 48 39 d0 74 7a 80 38 00 74 f2 48 89 c2 b8 01 00 00 00 48 85 d2 75 56 5b 5d 41 5c c3 85 d2 74 5e 48 01 ea eb 09 48 83 c0 01 48 39 d0 74 50 80 38 00<br /> RSP: 0018:ffffc9000cd676c8 EFLAGS: 00000283<br /> RAX: ffffed100e9a110e RBX: ffffed100e9a110f RCX: ffffffff88ea062a<br /> RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888074d08870<br /> RBP: ffffed100e9a110e R08: 0000000000000001 R09: ffff888074d08877<br /> R10: ffffed100e9a110e R11: 0000000000000000 R12: ffff888074d08000<br /> R13: ffff888074d08000 R14: ffff888074d08088 R15: ffff888074d08000<br /> FS: 0000555556d8e300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000<br /> S: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000180 CR3: 0000000068909000 CR4: 00000000001506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> instrument_atomic_read_write include/linux/instrumented.h:101 [inline]<br /> test_and_clear_bit include/asm-generic/bitops/instrumented-atomic.h:83 [inline]<br /> mptcp_release_cb+0x14a/0x210 net/mptcp/protocol.c:3016<br /> release_sock+0xb4/0x1b0 net/core/sock.c:3204<br /> mptcp_wait_data net/mptcp/protocol.c:1770 [inline]<br /> mptcp_recvmsg+0xfd1/0x27b0 net/mptcp/protocol.c:2080<br /> inet6_recvmsg+0x11b/0x5e0 net/ipv6/af_inet6.c:659<br /> sock_recvmsg_nosec net/socket.c:944 [inline]<br /> ____sys_recvmsg+0x527/0x600 net/socket.c:2626<br /> ___sys_recvmsg+0x127/0x200 net/socket.c:2670<br /> do_recvmmsg+0x24d/0x6d0 net/socket.c:2764<br /> __sys_recvmmsg net/socket.c:2843 [inline]<br /> __do_sys_recvmmsg net/socket.c:2866 [inline]<br /> __se_sys_recvmmsg net/socket.c:2859 [inline]<br /> __x64_sys_recvmmsg+0x20b/0x260 net/socket.c:2859<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7fc200d2<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix abort logic in btrfs_replace_file_extents<br /> <br /> Error injection testing uncovered a case where we&amp;#39;d end up with a<br /> corrupt file system with a missing extent in the middle of a file. This<br /> occurs because the if statement to decide if we should abort is wrong.<br /> <br /> The only way we would abort in this case is if we got a ret !=<br /> -EOPNOTSUPP and we called from the file clone code. However the<br /> prealloc code uses this path too. Instead we need to abort if there is<br /> an error, and the only error we _don&amp;#39;t_ abort on is -EOPNOTSUPP and only<br /> if we came from the clone file code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: Fix command ring pointer corruption while aborting a command<br /> <br /> The command ring pointer is located at [6:63] bits of the command<br /> ring control register (CRCR). All the control bits like command stop,<br /> abort are located at [0:3] bits. While aborting a command, we read the<br /> CRCR and set the abort bit and write to the CRCR. The read will always<br /> give command ring pointer as all zeros. So we essentially write only<br /> the control bits. Since we split the 64 bit write into two 32 bit writes,<br /> there is a possibility of xHC command ring stopped before the upper<br /> dword (all zeros) is written. If that happens, xHC updates the upper<br /> dword of its internal command ring pointer with all zeros. Next time,<br /> when the command ring is restarted, we see xHC memory access failures.<br /> Fix this issue by only writing to the lower dword of CRCR where all<br /> control bits are located.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: fix mempool NULL pointer race when completing IO<br /> <br /> dm_io_dec_pending() calls end_io_acct() first and will then dec md<br /> in-flight pending count. But if a task is swapping DM table at same<br /> time this can result in a crash due to mempool-&gt;elements being NULL:<br /> <br /> task1 task2<br /> do_resume<br /> -&gt;do_suspend<br /> -&gt;dm_wait_for_completion<br /> bio_endio<br /> -&gt;clone_endio<br /> -&gt;dm_io_dec_pending<br /> -&gt;end_io_acct<br /> -&gt;wakeup task1<br /> -&gt;dm_swap_table<br /> -&gt;__bind<br /> -&gt;__bind_mempools<br /> -&gt;bioset_exit<br /> -&gt;mempool_exit<br /> -&gt;free_io<br /> <br /> [ 67.330330] Unable to handle kernel NULL pointer dereference at<br /> virtual address 0000000000000000<br /> ......<br /> [ 67.330494] pstate: 80400085 (Nzcv daIf +PAN -UAO)<br /> [ 67.330510] pc : mempool_free+0x70/0xa0<br /> [ 67.330515] lr : mempool_free+0x4c/0xa0<br /> [ 67.330520] sp : ffffff8008013b20<br /> [ 67.330524] x29: ffffff8008013b20 x28: 0000000000000004<br /> [ 67.330530] x27: ffffffa8c2ff40a0 x26: 00000000ffff1cc8<br /> [ 67.330535] x25: 0000000000000000 x24: ffffffdada34c800<br /> [ 67.330541] x23: 0000000000000000 x22: ffffffdada34c800<br /> [ 67.330547] x21: 00000000ffff1cc8 x20: ffffffd9a1304d80<br /> [ 67.330552] x19: ffffffdada34c970 x18: 000000b312625d9c<br /> [ 67.330558] x17: 00000000002dcfbf x16: 00000000000006dd<br /> [ 67.330563] x15: 000000000093b41e x14: 0000000000000010<br /> [ 67.330569] x13: 0000000000007f7a x12: 0000000034155555<br /> [ 67.330574] x11: 0000000000000001 x10: 0000000000000001<br /> [ 67.330579] x9 : 0000000000000000 x8 : 0000000000000000<br /> [ 67.330585] x7 : 0000000000000000 x6 : ffffff80148b5c1a<br /> [ 67.330590] x5 : ffffff8008013ae0 x4 : 0000000000000001<br /> [ 67.330596] x3 : ffffff80080139c8 x2 : ffffff801083bab8<br /> [ 67.330601] x1 : 0000000000000000 x0 : ffffffdada34c970<br /> [ 67.330609] Call trace:<br /> [ 67.330616] mempool_free+0x70/0xa0<br /> [ 67.330627] bio_put+0xf8/0x110<br /> [ 67.330638] dec_pending+0x13c/0x230<br /> [ 67.330644] clone_endio+0x90/0x180<br /> [ 67.330649] bio_endio+0x198/0x1b8<br /> [ 67.330655] dec_pending+0x190/0x230<br /> [ 67.330660] clone_endio+0x90/0x180<br /> [ 67.330665] bio_endio+0x198/0x1b8<br /> [ 67.330673] blk_update_request+0x214/0x428<br /> [ 67.330683] scsi_end_request+0x2c/0x300<br /> [ 67.330688] scsi_io_completion+0xa0/0x710<br /> [ 67.330695] scsi_finish_command+0xd8/0x110<br /> [ 67.330700] scsi_softirq_done+0x114/0x148<br /> [ 67.330708] blk_done_softirq+0x74/0xd0<br /> [ 67.330716] __do_softirq+0x18c/0x374<br /> [ 67.330724] irq_exit+0xb4/0xb8<br /> [ 67.330732] __handle_domain_irq+0x84/0xc0<br /> [ 67.330737] gic_handle_irq+0x148/0x1b0<br /> [ 67.330744] el1_irq+0xe8/0x190<br /> [ 67.330753] lpm_cpuidle_enter+0x4f8/0x538<br /> [ 67.330759] cpuidle_enter_state+0x1fc/0x398<br /> [ 67.330764] cpuidle_enter+0x18/0x20<br /> [ 67.330772] do_idle+0x1b4/0x290<br /> [ 67.330778] cpu_startup_entry+0x20/0x28<br /> [ 67.330786] secondary_start_kernel+0x160/0x170<br /> <br /> Fix this by:<br /> 1) Establishing pointers to &amp;#39;struct dm_io&amp;#39; members in<br /> dm_io_dec_pending() so that they may be passed into end_io_acct()<br /> _after_ free_io() is called.<br /> 2) Moving end_io_acct() after free_io().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: musb: dsps: Fix the probe error path<br /> <br /> Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after<br /> initializing musb") has inverted the calls to<br /> dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without<br /> updating correctly the error path. dsps_create_musb_pdev() allocates and<br /> registers a new platform device which must be unregistered and freed<br /> with platform_device_unregister(), and this is missing upon<br /> dsps_setup_optional_vbus_irq() error.<br /> <br /> While on the master branch it seems not to trigger any issue, I observed<br /> a kernel crash because of a NULL pointer dereference with a v5.10.70<br /> stable kernel where the patch mentioned above was backported. With this<br /> kernel version, -EPROBE_DEFER is returned the first time<br /> dsps_setup_optional_vbus_irq() is called which triggers the probe to<br /> error out without unregistering the platform device. Unfortunately, on<br /> the Beagle Bone Black Wireless, the platform device still living in the<br /> system is being used by the USB Ethernet gadget driver, which during the<br /> boot phase triggers the crash.<br /> <br /> My limited knowledge of the musb world prevents me to revert this commit<br /> which was sent to silence a robot warning which, as far as I understand,<br /> does not make sense. The goal of this patch was to prevent an IRQ to<br /> fire before the platform device being registered. I think this cannot<br /> ever happen due to the fact that enabling the interrupts is done by the<br /> -&gt;enable() callback of the platform musb device, and this platform<br /> device must be already registered in order for the core or any other<br /> user to use this callback.<br /> <br /> Hence, I decided to fix the error path, which might prevent future<br /> errors on mainline kernels while also fixing older ones.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adis16475: fix deadlock on frequency set<br /> <br /> With commit 39c024b51b560<br /> ("iio: adis16475: improve sync scale mode handling"), two deadlocks were<br /> introduced:<br /> 1) The call to &amp;#39;adis_write_reg_16()&amp;#39; was not changed to it&amp;#39;s unlocked<br /> version.<br /> 2) The lock was not being released on the success path of the function.<br /> <br /> This change fixes both these issues.