Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path<br /> <br /> Prior to this patch in case mlx5_core_destroy_cq() failed it returns<br /> without completing all destroy operations and that leads to memory leak.<br /> Instead, complete the destroy flow before return error.<br /> <br /> Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq()<br /> to be symmetrical with mlx5_core_create_cq().<br /> <br /> kmemleak complains on:<br /> <br /> unreferenced object 0xc000000038625100 (size 64):<br /> comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s)<br /> hex dump (first 32 bytes):<br /> 60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4.....<br /> 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}.....<br /> backtrace:<br /> [] add_res_tree+0xd0/0x270 [mlx5_core]<br /> [] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core]<br /> [] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core]<br /> [] mlx5e_create_cq+0x210/0x3f0 [mlx5_core]<br /> [] mlx5e_open_cq+0xb4/0x130 [mlx5_core]<br /> [] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core]<br /> [] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core]<br /> [] mlx5e_switch_priv_channels+0xa4/0x230<br /> [mlx5_core]<br /> [] mlx5e_safe_switch_params+0x14c/0x300<br /> [mlx5_core]<br /> [] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core]<br /> [] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core]<br /> [] ethnl_set_privflags+0x234/0x2d0<br /> [] genl_family_rcv_msg_doit+0x108/0x1d0<br /> [] genl_family_rcv_msg+0xe4/0x1f0<br /> [] genl_rcv_msg+0x78/0x120<br /> [] netlink_rcv_skb+0x74/0x1a0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: microchip: Added the condition for scheduling ksz_mib_read_work<br /> <br /> When the ksz module is installed and removed using rmmod, kernel crashes<br /> with null pointer dereferrence error. During rmmod, ksz_switch_remove<br /> function tries to cancel the mib_read_workqueue using<br /> cancel_delayed_work_sync routine and unregister switch from dsa.<br /> <br /> During dsa_unregister_switch it calls ksz_mac_link_down, which in turn<br /> reschedules the workqueue since mib_interval is non-zero.<br /> Due to which queue executed after mib_interval and it tries to access<br /> dp-&gt;slave. But the slave is unregistered in the ksz_switch_remove<br /> function. Hence kernel crashes.<br /> <br /> To avoid this crash, before canceling the workqueue, resetted the<br /> mib_interval to 0.<br /> <br /> v1 -&gt; v2:<br /> -Removed the if condition in ksz_mib_read_work

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: encx24j600: check error in devm_regmap_init_encx24j600<br /> <br /> devm_regmap_init may return error which caused by like out of memory,<br /> this will results in null pointer dereference later when reading<br /> or writing register:<br /> <br /> general protection fault in encx24j600_spi_probe<br /> KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]<br /> CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540<br /> Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00<br /> RSP: 0018:ffffc900010476b8 EFLAGS: 00010207<br /> RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000<br /> RDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094<br /> RBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a<br /> R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001<br /> R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08<br /> FS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459<br /> spi_probe drivers/spi/spi.c:397<br /> really_probe drivers/base/dd.c:517<br /> __driver_probe_device drivers/base/dd.c:751<br /> driver_probe_device drivers/base/dd.c:782<br /> __device_attach_driver drivers/base/dd.c:899<br /> bus_for_each_drv drivers/base/bus.c:427<br /> __device_attach drivers/base/dd.c:971<br /> bus_probe_device drivers/base/bus.c:487<br /> device_add drivers/base/core.c:3364<br /> __spi_add_device drivers/spi/spi.c:599<br /> spi_add_device drivers/spi/spi.c:641<br /> spi_new_device drivers/spi/spi.c:717<br /> new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e]<br /> dev_attr_store drivers/base/core.c:2074<br /> sysfs_kf_write fs/sysfs/file.c:139<br /> kernfs_fop_write_iter fs/kernfs/file.c:300<br /> new_sync_write fs/read_write.c:508 (discriminator 4)<br /> vfs_write fs/read_write.c:594<br /> ksys_write fs/read_write.c:648<br /> do_syscall_64 arch/x86/entry/common.c:50<br /> entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113<br /> <br /> Add error check in devm_regmap_init_encx24j600 to avoid this situation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: thermal: Fix out-of-bounds memory accesses<br /> <br /> Currently, mlxsw allows cooling states to be set above the maximum<br /> cooling state supported by the driver:<br /> <br /> # cat /sys/class/thermal/thermal_zone2/cdev0/type<br /> mlxsw_fan<br /> # cat /sys/class/thermal/thermal_zone2/cdev0/max_state<br /> 10<br /> # echo 18 &gt; /sys/class/thermal/thermal_zone2/cdev0/cur_state<br /> # echo $?<br /> 0<br /> <br /> This results in out-of-bounds memory accesses when thermal state<br /> transition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as the<br /> transition table is accessed with a too large index (state) [1].<br /> <br /> According to the thermal maintainer, it is the responsibility of the<br /> driver to reject such operations [2].<br /> <br /> Therefore, return an error when the state to be set exceeds the maximum<br /> cooling state supported by the driver.<br /> <br /> To avoid dead code, as suggested by the thermal maintainer [3],<br /> partially revert commit a421ce088ac8 ("mlxsw: core: Extend cooling<br /> device with cooling levels") that tried to interpret these invalid<br /> cooling states (above the maximum) in a special way. The cooling levels<br /> array is not removed in order to prevent the fans going below 20% PWM,<br /> which would cause them to get stuck at 0% PWM.<br /> <br /> [1]<br /> BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290<br /> Read of size 4 at addr ffff8881052f7bf8 by task kworker/0:0/5<br /> <br /> CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122<br /> Hardware name: Mellanox Technologies Ltd. "MSN2410-CB2FO"/"SA000874", BIOS 4.6.5 03/08/2016<br /> Workqueue: events_freezable_power_ thermal_zone_device_check<br /> Call Trace:<br /> dump_stack_lvl+0x8b/0xb3<br /> print_address_description.constprop.0+0x1f/0x140<br /> kasan_report.cold+0x7f/0x11b<br /> thermal_cooling_device_stats_update+0x271/0x290<br /> __thermal_cdev_update+0x15e/0x4e0<br /> thermal_cdev_update+0x9f/0xe0<br /> step_wise_throttle+0x770/0xee0<br /> thermal_zone_device_update+0x3f6/0xdf0<br /> process_one_work+0xa42/0x1770<br /> worker_thread+0x62f/0x13e0<br /> kthread+0x3ee/0x4e0<br /> ret_from_fork+0x1f/0x30<br /> <br /> Allocated by task 1:<br /> kasan_save_stack+0x1b/0x40<br /> __kasan_kmalloc+0x7c/0x90<br /> thermal_cooling_device_setup_sysfs+0x153/0x2c0<br /> __thermal_cooling_device_register.part.0+0x25b/0x9c0<br /> thermal_cooling_device_register+0xb3/0x100<br /> mlxsw_thermal_init+0x5c5/0x7e0<br /> __mlxsw_core_bus_device_register+0xcb3/0x19c0<br /> mlxsw_core_bus_device_register+0x56/0xb0<br /> mlxsw_pci_probe+0x54f/0x710<br /> local_pci_probe+0xc6/0x170<br /> pci_device_probe+0x2b2/0x4d0<br /> really_probe+0x293/0xd10<br /> __driver_probe_device+0x2af/0x440<br /> driver_probe_device+0x51/0x1e0<br /> __driver_attach+0x21b/0x530<br /> bus_for_each_dev+0x14c/0x1d0<br /> bus_add_driver+0x3ac/0x650<br /> driver_register+0x241/0x3d0<br /> mlxsw_sp_module_init+0xa2/0x174<br /> do_one_initcall+0xee/0x5f0<br /> kernel_init_freeable+0x45a/0x4de<br /> kernel_init+0x1f/0x210<br /> ret_from_fork+0x1f/0x30<br /> <br /> The buggy address belongs to the object at ffff8881052f7800<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 1016 bytes inside of<br /> 1024-byte region [ffff8881052f7800, ffff8881052f7c00)<br /> The buggy address belongs to the page:<br /> page:0000000052355272 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1052f0<br /> head:0000000052355272 order:3 compound_mapcount:0 compound_pincount:0<br /> flags: 0x200000000010200(slab|head|node=0|zone=2)<br /> raw: 0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0<br /> raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc<br /> ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> &gt;ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ^<br /> ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> <br /> [2] https://lore.kernel.org/linux-pm/9aca37cb-1629-5c67-<br /> ---truncated---

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.