Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/ipv6: avoid possible UAF in ip6_route_mpath_notify()<br /> <br /> syzbot found another use-after-free in ip6_route_mpath_notify() [1]<br /> <br /> Commit f7225172f25a ("net/ipv6: prevent use after free in<br /> ip6_route_mpath_notify") was not able to fix the root cause.<br /> <br /> We need to defer the fib6_info_release() calls after<br /> ip6_route_mpath_notify(), in the cleanup phase.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0<br /> Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037<br /> <br /> CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x167/0x540 mm/kasan/report.c:488<br /> kasan_report+0x142/0x180 mm/kasan/report.c:601<br /> rt6_fill_node+0x1460/0x1ac0<br /> inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184<br /> ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]<br /> ip6_route_multipath_add net/ipv6/route.c:5404 [inline]<br /> inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517<br /> rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597<br /> netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]<br /> netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367<br /> netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:745<br /> ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584<br /> ___sys_sendmsg net/socket.c:2638 [inline]<br /> __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667<br /> do_syscall_64+0xf9/0x240<br /> entry_SYSCALL_64_after_hwframe+0x6f/0x77<br /> RIP: 0033:0x7f73dd87dda9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9<br /> RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005<br /> RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858<br /> <br /> <br /> Allocated by task 23037:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:372 [inline]<br /> __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389<br /> kasan_kmalloc include/linux/kasan.h:211 [inline]<br /> __do_kmalloc_node mm/slub.c:3981 [inline]<br /> __kmalloc+0x22e/0x490 mm/slub.c:3994<br /> kmalloc include/linux/slab.h:594 [inline]<br /> kzalloc include/linux/slab.h:711 [inline]<br /> fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155<br /> ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758<br /> ip6_route_multipath_add net/ipv6/route.c:5298 [inline]<br /> inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517<br /> rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597<br /> netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]<br /> netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367<br /> netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:745<br /> ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584<br /> ___sys_sendmsg net/socket.c:2638 [inline]<br /> __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667<br /> do_syscall_64+0xf9/0x240<br /> entry_SYSCALL_64_after_hwframe+0x6f/0x77<br /> <br /> Freed by task 16:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640<br /> poison_slab_object+0xa6/0xe0 m<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: avoid returning frame twice in XDP_REDIRECT<br /> <br /> When a frame can not be transmitted in XDP_REDIRECT<br /> (e.g. due to a full queue), it is necessary to free<br /> it by calling xdp_return_frame_rx_napi.<br /> <br /> However, this is the responsibility of the caller of<br /> the ndo_xdp_xmit (see for example bq_xmit_all in<br /> kernel/bpf/devmap.c) and thus calling it inside<br /> igc_xdp_xmit (which is the ndo_xdp_xmit of the igc<br /> driver) as well will lead to memory corruption.<br /> <br /> In fact, bq_xmit_all expects that it can return all<br /> frames after the last successfully transmitted one.<br /> Therefore, break for the first not transmitted frame,<br /> but do not call xdp_return_frame_rx_napi in igc_xdp_xmit.<br /> This is equally implemented in other Intel drivers<br /> such as the igb.<br /> <br /> There are two alternatives to this that were rejected:<br /> 1. Return num_frames as all the frames would have been<br /> transmitted and release them inside igc_xdp_xmit.<br /> While it might work technically, it is not what<br /> the return value is meant to represent (i.e. the<br /> number of SUCCESSFULLY transmitted packets).<br /> 2. Rework kernel/bpf/devmap.c and all drivers to<br /> support non-consecutively dropped packets.<br /> Besides being complex, it likely has a negative<br /> performance impact without a significant gain<br /> since it is anyway unlikely that the next frame<br /> can be transmitted if the previous one was dropped.<br /> <br /> The memory corruption can be reproduced with<br /> the following script which leads to a kernel panic<br /> after a few seconds. It basically generates more<br /> traffic than a i225 NIC can transmit and pushes it<br /> via XDP_REDIRECT from a virtual interface to the<br /> physical interface where frames get dropped.<br /> <br /> #!/bin/bash<br /> INTERFACE=enp4s0<br /> INTERFACE_IDX=`cat /sys/class/net/$INTERFACE/ifindex`<br /> <br /> sudo ip link add dev veth1 type veth peer name veth2<br /> sudo ip link set up $INTERFACE<br /> sudo ip link set up veth1<br /> sudo ip link set up veth2<br /> <br /> cat

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix uninitialized dplls mutex usage<br /> <br /> The pf-&gt;dplls.lock mutex is initialized too late, after its first use.<br /> Move it to the top of ice_dpll_init.<br /> Note that the "err_exit" error path destroys the mutex. And the mutex is<br /> the last thing destroyed in ice_dpll_deinit.<br /> This fixes the following warning with CONFIG_DEBUG_MUTEXES:<br /> <br /> ice 0000:10:00.0: The DDP package was successfully loaded: ICE OS Default Package version 1.3.36.0<br /> ice 0000:10:00.0: 252.048 Gb/s available PCIe bandwidth (16.0 GT/s PCIe x16 link)<br /> ice 0000:10:00.0: PTP init successful<br /> ------------[ cut here ]------------<br /> DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)<br /> WARNING: CPU: 0 PID: 410 at kernel/locking/mutex.c:587 __mutex_lock+0x773/0xd40<br /> Modules linked in: crct10dif_pclmul crc32_pclmul crc32c_intel polyval_clmulni polyval_generic ice(+) nvme nvme_c&gt;<br /> CPU: 0 PID: 410 Comm: kworker/0:4 Not tainted 6.8.0-rc5+ #3<br /> Hardware name: HPE ProLiant DL110 Gen10 Plus/ProLiant DL110 Gen10 Plus, BIOS U56 10/19/2023<br /> Workqueue: events work_for_cpu_fn<br /> RIP: 0010:__mutex_lock+0x773/0xd40<br /> Code: c0 0f 84 1d f9 ff ff 44 8b 35 0d 9c 69 01 45 85 f6 0f 85 0d f9 ff ff 48 c7 c6 12 a2 a9 85 48 c7 c7 12 f1 a&gt;<br /> RSP: 0018:ff7eb1a3417a7ae0 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000<br /> RDX: 0000000000000002 RSI: ffffffff85ac2bff RDI: 00000000ffffffff<br /> RBP: ff7eb1a3417a7b80 R08: 0000000000000000 R09: 00000000ffffbfff<br /> R10: ff7eb1a3417a7978 R11: ff32b80f7fd2e568 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 0000000000000000 R15: ff32b7f02c50e0d8<br /> FS: 0000000000000000(0000) GS:ff32b80efe800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055b5852cc000 CR3: 000000003c43a004 CR4: 0000000000771ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __warn+0x84/0x170<br /> ? __mutex_lock+0x773/0xd40<br /> ? report_bug+0x1c7/0x1d0<br /> ? prb_read_valid+0x1b/0x30<br /> ? handle_bug+0x42/0x70<br /> ? exc_invalid_op+0x18/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? __mutex_lock+0x773/0xd40<br /> ? rcu_is_watching+0x11/0x50<br /> ? __kmalloc_node_track_caller+0x346/0x490<br /> ? ice_dpll_lock_status_get+0x28/0x50 [ice]<br /> ? __pfx_ice_dpll_lock_status_get+0x10/0x10 [ice]<br /> ? ice_dpll_lock_status_get+0x28/0x50 [ice]<br /> ice_dpll_lock_status_get+0x28/0x50 [ice]<br /> dpll_device_get_one+0x14f/0x2e0<br /> dpll_device_event_send+0x7d/0x150<br /> dpll_device_register+0x124/0x180<br /> ice_dpll_init_dpll+0x7b/0xd0 [ice]<br /> ice_dpll_init+0x224/0xa40 [ice]<br /> ? _dev_info+0x70/0x90<br /> ice_load+0x468/0x690 [ice]<br /> ice_probe+0x75b/0xa10 [ice]<br /> ? _raw_spin_unlock_irqrestore+0x4f/0x80<br /> ? process_one_work+0x1a3/0x500<br /> local_pci_probe+0x47/0xa0<br /> work_for_cpu_fn+0x17/0x30<br /> process_one_work+0x20d/0x500<br /> worker_thread+0x1df/0x3e0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x103/0x140<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x31/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> irq event stamp: 125197<br /> hardirqs last enabled at (125197): [] finish_task_switch.isra.0+0x12d/0x3d0<br /> hardirqs last disabled at (125196): [] __schedule+0xea4/0x19f0<br /> softirqs last enabled at (105334): [] napi_get_frags_check+0x1a/0x60<br /> softirqs last disabled at (105332): [] napi_get_frags_check+0x1a/0x60<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()<br /> <br /> The function ice_bridge_setlink() may encounter a NULL pointer dereference<br /> if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently<br /> in nla_for_each_nested(). To address this issue, add a check to ensure that<br /> br_spec is not NULL before proceeding with the nested attribute iteration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sparx5: Fix use after free inside sparx5_del_mact_entry<br /> <br /> Based on the static analyzis of the code it looks like when an entry<br /> from the MAC table was removed, the entry was still used after being<br /> freed. More precise the vid of the mac_entry was used after calling<br /> devm_kfree on the mac_entry.<br /> The fix consists in first using the vid of the mac_entry to delete the<br /> entry from the HW and after that to free it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> geneve: make sure to pull inner header in geneve_rx()<br /> <br /> syzbot triggered a bug in geneve_rx() [1]<br /> <br /> Issue is similar to the one I fixed in commit 8d975c15c0cd<br /> ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")<br /> <br /> We have to save skb-&gt;network_header in a temporary variable<br /> in order to be able to recompute the network_header pointer<br /> after a pskb_inet_may_pull() call.<br /> <br /> pskb_inet_may_pull() makes sure the needed headers are in skb-&gt;head.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]<br /> BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]<br /> BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391<br /> IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]<br /> geneve_rx drivers/net/geneve.c:279 [inline]<br /> geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391<br /> udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108<br /> udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186<br /> udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346<br /> __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422<br /> udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604<br /> ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205<br /> ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254<br /> dst_input include/net/dst.h:461 [inline]<br /> ip_rcv_finish net/ipv4/ip_input.c:449 [inline]<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569<br /> __netif_receive_skb_one_core net/core/dev.c:5534 [inline]<br /> __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648<br /> process_backlog+0x480/0x8b0 net/core/dev.c:5976<br /> __napi_poll+0xe3/0x980 net/core/dev.c:6576<br /> napi_poll net/core/dev.c:6645 [inline]<br /> net_rx_action+0x8b8/0x1870 net/core/dev.c:6778<br /> __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553<br /> do_softirq+0x9a/0xf0 kernel/softirq.c:454<br /> __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381<br /> local_bh_enable include/linux/bottom_half.h:33 [inline]<br /> rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]<br /> __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378<br /> dev_queue_xmit include/linux/netdevice.h:3171 [inline]<br /> packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276<br /> packet_snd net/packet/af_packet.c:3081 [inline]<br /> packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg net/socket.c:745 [inline]<br /> __sys_sendto+0x735/0xa10 net/socket.c:2191<br /> __do_sys_sendto net/socket.c:2203 [inline]<br /> __se_sys_sendto net/socket.c:2199 [inline]<br /> __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:3819 [inline]<br /> slab_alloc_node mm/slub.c:3860 [inline]<br /> kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903<br /> kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560<br /> __alloc_skb+0x352/0x790 net/core/skbuff.c:651<br /> alloc_skb include/linux/skbuff.h:1296 [inline]<br /> alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394<br /> sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783<br /> packet_alloc_skb net/packet/af_packet.c:2930 [inline]<br /> packet_snd net/packet/af_packet.c:3024 [inline]<br /> packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg net/socket.c:745 [inline]<br /> __sys_sendto+0x735/0xa10 net/socket.c:2191<br /> __do_sys_sendto net/socket.c:2203 [inline]<br /> __se_sys_sendto net/socket.c:2199 [inline]<br /> __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Use a memory barrier to enforce PTP WQ xmit submission tracking occurs after populating the metadata_map<br /> <br /> Just simply reordering the functions mlx5e_ptp_metadata_map_put and<br /> mlx5e_ptpsq_track_metadata in the mlx5e_txwqe_complete context is not good<br /> enough since both the compiler and CPU are free to reorder these two<br /> functions. If reordering does occur, the issue that was supposedly fixed by<br /> 7e3f3ba97e6c ("net/mlx5e: Track xmit submission to PTP WQ after populating<br /> metadata map") will be seen. This will lead to NULL pointer dereferences in<br /> mlx5e_ptpsq_mark_ts_cqes_undelivered in the NAPI polling context due to the<br /> tracking list being populated before the metadata map.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/bnx2x: Prevent access to a freed page in page_pool<br /> <br /> Fix race condition leading to system crash during EEH error handling<br /> <br /> During EEH error recovery, the bnx2x driver&amp;#39;s transmit timeout logic<br /> could cause a race condition when handling reset tasks. The<br /> bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),<br /> which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()<br /> SGEs are freed using bnx2x_free_rx_sge_range(). However, this could<br /> overlap with the EEH driver&amp;#39;s attempt to reset the device using<br /> bnx2x_io_slot_reset(), which also tries to free SGEs. This race<br /> condition can result in system crashes due to accessing freed memory<br /> locations in bnx2x_free_rx_sge()<br /> <br /> 799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,<br /> 800 struct bnx2x_fastpath *fp, u16 index)<br /> 801 {<br /> 802 struct sw_rx_page *sw_buf = &amp;fp-&gt;rx_page_ring[index];<br /> 803 struct page *page = sw_buf-&gt;page;<br /> ....<br /> where sw_buf was set to NULL after the call to dma_unmap_page()<br /> by the preceding thread.<br /> <br /> EEH: Beginning: &amp;#39;slot_reset&amp;#39;<br /> PCI 0011:01:00.0#10000: EEH: Invoking bnx2x-&gt;slot_reset()<br /> bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...<br /> bnx2x 0011:01:00.0: enabling device (0140 -&gt; 0142)<br /> bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --&gt; driver unload<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: 0xc0080000025065fc<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> .....<br /> Call Trace:<br /> [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)<br /> [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0<br /> [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550<br /> [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60<br /> [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170<br /> [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0<br /> [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64<br /> <br /> To solve this issue, we need to verify page pool allocations before<br /> freeing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-integrity: fix a memory leak when rechecking the data<br /> <br /> Memory for the "checksums" pointer will leak if the data is rechecked<br /> after checksum failure (because the associated kfree won&amp;#39;t happen due<br /> to &amp;#39;goto skip_io&amp;#39;).<br /> <br /> Fix this by freeing the checksums memory before recheck, and just use<br /> the "checksum_onstack" memory for storing checksum during recheck.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wireguard: receive: annotate data-race around receiving_counter.counter<br /> <br /> Syzkaller with KCSAN identified a data-race issue when accessing<br /> keypair-&gt;receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE()<br /> annotations to mark the data race as intentional.<br /> <br /> BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll<br /> <br /> write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0:<br /> counter_validate drivers/net/wireguard/receive.c:321 [inline]<br /> wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461<br /> __napi_poll+0x60/0x3b0 net/core/dev.c:6536<br /> napi_poll net/core/dev.c:6605 [inline]<br /> net_rx_action+0x32b/0x750 net/core/dev.c:6738<br /> __do_softirq+0xc4/0x279 kernel/softirq.c:553<br /> do_softirq+0x5e/0x90 kernel/softirq.c:454<br /> __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381<br /> __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]<br /> _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210<br /> spin_unlock_bh include/linux/spinlock.h:396 [inline]<br /> ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline]<br /> wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499<br /> process_one_work kernel/workqueue.c:2633 [inline]<br /> ...<br /> <br /> read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1:<br /> decrypt_packet drivers/net/wireguard/receive.c:252 [inline]<br /> wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501<br /> process_one_work kernel/workqueue.c:2633 [inline]<br /> process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706<br /> worker_thread+0x525/0x730 kernel/workqueue.c:2787<br /> ...

Missing Authorization vulnerability in Undsgn Uncode Core.This issue affects Uncode Core: from n/a through 2.8.8.<br /> <br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: add nla be16/32 types to minlen array<br /> <br /> BUG: KMSAN: uninit-value in nla_validate_range_unsigned lib/nlattr.c:222 [inline]<br /> BUG: KMSAN: uninit-value in nla_validate_int_range lib/nlattr.c:336 [inline]<br /> BUG: KMSAN: uninit-value in validate_nla lib/nlattr.c:575 [inline]<br /> BUG: KMSAN: uninit-value in __nla_validate_parse+0x2e20/0x45c0 lib/nlattr.c:631<br /> nla_validate_range_unsigned lib/nlattr.c:222 [inline]<br /> nla_validate_int_range lib/nlattr.c:336 [inline]<br /> validate_nla lib/nlattr.c:575 [inline]<br /> ...<br /> <br /> The message in question matches this policy:<br /> <br /> [NFTA_TARGET_REV] = NLA_POLICY_MAX(NLA_BE32, 255),<br /> <br /> but because NLA_BE32 size in minlen array is 0, the validation<br /> code will read past the malformed (too small) attribute.<br /> <br /> Note: Other attributes, e.g. BITFIELD32, SINT, UINT.. are also missing:<br /> those likely should be added too.