Vulnerabilities

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 /> Bluetooth: hci_uart: add missing NULL check in h5_enqueue<br /> <br /> Syzbot hit general protection fault in __pm_runtime_resume(). The problem<br /> was in missing NULL check.<br /> <br /> hu-&gt;serdev can be NULL and we should not blindly pass &amp;serdev-&gt;dev<br /> somewhere, since it will cause GPF.

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---