Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Prevent some integer underflows<br /> <br /> My static checker complains that:<br /> <br /> drivers/infiniband/hw/irdma/ctrl.c:3605 irdma_sc_ceq_init()<br /> warn: can subtract underflow &amp;#39;info-&gt;dev-&gt;hmc_fpm_misc.max_ceqs&amp;#39;?<br /> <br /> It appears that "info-&gt;dev-&gt;hmc_fpm_misc.max_ceqs" comes from the firmware<br /> in irdma_sc_parse_fpm_query_buf() so, yes, there is a chance that it could<br /> be zero. Even if we trust the firmware, it&amp;#39;s easy enough to change the<br /> condition just as a hardenning measure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: fix race between xmit and reset<br /> <br /> There is a race between reset and the transmit paths that can lead to<br /> ibmvnic_xmit() accessing an scrq after it has been freed in the reset<br /> path. It can result in a crash like:<br /> <br /> Kernel attempted to read user page (0) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000000<br /> Faulting instruction address: 0xc0080000016189f8<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> ...<br /> NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic]<br /> LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280<br /> Call Trace:<br /> [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable)<br /> [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280<br /> [c000000000c9cfcc] sch_direct_xmit+0xec/0x330<br /> [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0<br /> [c000000000c00ad4] __dev_queue_xmit+0x394/0x730<br /> [c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding]<br /> [c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding]<br /> [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280<br /> [c000000000c00ca4] __dev_queue_xmit+0x564/0x730<br /> [c000000000cf97e0] neigh_hh_output+0xd0/0x180<br /> [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0<br /> [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0<br /> [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0<br /> [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0<br /> [c000000000d2d984] tcp_retransmit_skb+0x34/0x130<br /> [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0<br /> [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330<br /> [c000000000d317bc] tcp_write_timer+0x5c/0x200<br /> [c000000000243270] call_timer_fn+0x50/0x1c0<br /> [c000000000243704] __run_timers.part.0+0x324/0x460<br /> [c000000000243894] run_timer_softirq+0x54/0xa0<br /> [c000000000ea713c] __do_softirq+0x15c/0x3e0<br /> [c000000000166258] __irq_exit_rcu+0x158/0x190<br /> [c000000000166420] irq_exit+0x20/0x40<br /> [c00000000002853c] timer_interrupt+0x14c/0x2b0<br /> [c000000000009a00] decrementer_common_virt+0x210/0x220<br /> --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c<br /> <br /> The immediate cause of the crash is the access of tx_scrq in the following<br /> snippet during a reset, where the tx_scrq can be either NULL or an address<br /> that will soon be invalid:<br /> <br /> ibmvnic_xmit()<br /> {<br /> ...<br /> tx_scrq = adapter-&gt;tx_scrq[queue_num];<br /> txq = netdev_get_tx_queue(netdev, queue_num);<br /> ind_bufp = &amp;tx_scrq-&gt;ind_buf;<br /> <br /> if (test_bit(0, &amp;adapter-&gt;resetting)) {<br /> ...<br /> }<br /> <br /> But beyond that, the call to ibmvnic_xmit() itself is not safe during a<br /> reset and the reset path attempts to avoid this by stopping the queue in<br /> ibmvnic_cleanup(). However just after the queue was stopped, an in-flight<br /> ibmvnic_complete_tx() could have restarted the queue even as the reset is<br /> progressing.<br /> <br /> Since the queue was restarted we could get a call to ibmvnic_xmit() which<br /> can then access the bad tx_scrq (or other fields).<br /> <br /> We cannot however simply have ibmvnic_complete_tx() check the -&gt;resetting<br /> bit and skip starting the queue. This can race at the "back-end" of a good<br /> reset which just restarted the queue but has not cleared the -&gt;resetting<br /> bit yet. If we skip restarting the queue due to -&gt;resetting being true,<br /> the queue would remain stopped indefinitely potentially leading to transmit<br /> timeouts.<br /> <br /> IOW -&gt;resetting is too broad for this purpose. Instead use a new flag<br /> that indicates whether or not the queues are active. Only the open/<br /> reset paths control when the queues are active. ibmvnic_complete_tx()<br /> and others wake up the queue only if the queue is marked active.<br /> <br /> So we will have:<br /> A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()<br /> <br /> -&gt;resetting = true<br /> -&gt;tx_queues_active = false<br /> disable tx queues<br /> ...<br /> -&gt;tx_queues_active = true<br /> start tx queues<br /> <br /> B. Tx interrupt in ibmvnic_complete_tx():<br /> <br /> if (-&gt;tx_queues_active)<br /> netif_wake_subqueue();<br /> <br /> To ensure that -&gt;tx_queues_active and state of the queues are consistent,<br /> we need a lock which:<br /> <br /> - must also be taken in the interrupt path (ibmvnic_complete_tx())<br /> - shared across the multiple<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix double free during GPU reset on DC streams<br /> <br /> [Why]<br /> The issue only occurs during the GPU reset code path.<br /> <br /> We first backup the current state prior to commiting 0 streams<br /> internally from DM to DC. This state backup contains valid link<br /> encoder assignments.<br /> <br /> DC will clear the link encoder assignments as part of current state<br /> (but not the backup, since it was a copied before the commit) and<br /> free the extra stream reference it held.<br /> <br /> DC requires that the link encoder assignments remain cleared/invalid<br /> prior to commiting. Since the backup still has valid assignments we<br /> call the interface post reset to clear them. This routine also<br /> releases the extra reference that the link encoder interface held -<br /> resulting in a double free (and eventually a NULL pointer dereference).<br /> <br /> [How]<br /> We&amp;#39;ll have to do a full DC commit anyway after GPU reset because<br /> the stream count previously went to 0.<br /> <br /> We don&amp;#39;t need to retain the assignment that we had backed up, so<br /> just copy off of the now clean current state assignment after the<br /> reset has occcurred with the new link_enc_cfg_copy() interface.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernel/resource: fix kfree() of bootmem memory again<br /> <br /> Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem<br /> memory"), we could get a resource allocated during boot via<br /> alloc_resource(). And it&amp;#39;s required to release the resource using<br /> free_resource(). Howerver, many people use kfree directly which will<br /> result in kernel BUG. In order to fix this without fixing every call<br /> site, just leak a couple of bytes in such corner case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mxser: fix xmit_buf leak in activate when LSR == 0xff<br /> <br /> When LSR is 0xff in -&gt;activate() (rather unlike), we return an error.<br /> Provided -&gt;shutdown() is not called when -&gt;activate() fails, nothing<br /> actually frees the buffer in this case.<br /> <br /> Fix this by properly freeing the buffer in a designated label. We jump<br /> there also from the "!info-&gt;type" if now too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: ethernet: cpsw: fix panic when interrupt coaleceing is set via ethtool<br /> <br /> cpsw_ethtool_begin directly returns the result of pm_runtime_get_sync<br /> when successful.<br /> pm_runtime_get_sync returns -error code on failure and 0 on successful<br /> resume but also 1 when the device is already active. So the common case<br /> for cpsw_ethtool_begin is to return 1. That leads to inconsistent calls<br /> to pm_runtime_put in the call-chain so that pm_runtime_put is called<br /> one too many times and as result leaving the cpsw dev behind suspended.<br /> <br /> The suspended cpsw dev leads to an access violation later on by<br /> different parts of the cpsw driver.<br /> <br /> Fix this by calling the return-friendly pm_runtime_resume_and_get<br /> function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix &amp;#39;scheduling while atomic&amp;#39; on aux critical err interrupt<br /> <br /> There&amp;#39;s a kernel BUG splat on processing aux critical error<br /> interrupts in ice_misc_intr():<br /> <br /> [ 2100.917085] BUG: scheduling while atomic: swapper/15/0/0x00010000<br /> ...<br /> [ 2101.060770] Call Trace:<br /> [ 2101.063229] <br /> [ 2101.065252] dump_stack+0x41/0x60<br /> [ 2101.068587] __schedule_bug.cold.100+0x4c/0x58<br /> [ 2101.073060] __schedule+0x6a4/0x830<br /> [ 2101.076570] schedule+0x35/0xa0<br /> [ 2101.079727] schedule_preempt_disabled+0xa/0x10<br /> [ 2101.084284] __mutex_lock.isra.7+0x310/0x420<br /> [ 2101.088580] ? ice_misc_intr+0x201/0x2e0 [ice]<br /> [ 2101.093078] ice_send_event_to_aux+0x25/0x70 [ice]<br /> [ 2101.097921] ice_misc_intr+0x220/0x2e0 [ice]<br /> [ 2101.102232] __handle_irq_event_percpu+0x40/0x180<br /> [ 2101.106965] handle_irq_event_percpu+0x30/0x80<br /> [ 2101.111434] handle_irq_event+0x36/0x53<br /> [ 2101.115292] handle_edge_irq+0x82/0x190<br /> [ 2101.119148] handle_irq+0x1c/0x30<br /> [ 2101.122480] do_IRQ+0x49/0xd0<br /> [ 2101.125465] common_interrupt+0xf/0xf<br /> [ 2101.129146] <br /> ...<br /> <br /> As Andrew correctly mentioned previously[0], the following call<br /> ladder happens:<br /> <br /> ice_misc_intr()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: fix panic on shutdown if multi-chip tree failed to probe<br /> <br /> DSA probing is atypical because a tree of devices must probe all at<br /> once, so out of N switches which call dsa_tree_setup_routing_table()<br /> during probe, for (N - 1) of them, "complete" will return false and they<br /> will exit probing early. The Nth switch will set up the whole tree on<br /> their behalf.<br /> <br /> The implication is that for (N - 1) switches, the driver binds to the<br /> device successfully, without doing anything. When the driver is bound,<br /> the -&gt;shutdown() method may run. But if the Nth switch has failed to<br /> initialize the tree, there is nothing to do for the (N - 1) driver<br /> instances, since the slave devices have not been created, etc. Moreover,<br /> dsa_switch_shutdown() expects that the calling @ds has been in fact<br /> initialized, so it jumps at dereferencing the various data structures,<br /> which is incorrect.<br /> <br /> Avoid the ensuing NULL pointer dereferences by simply checking whether<br /> the Nth switch has previously set "ds-&gt;setup = true" for the switch<br /> which is currently shutting down. The entire setup is serialized under<br /> dsa2_mutex which we already hold.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: Fix use after free in remove_phb_dynamic()<br /> <br /> In remove_phb_dynamic() we use &amp;phb-&gt;io_resource, after we&amp;#39;ve called<br /> device_unregister(&amp;host_bridge-&gt;dev). But the unregister may have freed<br /> phb, because pcibios_free_controller_deferred() is the release function<br /> for the host_bridge.<br /> <br /> If there are no outstanding references when we call device_unregister()<br /> then phb will be freed out from under us.<br /> <br /> This has gone mainly unnoticed, but with slub_debug and page_poison<br /> enabled it can lead to a crash:<br /> <br /> PID: 7574 TASK: c0000000d492cb80 CPU: 13 COMMAND: "drmgr"<br /> #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc<br /> #1 [c0000000e4f075d0] oops_end at c000000000029608<br /> #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4<br /> #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8<br /> #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30<br /> Data SLB Access [380] exception frame:<br /> R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100<br /> R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9<br /> R6: 3894674d000000c0 R7: 0000000000000000 R8: 00000000000000ff<br /> R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000<br /> R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000<br /> R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003<br /> R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005<br /> R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0<br /> R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8<br /> R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800<br /> R30: c00000004d1d2400 R31: c00000004d1d2540<br /> NIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474<br /> CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003<br /> CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3<br /> DSISR: c0000000e4f07920 Syscall Result: fffffffffffffff2<br /> [NIP : release_resource+56]<br /> [LR : release_resource+48]<br /> #5 [c0000000e4f07a00] release_resource at c000000000167258 (unreliable)<br /> #6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648<br /> #7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io]<br /> #8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io]<br /> #9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c<br /> #10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504<br /> #11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868<br /> #12 [c0000000e4f07c70] new_sync_write at c00000000054339c<br /> #13 [c0000000e4f07d10] vfs_write at c000000000546624<br /> #14 [c0000000e4f07d60] ksys_write at c0000000005469f4<br /> #15 [c0000000e4f07db0] system_call_exception at c000000000030840<br /> #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168<br /> <br /> To avoid it, we can take a reference to the host_bridge-&gt;dev until we&amp;#39;re<br /> done using phb. Then when we drop the reference the phb will be freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_netlink: Fix shift out of bounds in group mask calculation<br /> <br /> When a netlink message is received, netlink_recvmsg() fills in the address<br /> of the sender. One of the fields is the 32-bit bitfield nl_groups, which<br /> carries the multicast group on which the message was received. The least<br /> significant bit corresponds to group 1, and therefore the highest group<br /> that the field can represent is 32. Above that, the UB sanitizer flags the<br /> out-of-bounds shift attempts.<br /> <br /> Which bits end up being set in such case is implementation defined, but<br /> it&amp;#39;s either going to be a wrong non-zero value, or zero, which is at least<br /> not misleading. Make the latter choice deterministic by always setting to 0<br /> for higher-numbered multicast groups.<br /> <br /> To get information about membership in groups &gt;= 32, userspace is expected<br /> to use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFO<br /> socket option.<br /> [0] https://lwn.net/Articles/147608/<br /> <br /> The way to trigger this issue is e.g. through monitoring the BRVLAN group:<br /> <br /> # bridge monitor vlan &amp;<br /> # ip link add name br type bridge<br /> <br /> Which produces the following citation:<br /> <br /> UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19<br /> shift exponent 32 is too large for 32-bit type &amp;#39;int&amp;#39;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: Fix crash due to tcp_tsorted_anchor was initialized before release skb<br /> <br /> Got crash when doing pressure test of mptcp:<br /> <br /> ===========================================================================<br /> dst_release: dst:ffffa06ce6e5c058 refcnt:-1<br /> kernel tried to execute NX-protected page - exploit attempt? (uid: 0)<br /> BUG: unable to handle kernel paging request at ffffa06ce6e5c058<br /> PGD 190a01067 P4D 190a01067 PUD 43fffb067 PMD 22e403063 PTE 8000000226e5c063<br /> Oops: 0011 [#1] SMP PTI<br /> CPU: 7 PID: 7823 Comm: kworker/7:0 Kdump: loaded Tainted: G E<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.2.1 04/01/2014<br /> Call Trace:<br /> ? skb_release_head_state+0x68/0x100<br /> ? skb_release_all+0xe/0x30<br /> ? kfree_skb+0x32/0xa0<br /> ? mptcp_sendmsg_frag+0x57e/0x750<br /> ? __mptcp_retrans+0x21b/0x3c0<br /> ? __switch_to_asm+0x35/0x70<br /> ? mptcp_worker+0x25e/0x320<br /> ? process_one_work+0x1a7/0x360<br /> ? worker_thread+0x30/0x390<br /> ? create_worker+0x1a0/0x1a0<br /> ? kthread+0x112/0x130<br /> ? kthread_flush_work_fn+0x10/0x10<br /> ? ret_from_fork+0x35/0x40<br /> ===========================================================================<br /> <br /> In __mptcp_alloc_tx_skb skb was allocated and skb-&gt;tcp_tsorted_anchor will<br /> be initialized, in under memory pressure situation sk_wmem_schedule will<br /> return false and then kfree_skb. In this case skb-&gt;_skb_refdst is not null<br /> because_skb_refdst and tcp_tsorted_anchor are stored in the same mem, and<br /> kfree_skb will try to release dst and cause crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/nldev: Prevent underflow in nldev_stat_set_counter_dynamic_doit()<br /> <br /> This code checks "index" for an upper bound but it does not check for<br /> negatives. Change the type to unsigned to prevent underflows.