Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: skip netdev events generated on netns removal<br /> <br /> syzbot reported following (harmless) WARN:<br /> <br /> WARNING: CPU: 1 PID: 2648 at net/netfilter/core.c:468<br /> nft_netdev_unregister_hooks net/netfilter/nf_tables_api.c:230 [inline]<br /> nf_tables_unregister_hook include/net/netfilter/nf_tables.h:1090 [inline]<br /> __nft_release_basechain+0x138/0x640 net/netfilter/nf_tables_api.c:9524<br /> nft_netdev_event net/netfilter/nft_chain_filter.c:351 [inline]<br /> nf_tables_netdev_event+0x521/0x8a0 net/netfilter/nft_chain_filter.c:382<br /> <br /> reproducer:<br /> unshare -n bash -c &amp;#39;ip link add br0 type bridge; nft add table netdev t ; \<br /> nft add chain netdev t ingress \{ type filter hook ingress device "br0" \<br /> priority 0\; policy drop\; \}&amp;#39;<br /> <br /> Problem is that when netns device exit hooks create the UNREGISTER<br /> event, the .pre_exit hook for nf_tables core has already removed the<br /> base hook. Notifier attempts to do this again.<br /> <br /> The need to do base hook unregister unconditionally was needed in the past,<br /> because notifier was last stage where reg-&gt;dev dereference was safe.<br /> <br /> Now that nf_tables does the hook removal in .pre_exit, this isn&amp;#39;t<br /> needed anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Avoid crash from unnecessary IDA free<br /> <br /> In the remove path, there is an attempt to free the aux_idx IDA whether<br /> it was allocated or not. This can potentially cause a crash when<br /> unloading the driver on systems that do not initialize support for RDMA.<br /> But, this free cannot be gated by the status bit for RDMA, since it is<br /> allocated if the driver detects support for RDMA at probe time, but the<br /> driver can enter into a state where RDMA is not supported after the IDA<br /> has been allocated at probe time and this would lead to a memory leak.<br /> <br /> Initialize aux_idx to an invalid value and check for a valid value when<br /> unloading to determine if an IDA free is necessary.

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.