Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/smp: do not decrement idle task preempt count in CPU offline<br /> <br /> With PREEMPT_COUNT=y, when a CPU is offlined and then onlined again, we<br /> get:<br /> <br /> BUG: scheduling while atomic: swapper/1/0/0x00000000<br /> no locks held by swapper/1/0.<br /> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.15.0-rc2+ #100<br /> Call Trace:<br /> dump_stack_lvl+0xac/0x108<br /> __schedule_bug+0xac/0xe0<br /> __schedule+0xcf8/0x10d0<br /> schedule_idle+0x3c/0x70<br /> do_idle+0x2d8/0x4a0<br /> cpu_startup_entry+0x38/0x40<br /> start_secondary+0x2ec/0x3a0<br /> start_secondary_prolog+0x10/0x14<br /> <br /> This is because powerpc&amp;#39;s arch_cpu_idle_dead() decrements the idle task&amp;#39;s<br /> preempt count, for reasons explained in commit a7c2bb8279d2 ("powerpc:<br /> Re-enable preemption before cpu_die()"), specifically "start_secondary()<br /> expects a preempt_count() of 0."<br /> <br /> However, since commit 2c669ef6979c ("powerpc/preempt: Don&amp;#39;t touch the idle<br /> task&amp;#39;s preempt_count during hotplug") and commit f1a0a376ca0c ("sched/core:<br /> Initialize the idle task with preemption disabled"), that justification no<br /> longer holds.<br /> <br /> The idle task isn&amp;#39;t supposed to re-enable preemption, so remove the<br /> vestigial preempt_enable() from the CPU offline path.<br /> <br /> Tested with pseries and powernv in qemu, and pseries on PowerVM.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: peak_pci: peak_pci_remove(): fix UAF<br /> <br /> When remove the module peek_pci, referencing &amp;#39;chan&amp;#39; again after<br /> releasing &amp;#39;dev&amp;#39; will cause UAF.<br /> <br /> Fix this by releasing &amp;#39;dev&amp;#39; later.<br /> <br /> The following log reveals it:<br /> <br /> [ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci]<br /> [ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537<br /> [ 35.965513 ] Call Trace:<br /> [ 35.965718 ] dump_stack_lvl+0xa8/0xd1<br /> [ 35.966028 ] print_address_description+0x87/0x3b0<br /> [ 35.966420 ] kasan_report+0x172/0x1c0<br /> [ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci]<br /> [ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170<br /> [ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci]<br /> [ 35.967945 ] __asan_report_load8_noabort+0x14/0x20<br /> [ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci]<br /> [ 35.968752 ] pci_device_remove+0xa9/0x250

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: isotp: isotp_sendmsg(): add result check for wait_event_interruptible()<br /> <br /> Using wait_event_interruptible() to wait for complete transmission,<br /> but do not check the result of wait_event_interruptible() which can be<br /> interrupted. It will result in TX buffer has multiple accessors and<br /> the later process interferes with the previous process.<br /> <br /> Following is one of the problems reported by syzbot.<br /> <br /> =============================================================<br /> WARNING: CPU: 0 PID: 0 at net/can/isotp.c:840 isotp_tx_timer_handler+0x2e0/0x4c0<br /> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc7+ #68<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014<br /> RIP: 0010:isotp_tx_timer_handler+0x2e0/0x4c0<br /> Call Trace:<br /> <br /> ? isotp_setsockopt+0x390/0x390<br /> __hrtimer_run_queues+0xb8/0x610<br /> hrtimer_run_softirq+0x91/0xd0<br /> ? rcu_read_lock_sched_held+0x4d/0x80<br /> __do_softirq+0xe8/0x553<br /> irq_exit_rcu+0xf8/0x100<br /> sysvec_apic_timer_interrupt+0x9e/0xc0<br /> <br /> asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> <br /> Add result check for wait_event_interruptible() in isotp_sendmsg()<br /> to avoid multiple accessers for tx buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: mount fails with buffer overflow in strlen<br /> <br /> Starting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting an<br /> ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the<br /> trace below. Problem seems to be that strings for cluster stack and<br /> cluster name are not guaranteed to be null terminated in the disk<br /> representation, while strlcpy assumes that the source string is always<br /> null terminated. This causes a read outside of the source string<br /> triggering the buffer overflow detection.<br /> <br /> detected buffer overflow in strlen<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/string.c:1149!<br /> invalid opcode: 0000 [#1] SMP PTI<br /> CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1<br /> Debian 5.14.6-2<br /> RIP: 0010:fortify_panic+0xf/0x11<br /> ...<br /> Call Trace:<br /> ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2]<br /> ocfs2_fill_super+0x359/0x19b0 [ocfs2]<br /> mount_bdev+0x185/0x1b0<br /> legacy_get_tree+0x27/0x40<br /> vfs_get_tree+0x25/0xb0<br /> path_mount+0x454/0xa20<br /> __x64_sys_mount+0x103/0x140<br /> do_syscall_64+0x3b/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: j1939_netdev_start(): fix UAF for rx_kref of j1939_priv<br /> <br /> It will trigger UAF for rx_kref of j1939_priv as following.<br /> <br /> cpu0 cpu1<br /> j1939_sk_bind(socket0, ndev0, ...)<br /> j1939_netdev_start<br /> j1939_sk_bind(socket1, ndev0, ...)<br /> j1939_netdev_start<br /> j1939_priv_set<br /> j1939_priv_get_by_ndev_locked<br /> j1939_jsk_add<br /> .....<br /> j1939_netdev_stop<br /> kref_put_lock(&amp;priv-&gt;rx_kref, ...)<br /> kref_get(&amp;priv-&gt;rx_kref, ...)<br /> REFCOUNT_WARN("addition on 0;...")<br /> <br /> ====================================================<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0<br /> RIP: 0010:refcount_warn_saturate+0x169/0x1e0<br /> Call Trace:<br /> j1939_netdev_start+0x68b/0x920<br /> j1939_sk_bind+0x426/0xeb0<br /> ? security_socket_bind+0x83/0xb0<br /> <br /> The rx_kref&amp;#39;s kref_get() and kref_put() should use j1939_netdev_lock to<br /> protect.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix data corruption after conversion from inline format<br /> <br /> Commit 6dbf7bb55598 ("fs: Don&amp;#39;t invalidate page buffers in<br /> block_write_full_page()") uncovered a latent bug in ocfs2 conversion<br /> from inline inode format to a normal inode format.<br /> <br /> The code in ocfs2_convert_inline_data_to_extents() attempts to zero out<br /> the whole cluster allocated for file data by grabbing, zeroing, and<br /> dirtying all pages covering this cluster. However these pages are<br /> beyond i_size, thus writeback code generally ignores these dirty pages<br /> and no blocks were ever actually zeroed on the disk.<br /> <br /> This oversight was fixed by commit 693c241a5f6a ("ocfs2: No need to zero<br /> pages past i_size.") for standard ocfs2 write path, inline conversion<br /> path was apparently forgotten; the commit log also has a reasoning why<br /> the zeroing actually is not needed.<br /> <br /> After commit 6dbf7bb55598, things became worse as writeback code stopped<br /> invalidating buffers on pages beyond i_size and thus these pages end up<br /> with clean PageDirty bit but with buffers attached to these pages being<br /> still dirty. So when a file is converted from inline format, then<br /> writeback triggers, and then the file is grown so that these pages<br /> become valid, the invalid dirtiness state is preserved,<br /> mark_buffer_dirty() does nothing on these pages (buffers are already<br /> dirty) but page is never written back because it is clean. So data<br /> written to these pages is lost once pages are reclaimed.<br /> <br /> Simple reproducer for the problem is:<br /> <br /> xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \<br /> -c "pwrite 4000 2000" ocfs2_file<br /> <br /> After unmounting and mounting the fs again, you can observe that end of<br /> &amp;#39;ocfs2_file&amp;#39; has lost its contents.<br /> <br /> Fix the problem by not doing the pointless zeroing during conversion<br /> from inline format similarly as in the standard write path.<br /> <br /> [akpm@linux-foundation.org: fix whitespace, per Joseph]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: Fix possible memory leak in ptp_clock_register()<br /> <br /> I got memory leak as follows when doing fault injection test:<br /> <br /> unreferenced object 0xffff88800906c618 (size 8):<br /> comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s)<br /> hex dump (first 8 bytes):<br /> 70 74 70 30 00 00 00 00 ptp0....<br /> backtrace:<br /> [] __kmalloc_track_caller+0x19f/0x3a0<br /> [] kvasprintf+0xb5/0x150<br /> [] kvasprintf_const+0x60/0x190<br /> [] kobject_set_name_vargs+0x56/0x150<br /> [] dev_set_name+0xc0/0x100<br /> [] ptp_clock_register+0x9f4/0xd30 [ptp]<br /> [] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]<br /> <br /> When posix_clock_register() returns an error, the name allocated<br /> in dev_set_name() will be leaked, the put_device() should be used<br /> to give up the device reference, then the name will be freed in<br /> kobject_cleanup() and other memory will be freed in ptp_clock_release().

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.