Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem<br /> <br /> When the mapping is already reaped the unmap must be a no-op, as we<br /> would otherwise try to remove the mapping twice, corrupting the involved<br /> data structures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock<br /> <br /> When user_dlm_destroy_lock failed, it didn&amp;#39;t clean up the flags it set<br /> before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of<br /> lock is still in used, next time when unlink invokes this function, it<br /> will return succeed, and then unlink will remove inode and dentry if lock<br /> is not in used(file closed), but the dlm lock is still linked in dlm lock<br /> resource, then when bast come in, it will trigger a panic due to<br /> user-after-free. See the following panic call trace. To fix this,<br /> USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should<br /> be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink<br /> fail.<br /> <br /> For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN,<br /> USER_LOCK_BUSY is also required to be cleared. Even though spin lock is<br /> released in between, but USER_LOCK_IN_TEARDOWN is still set, for<br /> USER_LOCK_BUSY, if before every place that waits on this flag,<br /> USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow<br /> waits on the busy flag set by user_dlm_destroy_lock(), then we can<br /> simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix<br /> user_dlm_cluster_lock() which is the only function not following this.<br /> <br /> [ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink<br /> 004fb0000060000b5a90b8c847b72e1, error -16 from destroy<br /> [ 989.757536] ------------[ cut here ]------------<br /> [ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173!<br /> [ 989.757876] invalid opcode: 0000 [#1] SMP<br /> [ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O)<br /> ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc<br /> xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5<br /> auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs<br /> ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc<br /> fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc<br /> rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad<br /> rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE)<br /> mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad<br /> ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support<br /> pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si<br /> ipmi_msghandler<br /> [ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp<br /> pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel<br /> be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio<br /> libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi<br /> dm_mirror dm_region_hash dm_log dm_mod [last unloaded:<br /> ksplice_2zhuk2jr_ib_ipoib_old]<br /> [ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE<br /> 4.1.12-124.57.1.el6uek.x86_64 #2<br /> [ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER<br /> X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021<br /> [ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti:<br /> ffff88017f7c8000<br /> [ 989.762848] RIP: e030:[] []<br /> __user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs]<br /> [ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246<br /> [ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX:<br /> 0000000000000003<br /> [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI:<br /> ffff880174d48170<br /> [ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09:<br /> 0000000000000000<br /> [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12:<br /> ffff880174d48008<br /> [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15:<br /> ffff88021db7a000<br /> [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000)<br /> knlGS:ffff880247480000<br /> [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4:<br /> 0000000000042660<br /> [ 989.765081] Stack:<br /> [ 989.765167] 00000000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip_gre: test csum_start instead of transport header<br /> <br /> GRE with TUNNEL_CSUM will apply local checksum offload on<br /> CHECKSUM_PARTIAL packets.<br /> <br /> ipgre_xmit must validate csum_start after an optional skb_pull,<br /> else lco_csum may trigger an overflow. The original check was<br /> <br /> if (csum &amp;&amp; skb_checksum_start(skb) data)<br /> return -EINVAL;<br /> <br /> This had false positives when skb_checksum_start is undefined:<br /> when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement<br /> was straightforward<br /> <br /> if (csum &amp;&amp; skb-&gt;ip_summed == CHECKSUM_PARTIAL &amp;&amp;<br /> skb_checksum_start(skb) data)<br /> return -EINVAL;<br /> <br /> But was eventually revised more thoroughly:<br /> - restrict the check to the only branch where needed, in an<br /> uncommon GRE path that uses header_ops and calls skb_pull.<br /> - test skb_transport_header, which is set along with csum_start<br /> in skb_partial_csum_set in the normal header_ops datapath.<br /> <br /> Turns out skbs can arrive in this branch without the transport<br /> header set, e.g., through BPF redirection.<br /> <br /> Revise the check back to check csum_start directly, and only if<br /> CHECKSUM_PARTIAL. Do leave the check in the updated location.<br /> Check field regardless of whether TUNNEL_CSUM is configured.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix sleeping function called from invalid context on RT kernel<br /> <br /> When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the<br /> cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the<br /> atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,<br /> these locks are replaced with sleepable rt-spinlock, so the stack calltrace will<br /> be triggered.<br /> Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start<br /> tp_printk=1" enabled.<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0<br /> preempt_count: 2, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> Preemption disabled at:<br /> [] try_to_wake_up+0x7e/0xba0<br /> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x60/0x8c<br /> dump_stack+0x10/0x12<br /> __might_resched.cold+0x11d/0x155<br /> rt_spin_lock+0x40/0x70<br /> trace_event_buffer_commit+0x2fa/0x4c0<br /> ? map_vsyscall+0x93/0x93<br /> trace_event_raw_event_initcall_start+0xbe/0x110<br /> ? perf_trace_initcall_finish+0x210/0x210<br /> ? probe_sched_wakeup+0x34/0x40<br /> ? ttwu_do_wakeup+0xda/0x310<br /> ? trace_hardirqs_on+0x35/0x170<br /> ? map_vsyscall+0x93/0x93<br /> do_one_initcall+0x217/0x3c0<br /> ? trace_event_raw_event_initcall_level+0x170/0x170<br /> ? push_cpu_stop+0x400/0x400<br /> ? cblist_init_generic+0x241/0x290<br /> kernel_init_freeable+0x1ac/0x347<br /> ? _raw_spin_unlock_irq+0x65/0x80<br /> ? rest_init+0xf0/0xf0<br /> kernel_init+0x1e/0x150<br /> ret_from_fork+0x22/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe()<br /> <br /> It will cause null-ptr-deref when using &amp;#39;res&amp;#39;, if platform_get_resource()<br /> returns NULL, so move using &amp;#39;res&amp;#39; after devm_ioremap_resource() that<br /> will check it to avoid null-ptr-deref.<br /> And use devm_platform_get_and_ioremap_resource() to simplify code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mips: cpc: Fix refcount leak in mips_cpc_default_phys_base<br /> <br /> Add the missing of_node_put() to release the refcount incremented<br /> by of_find_compatible_node().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtl818x: Prevent using not initialized queues<br /> <br /> Using not existing queues can panic the kernel with rtl8180/rtl8185 cards.<br /> Ignore the skb priority for those cards, they only have one tx queue. Pierre<br /> Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum:<br /> <br /> https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html<br /> <br /> He also confirmed that this patch fixes the issue. In summary this happened:<br /> <br /> After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a<br /> "divide error: 0000" when connecting to an AP. Control port tx now tries to<br /> use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in<br /> 2.10.<br /> <br /> Since only the rtl8187se part of the driver supports QoS, the priority<br /> of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185<br /> cards.<br /> <br /> rtl8180 is then unconditionally reading out the priority and finally crashes on<br /> drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this<br /> patch:<br /> idx = (ring-&gt;idx + skb_queue_len(&amp;ring-&gt;queue)) % ring-&gt;entries<br /> <br /> "ring-&gt;entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got<br /> initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: avoid journal no-space deadlock by reserving 1 journal bucket<br /> <br /> The journal no-space deadlock was reported time to time. Such deadlock<br /> can happen in the following situation.<br /> <br /> When all journal buckets are fully filled by active jset with heavy<br /> write I/O load, the cache set registration (after a reboot) will load<br /> all active jsets and inserting them into the btree again (which is<br /> called journal replay). If a journaled bkey is inserted into a btree<br /> node and results btree node split, new journal request might be<br /> triggered. For example, the btree grows one more level after the node<br /> split, then the root node record in cache device super block will be<br /> upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no<br /> space in journal buckets, the journal replay has to wait for new journal<br /> bucket to be reclaimed after at least one journal bucket replayed. This<br /> is one example that how the journal no-space deadlock happens.<br /> <br /> The solution to avoid the deadlock is to reserve 1 journal bucket in<br /> run time, and only permit the reserved journal bucket to be used during<br /> cache set registration procedure for things like journal replay. Then<br /> the journal space will never be fully filled, there is no chance for<br /> journal no-space deadlock to happen anymore.<br /> <br /> This patch adds a new member "bool do_reserve" in struct journal, it is<br /> inititalized to 0 (false) when struct journal is allocated, and set to<br /> 1 (true) by bch_journal_space_reserve() when all initialization done in<br /> run_cache_set(). In the run time when journal_reclaim() tries to<br /> allocate a new journal bucket, free_journal_buckets() is called to check<br /> whether there are enough free journal buckets to use. If there is only<br /> 1 free journal bucket and journal-&gt;do_reserve is 1 (true), the last<br /> bucket is reserved and free_journal_buckets() will return 0 to indicate<br /> no free journal bucket. Then journal_reclaim() will give up, and try<br /> next time to see whetheer there is free journal bucket to allocate. By<br /> this method, there is always 1 jouranl bucket reserved in run time.<br /> <br /> During the cache set registration, journal-&gt;do_reserve is 0 (false), so<br /> the reserved journal bucket can be used to avoid the no-space deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vduse: Fix NULL pointer dereference on sysfs access<br /> <br /> The control device has no drvdata. So we will get a<br /> NULL pointer dereference when accessing control<br /> device&amp;#39;s msg_timeout attribute via sysfs:<br /> <br /> [ 132.841881][ T3644] BUG: kernel NULL pointer dereference, address: 00000000000000f8<br /> [ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271)<br /> [ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094)<br /> [ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59)<br /> [ 132.871164][ T3644] ? device_remove_bin_file (drivers/base/core.c:2088)<br /> [ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164)<br /> [ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230)<br /> [ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041)<br /> [ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238)<br /> [ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminator 1))<br /> [ 132.876319][ T3644] kernel_read (fs/read_write.c:459)<br /> [ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94)<br /> [ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186)<br /> [ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207)<br /> [ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189)<br /> [ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132)<br /> [ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419)<br /> <br /> To fix it, don&amp;#39;t create the unneeded attribute for<br /> control device anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling<br /> <br /> Error paths do not free previously allocated memory. Add devm_kfree() to<br /> those failure paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Address NULL pointer dereference after starget_to_rport()<br /> <br /> Calls to starget_to_rport() may return NULL. Add check for NULL rport<br /> before dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: add accessors to read/set tp-&gt;snd_cwnd<br /> <br /> We had various bugs over the years with code<br /> breaking the assumption that tp-&gt;snd_cwnd is greater<br /> than zero.<br /> <br /> Lately, syzbot reported the WARN_ON_ONCE(!tp-&gt;prior_cwnd) added<br /> in commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")<br /> can trigger, and without a repro we would have to spend<br /> considerable time finding the bug.<br /> <br /> Instead of complaining too late, we want to catch where<br /> and when tp-&gt;snd_cwnd is set to an illegal value.