Vulnerabilities

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 /> bpf, sockmap: Fix more uncharged while msg has more_data<br /> <br /> In tcp_bpf_send_verdict(), if msg has more data after<br /> tcp_bpf_sendmsg_redir():<br /> <br /> tcp_bpf_send_verdict()<br /> tosend = msg-&gt;sg.size //msg-&gt;sg.size = 22220<br /> case __SK_REDIRECT:<br /> sk_msg_return() //uncharged msg-&gt;sg.size(22220) sk-&gt;sk_forward_alloc<br /> tcp_bpf_sendmsg_redir() //after tcp_bpf_sendmsg_redir, msg-&gt;sg.size=11000<br /> goto more_data;<br /> tosend = msg-&gt;sg.size //msg-&gt;sg.size = 11000<br /> case __SK_REDIRECT:<br /> sk_msg_return() //uncharged msg-&gt;sg.size(11000) to sk-&gt;sk_forward_alloc<br /> <br /> The msg-&gt;sg.size(11000) has been uncharged twice, to fix we can charge the<br /> remaining msg-&gt;sg.size before goto more data.<br /> <br /> This issue can cause the following info:<br /> WARNING: CPU: 0 PID: 9860 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0<br /> Call Trace:<br /> <br /> inet_csk_destroy_sock+0x55/0x110<br /> __tcp_close+0x279/0x470<br /> tcp_close+0x1f/0x60<br /> inet_release+0x3f/0x80<br /> __sock_release+0x3d/0xb0<br /> sock_close+0x11/0x20<br /> __fput+0x92/0x250<br /> task_work_run+0x6a/0xa0<br /> do_exit+0x33b/0xb60<br /> do_group_exit+0x2f/0xa0<br /> get_signal+0xb6/0x950<br /> arch_do_signal_or_restart+0xac/0x2a0<br /> ? vfs_write+0x237/0x290<br /> exit_to_user_mode_prepare+0xa9/0x200<br /> syscall_exit_to_user_mode+0x12/0x30<br /> do_syscall_64+0x46/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> <br /> WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260<br /> Call Trace:<br /> <br /> __sk_destruct+0x24/0x1f0<br /> sk_psock_destroy+0x19b/0x1c0<br /> process_one_work+0x1b3/0x3c0<br /> worker_thread+0x30/0x350<br /> ? process_one_work+0x3c0/0x3c0<br /> kthread+0xe6/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix double uncharge the mem of sk_msg<br /> <br /> If tcp_bpf_sendmsg is running during a tear down operation, psock may be<br /> freed.<br /> <br /> tcp_bpf_sendmsg()<br /> tcp_bpf_send_verdict()<br /> sk_msg_return()<br /> tcp_bpf_sendmsg_redir()<br /> unlikely(!psock))<br /> sk_msg_free()<br /> <br /> The mem of msg has been uncharged in tcp_bpf_send_verdict() by<br /> sk_msg_return(), and would be uncharged by sk_msg_free() again. When psock<br /> is null, we can simply returning an error code, this would then trigger<br /> the sk_msg_free_nocharge in the error path of __SK_REDIRECT and would have<br /> the side effect of throwing an error up to user space. This would be a<br /> slight change in behavior from user side but would look the same as an<br /> error if the redirect on the socket threw an error.<br /> <br /> This issue can cause the following info:<br /> WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260<br /> Call Trace:<br /> <br /> __sk_destruct+0x24/0x1f0<br /> sk_psock_destroy+0x19b/0x1c0<br /> process_one_work+0x1b3/0x3c0<br /> worker_thread+0x30/0x350<br /> ? process_one_work+0x3c0/0x3c0<br /> kthread+0xe6/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix memory leak in error flow for subscribe event routine<br /> <br /> In case the second xa_insert() fails, the obj_event is not released. Fix<br /> the error unwind flow to free that memory to avoid a memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix memleak in sk_psock_queue_msg<br /> <br /> If tcp_bpf_sendmsg is running during a tear down operation we may enqueue<br /> data on the ingress msg queue while tear down is trying to free it.<br /> <br /> sk1 (redirect sk2) sk2<br /> ------------------- ---------------<br /> tcp_bpf_sendmsg()<br /> tcp_bpf_send_verdict()<br /> tcp_bpf_sendmsg_redir()<br /> bpf_tcp_ingress()<br /> sock_map_close()<br /> lock_sock()<br /> lock_sock() ... blocking<br /> sk_psock_stop<br /> sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED);<br /> release_sock(sk);<br /> lock_sock()<br /> sk_mem_charge()<br /> get_page()<br /> sk_psock_queue_msg()<br /> sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED);<br /> drop_sk_msg()<br /> release_sock()<br /> <br /> While drop_sk_msg(), the msg has charged memory form sk by sk_mem_charge<br /> and has sg pages need to put. To fix we use sk_msg_free() and then kfee()<br /> msg.<br /> <br /> This issue can cause the following info:<br /> WARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0<br /> Call Trace:<br /> <br /> inet_csk_destroy_sock+0x55/0x110<br /> tcp_rcv_state_process+0xe5f/0xe90<br /> ? sk_filter_trim_cap+0x10d/0x230<br /> ? tcp_v4_do_rcv+0x161/0x250<br /> tcp_v4_do_rcv+0x161/0x250<br /> tcp_v4_rcv+0xc3a/0xce0<br /> ip_protocol_deliver_rcu+0x3d/0x230<br /> ip_local_deliver_finish+0x54/0x60<br /> ip_local_deliver+0xfd/0x110<br /> ? ip_protocol_deliver_rcu+0x230/0x230<br /> ip_rcv+0xd6/0x100<br /> ? ip_local_deliver+0x110/0x110<br /> __netif_receive_skb_one_core+0x85/0xa0<br /> process_backlog+0xa4/0x160<br /> __napi_poll+0x29/0x1b0<br /> net_rx_action+0x287/0x300<br /> __do_softirq+0xff/0x2fc<br /> do_softirq+0x79/0x90<br /> <br /> <br /> WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0<br /> Call Trace:<br /> <br /> __sk_destruct+0x24/0x1f0<br /> sk_psock_destroy+0x19b/0x1c0<br /> process_one_work+0x1b3/0x3c0<br /> ? process_one_work+0x3c0/0x3c0<br /> worker_thread+0x30/0x350<br /> ? process_one_work+0x3c0/0x3c0<br /> kthread+0xe6/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30<br />

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 /> 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: bcmgenet: Use stronger register read/writes to assure ordering<br /> <br /> GCC12 appears to be much smarter about its dependency tracking and is<br /> aware that the relaxed variants are just normal loads and stores and<br /> this is causing problems like:<br /> <br /> [ 210.074549] ------------[ cut here ]------------<br /> [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): transmit queue 1 timed out<br /> [ 210.086717] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240<br /> [ 210.095044] Modules linked in: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat]<br /> [ 210.146561] ACPI CPPC: PCC check channel failed for ss: 0. ret=-110<br /> [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 5.17.0-rc7G12+ #58<br /> [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: failed to read perf counters<br /> [ 210.161349] Hardware name: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022<br /> [ 210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 210.161358] pc : dev_watchdog+0x234/0x240<br /> [ 210.161364] lr : dev_watchdog+0x234/0x240<br /> [ 210.161368] sp : ffff8000080a3a40<br /> [ 210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20<br /> [ 210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08<br /> [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000<br /> [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffff<br /> [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a<br /> [ 210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0<br /> [ 210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9 : ffffcd4258bdad9c<br /> [ 210.248171] x8 : 00000000ffffdfff x7 : 000000000000003f x6 : 0000000000000000<br /> [ 210.255341] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000001000<br /> [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044<br /> [ 210.269682] Call trace:<br /> [ 210.272133] dev_watchdog+0x234/0x240<br /> [ 210.275811] call_timer_fn+0x3c/0x15c<br /> [ 210.279489] __run_timers.part.0+0x288/0x310<br /> [ 210.283777] run_timer_softirq+0x48/0x80<br /> [ 210.287716] __do_softirq+0x128/0x360<br /> [ 210.291392] __irq_exit_rcu+0x138/0x140<br /> [ 210.295243] irq_exit_rcu+0x1c/0x30<br /> [ 210.298745] el1_interrupt+0x38/0x54<br /> [ 210.302334] el1h_64_irq_handler+0x18/0x24<br /> [ 210.306445] el1h_64_irq+0x7c/0x80<br /> [ 210.309857] arch_cpu_idle+0x18/0x2c<br /> [ 210.313445] default_idle_call+0x4c/0x140<br /> [ 210.317470] cpuidle_idle_call+0x14c/0x1a0<br /> [ 210.321584] do_idle+0xb0/0x100<br /> [ 210.324737] cpu_startup_entry+0x30/0x8c<br /> [ 210.328675] secondary_start_kernel+0xe4/0x110<br /> [ 210.333138] __secondary_switched+0x94/0x98<br /> <br /> The assumption when these were relaxed seems to be that device memory<br /> would be mapped non reordering, and that other constructs<br /> (spinlocks/etc) would provide the barriers to assure that packet data<br /> and in memory rings/queues were ordered with respect to device<br /> register reads/writes. This itself seems a bit sketchy, but the real<br /> problem with GCC12 is that it is moving the actual reads/writes around<br /> at will as though they were independent operations when in truth they<br /> are not, but the compiler can&amp;#39;t know that. When looking at the<br /> assembly dumps for many of these routines its possible to see very<br /> clean, but not strictly in program order operations occurring as the<br /> compiler would be free to do if these weren&amp;#39;t actually register<br /> reads/write operations.<br /> <br /> Its possible to suppress the timeout with a liberal bit of dma_mb()&amp;#39;s<br /> sprinkled around but the device still seems unable to reliably<br /> send/receive data. A better plan is to use the safer readl/writel<br /> everywhere.<br /> <br /> Since this partially reverts an older commit, which notes the use of<br /> the relaxed variants for performance reasons. I would suggest that<br /> any performance problems <br /> ---truncated---

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.