Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: mxsfb: Fix NULL pointer dereference crash on unload<br /> <br /> The mxsfb-&gt;crtc.funcs may already be NULL when unloading the driver,<br /> in which case calling mxsfb_irq_disable() via drm_irq_uninstall() from<br /> mxsfb_unload() leads to NULL pointer dereference.<br /> <br /> Since all we care about is masking the IRQ and mxsfb-&gt;base is still<br /> valid, just use that to clear and mask the IRQ.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix locking for Tx timestamp tracking flush<br /> <br /> Commit 4dd0d5c33c3e ("ice: add lock around Tx timestamp tracker flush")<br /> added a lock around the Tx timestamp tracker flow which is used to<br /> cleanup any left over SKBs and prepare for device removal.<br /> <br /> This lock is problematic because it is being held around a call to<br /> ice_clear_phy_tstamp. The clear function takes a mutex to send a PHY<br /> write command to firmware. This could lead to a deadlock if the mutex<br /> actually sleeps, and causes the following warning on a kernel with<br /> preemption debugging enabled:<br /> <br /> [ 715.419426] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:573<br /> [ 715.427900] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 3100, name: rmmod<br /> [ 715.435652] INFO: lockdep is turned off.<br /> [ 715.439591] Preemption disabled at:<br /> [ 715.439594] [] 0x0<br /> [ 715.446678] CPU: 52 PID: 3100 Comm: rmmod Tainted: G W OE 5.15.0-rc4+ #42 bdd7ec3018e725f159ca0d372ce8c2c0e784891c<br /> [ 715.458058] Hardware name: Intel Corporation S2600STQ/S2600STQ, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020<br /> [ 715.468483] Call Trace:<br /> [ 715.470940] dump_stack_lvl+0x6a/0x9a<br /> [ 715.474613] ___might_sleep.cold+0x224/0x26a<br /> [ 715.478895] __mutex_lock+0xb3/0x1440<br /> [ 715.482569] ? stack_depot_save+0x378/0x500<br /> [ 715.486763] ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.494979] ? kfree+0xc1/0x520<br /> [ 715.498128] ? mutex_lock_io_nested+0x12a0/0x12a0<br /> [ 715.502837] ? kasan_set_free_info+0x20/0x30<br /> [ 715.507110] ? __kasan_slab_free+0x10b/0x140<br /> [ 715.511385] ? slab_free_freelist_hook+0xc7/0x220<br /> [ 715.516092] ? kfree+0xc1/0x520<br /> [ 715.519235] ? ice_deinit_lag+0x16c/0x220 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.527359] ? ice_remove+0x1cf/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.535133] ? pci_device_remove+0xab/0x1d0<br /> [ 715.539318] ? __device_release_driver+0x35b/0x690<br /> [ 715.544110] ? driver_detach+0x214/0x2f0<br /> [ 715.548035] ? bus_remove_driver+0x11d/0x2f0<br /> [ 715.552309] ? pci_unregister_driver+0x26/0x250<br /> [ 715.556840] ? ice_module_exit+0xc/0x2f [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.564799] ? __do_sys_delete_module.constprop.0+0x2d8/0x4e0<br /> [ 715.570554] ? do_syscall_64+0x3b/0x90<br /> [ 715.574303] ? entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 715.579529] ? start_flush_work+0x542/0x8f0<br /> [ 715.583719] ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.591923] ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.599960] ? wait_for_completion_io+0x250/0x250<br /> [ 715.604662] ? lock_acquire+0x196/0x200<br /> [ 715.608504] ? do_raw_spin_trylock+0xa5/0x160<br /> [ 715.612864] ice_sbq_rw_reg+0x1e6/0x2f0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.620813] ? ice_reset+0x130/0x130 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.628497] ? __debug_check_no_obj_freed+0x1e8/0x3c0<br /> [ 715.633550] ? trace_hardirqs_on+0x1c/0x130<br /> [ 715.637748] ice_write_phy_reg_e810+0x70/0xf0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.646220] ? do_raw_spin_trylock+0xa5/0x160<br /> [ 715.650581] ? ice_ptp_release+0x910/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.658797] ? ice_ptp_release+0x255/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.667013] ice_clear_phy_tstamp+0x2c/0x110 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.675403] ice_ptp_release+0x408/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.683440] ice_remove+0x560/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]<br /> [ 715.691037] ? _raw_spin_unlock_irqrestore+0x46/0x73<br /> [ 715.696005] pci_device_remove+0xab/0x1d0<br /> [ 715.700018] __device_release_driver+0x35b/0x690<br /> [ 715.704637] driver_detach+0x214/0x2f0<br /> [ 715.708389] bus_remove_driver+0x11d/0x2f0<br /> [ 715.712489] pci_unregister_driver+0x26/0x250<br /> [ 71<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Fix host stage-2 PGD refcount<br /> <br /> The KVM page-table library refcounts the pages of concatenated stage-2<br /> PGDs individually. However, when running KVM in protected mode, the<br /> host&amp;#39;s stage-2 PGD is currently managed by EL2 as a single high-order<br /> compound page, which can cause the refcount of the tail pages to reach 0<br /> when they shouldn&amp;#39;t, hence corrupting the page-table.<br /> <br /> Fix this by introducing a new hyp_split_page() helper in the EL2 page<br /> allocator (matching the kernel&amp;#39;s split_page() function), and make use of<br /> it from host_s2_zalloc_pages_exact().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xt_IDLETIMER: fix panic that occurs when timer_type has garbage value<br /> <br /> Currently, when the rule related to IDLETIMER is added, idletimer_tg timer<br /> structure is initialized by kmalloc on executing idletimer_tg_create<br /> function. However, in this process timer-&gt;timer_type is not defined to<br /> a specific value. Thus, timer-&gt;timer_type has garbage value and it occurs<br /> kernel panic. So, this commit fixes the panic by initializing<br /> timer-&gt;timer_type using kzalloc instead of kmalloc.<br /> <br /> Test commands:<br /> # iptables -A OUTPUT -j IDLETIMER --timeout 1 --label test<br /> $ cat /sys/class/xt_idletimer/timers/test<br /> Killed<br /> <br /> Splat looks like:<br /> BUG: KASAN: user-memory-access in alarm_expires_remaining+0x49/0x70<br /> Read of size 8 at addr 0000002e8c7bc4c8 by task cat/917<br /> CPU: 12 PID: 917 Comm: cat Not tainted 5.14.0+ #3 79940a339f71eb14fc81aee1757a20d5bf13eb0e<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> Call Trace:<br /> dump_stack_lvl+0x6e/0x9c<br /> kasan_report.cold+0x112/0x117<br /> ? alarm_expires_remaining+0x49/0x70<br /> __asan_load8+0x86/0xb0<br /> alarm_expires_remaining+0x49/0x70<br /> idletimer_tg_show+0xe5/0x19b [xt_IDLETIMER 11219304af9316a21bee5ba9d58f76a6b9bccc6d]<br /> dev_attr_show+0x3c/0x60<br /> sysfs_kf_seq_show+0x11d/0x1f0<br /> ? device_remove_bin_file+0x20/0x20<br /> kernfs_seq_show+0xa4/0xb0<br /> seq_read_iter+0x29c/0x750<br /> kernfs_fop_read_iter+0x25a/0x2c0<br /> ? __fsnotify_parent+0x3d1/0x570<br /> ? iov_iter_init+0x70/0x90<br /> new_sync_read+0x2a7/0x3d0<br /> ? __x64_sys_llseek+0x230/0x230<br /> ? rw_verify_area+0x81/0x150<br /> vfs_read+0x17b/0x240<br /> ksys_read+0xd9/0x180<br /> ? vfs_write+0x460/0x460<br /> ? do_syscall_64+0x16/0xc0<br /> ? lockdep_hardirqs_on+0x79/0x120<br /> __x64_sys_read+0x43/0x50<br /> do_syscall_64+0x3b/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f0cdc819142<br /> Code: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24<br /> RSP: 002b:00007fff28eee5b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f0cdc819142<br /> RDX: 0000000000020000 RSI: 00007f0cdc032000 RDI: 0000000000000003<br /> RBP: 00007f0cdc032000 R08: 00007f0cdc031010 R09: 0000000000000000<br /> R10: 0000000000000022 R11: 0000000000000246 R12: 00005607e9ee31f0<br /> R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000

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.