Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: fix possible cp null dereference<br /> <br /> cp might be null, calling cp-&gt;cp_conn would produce null dereference<br /> <br /> [Simon Horman adds:]<br /> <br /> Analysis:<br /> <br /> * cp is a parameter of __rds_rdma_map and is not reassigned.<br /> <br /> * The following call-sites pass a NULL cp argument to __rds_rdma_map()<br /> <br /> - rds_get_mr()<br /> - rds_get_mr_for_dest<br /> <br /> * Prior to the code above, the following assumes that cp may be NULL<br /> (which is indicative, but could itself be unnecessary)<br /> <br /> trans_private = rs-&gt;rs_transport-&gt;get_mr(<br /> sg, nents, rs, &amp;mr-&gt;r_key, cp ? cp-&gt;cp_conn : NULL,<br /> args-&gt;vec.addr, args-&gt;vec.bytes,<br /> need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);<br /> <br /> * The code modified by this patch is guarded by IS_ERR(trans_private),<br /> where trans_private is assigned as per the previous point in this analysis.<br /> <br /> The only implementation of get_mr that I could locate is rds_ib_get_mr()<br /> which can return an ERR_PTR if the conn (4th) argument is NULL.<br /> <br /> * ret is set to PTR_ERR(trans_private).<br /> rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.<br /> Thus ret may be -ENODEV in which case the code in question will execute.<br /> <br /> Conclusion:<br /> * cp may be NULL at the point where this patch adds a check;<br /> this patch does seem to address a possible bug

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Protect against int overflow for stack access size<br /> <br /> This patch re-introduces protection against the size of access to stack<br /> memory being negative; the access size can appear negative as a result<br /> of overflowing its signed int representation. This should not actually<br /> happen, as there are other protections along the way, but we should<br /> protect against it anyway. One code path was missing such protections<br /> (fixed in the previous patch in the series), causing out-of-bounds array<br /> accesses in check_stack_range_initialized(). This patch causes the<br /> verification of a program with such a non-sensical access size to fail.<br /> <br /> This check used to exist in a more indirect way, but was inadvertendly<br /> removed in a833a17aeac7.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: properly terminate timers for kernel sockets<br /> <br /> We had various syzbot reports about tcp timers firing after<br /> the corresponding netns has been dismantled.<br /> <br /> Fortunately Josef Bacik could trigger the issue more often,<br /> and could test a patch I wrote two years ago.<br /> <br /> When TCP sockets are closed, we call inet_csk_clear_xmit_timers()<br /> to &amp;#39;stop&amp;#39; the timers.<br /> <br /> inet_csk_clear_xmit_timers() can be called from any context,<br /> including when socket lock is held.<br /> This is the reason it uses sk_stop_timer(), aka del_timer().<br /> This means that ongoing timers might finish much later.<br /> <br /> For user sockets, this is fine because each running timer<br /> holds a reference on the socket, and the user socket holds<br /> a reference on the netns.<br /> <br /> For kernel sockets, we risk that the netns is freed before<br /> timer can complete, because kernel sockets do not hold<br /> reference on the netns.<br /> <br /> This patch adds inet_csk_clear_xmit_timers_sync() function<br /> that using sk_stop_timer_sync() to make sure all timers<br /> are terminated before the kernel socket is released.<br /> Modules using kernel sockets close them in their netns exit()<br /> handler.<br /> <br /> Also add sock_not_owned_by_me() helper to get LOCKDEP<br /> support : inet_csk_clear_xmit_timers_sync() must not be called<br /> while socket lock is held.<br /> <br /> It is very possible we can revert in the future commit<br /> 3a58f13a881e ("net: rds: acquire refcount on TCP sockets")<br /> which attempted to solve the issue in rds only.<br /> (net/smc/af_smc.c and net/mptcp/subflow.c have similar code)<br /> <br /> We probably can remove the check_net() tests from<br /> tcp_out_of_resources() and __tcp_close() in the future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet<br /> <br /> syzbot reported the following uninit-value access issue [1][2]:<br /> <br /> nci_rx_work() parses and processes received packet. When the payload<br /> length is zero, each message type handler reads uninitialized payload<br /> and KMSAN detects this issue. The receipt of a packet with a zero-size<br /> payload is considered unexpected, and therefore, such packets should be<br /> silently discarded.<br /> <br /> This patch resolved this issue by checking payload size before calling<br /> each message type handler codes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gro: fix ownership transfer<br /> <br /> If packets are GROed with fraglist they might be segmented later on and<br /> continue their journey in the stack. In skb_segment_list those skbs can<br /> be reused as-is. This is an issue as their destructor was removed in<br /> skb_gro_receive_list but not the reference to their socket, and then<br /> they can&amp;#39;t be orphaned. Fix this by also removing the reference to the<br /> socket.<br /> <br /> For example this could be observed,<br /> <br /> kernel BUG at include/linux/skbuff.h:3131! (skb_orphan)<br /> RIP: 0010:ip6_rcv_core+0x11bc/0x19a0<br /> Call Trace:<br /> ipv6_list_rcv+0x250/0x3f0<br /> __netif_receive_skb_list_core+0x49d/0x8f0<br /> netif_receive_skb_list_internal+0x634/0xd40<br /> napi_complete_done+0x1d2/0x7d0<br /> gro_cell_poll+0x118/0x1f0<br /> <br /> A similar construction is found in skb_gro_receive, apply the same<br /> change there.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: micrel: Fix potential null pointer dereference<br /> <br /> In lan8814_get_sig_rx() and lan8814_get_sig_tx() ptp_parse_header() may<br /> return NULL as ptp_header due to abnormal packet type or corrupted packet.<br /> Fix this bug by adding ptp_header check.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: fix lockdep splat in qdisc_tree_reduce_backlog()<br /> <br /> qdisc_tree_reduce_backlog() is called with the qdisc lock held,<br /> not RTNL.<br /> <br /> We must use qdisc_lookup_rcu() instead of qdisc_lookup()<br /> <br /> syzbot reported:<br /> <br /> WARNING: suspicious RCU usage<br /> 6.1.74-syzkaller #0 Not tainted<br /> -----------------------------<br /> net/sched/sch_api.c:305 suspicious rcu_dereference_protected() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 3 locks held by udevd/1142:<br /> #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]<br /> #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]<br /> #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: net_tx_action+0x64a/0x970 net/core/dev.c:5282<br /> #1: ffff888171861108 (&amp;sch-&gt;q.lock){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:350 [inline]<br /> #1: ffff888171861108 (&amp;sch-&gt;q.lock){+.-.}-{2:2}, at: net_tx_action+0x754/0x970 net/core/dev.c:5297<br /> #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]<br /> #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]<br /> #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792<br /> <br /> stack backtrace:<br /> CPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #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+0x1b1/0x28f lib/dump_stack.c:106<br /> [] dump_stack+0x15/0x1e lib/dump_stack.c:113<br /> [] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592<br /> [] qdisc_lookup+0xac/0x6f0 net/sched/sch_api.c:305<br /> [] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811<br /> [] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51<br /> [] qdisc_enqueue include/net/sch_generic.h:833 [inline]<br /> [] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723<br /> [] dequeue_skb net/sched/sch_generic.c:292 [inline]<br /> [] qdisc_restart net/sched/sch_generic.c:397 [inline]<br /> [] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415<br /> [] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125<br /> [] net_tx_action+0x7c9/0x970 net/core/dev.c:5313<br /> [] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616<br /> [] invoke_softirq kernel/softirq.c:447 [inline]<br /> [] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700<br /> [] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712<br /> [] sysvec_apic_timer_interrupt+0x42/0x90 arch/x86/kernel/apic/apic.c:1107<br /> [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: prevent BPF accessing lowat from a subflow socket.<br /> <br /> Alexei reported the following splat:<br /> <br /> WARNING: CPU: 32 PID: 3276 at net/mptcp/subflow.c:1430 subflow_data_ready+0x147/0x1c0<br /> Modules linked in: dummy bpf_testmod(O) [last unloaded: bpf_test_no_cfi(O)]<br /> CPU: 32 PID: 3276 Comm: test_progs Tainted: GO 6.8.0-12873-g2c43c33bfd23<br /> Call Trace:<br /> <br /> mptcp_set_rcvlowat+0x79/0x1d0<br /> sk_setsockopt+0x6c0/0x1540<br /> __bpf_setsockopt+0x6f/0x90<br /> bpf_sock_ops_setsockopt+0x3c/0x90<br /> bpf_prog_509ce5db2c7f9981_bpf_test_sockopt_int+0xb4/0x11b<br /> bpf_prog_dce07e362d941d2b_bpf_test_socket_sockopt+0x12b/0x132<br /> bpf_prog_348c9b5faaf10092_skops_sockopt+0x954/0xe86<br /> __cgroup_bpf_run_filter_sock_ops+0xbc/0x250<br /> tcp_connect+0x879/0x1160<br /> tcp_v6_connect+0x50c/0x870<br /> mptcp_connect+0x129/0x280<br /> __inet_stream_connect+0xce/0x370<br /> inet_stream_connect+0x36/0x50<br /> bpf_trampoline_6442491565+0x49/0xef<br /> inet_stream_connect+0x5/0x50<br /> __sys_connect+0x63/0x90<br /> __x64_sys_connect+0x14/0x20<br /> <br /> The root cause of the issue is that bpf allows accessing mptcp-level<br /> proto_ops from a tcp subflow scope.<br /> <br /> Fix the issue detecting the problematic call and preventing any action.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Fix Rx DMA datasize and skb_over_panic<br /> <br /> mana_get_rxbuf_cfg() aligns the RX buffer&amp;#39;s DMA datasize to be<br /> multiple of 64. So a packet slightly bigger than mtu+14, say 1536,<br /> can be received and cause skb_over_panic.<br /> <br /> Sample dmesg:<br /> [ 5325.237162] skbuff: skb_over_panic: text:ffffffffc043277a len:1536 put:1536 head:ff1100018b517000 data:ff1100018b517100 tail:0x700 end:0x6ea dev:<br /> [ 5325.243689] ------------[ cut here ]------------<br /> [ 5325.245748] kernel BUG at net/core/skbuff.c:192!<br /> [ 5325.247838] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 5325.258374] RIP: 0010:skb_panic+0x4f/0x60<br /> [ 5325.302941] Call Trace:<br /> [ 5325.304389] <br /> [ 5325.315794] ? skb_panic+0x4f/0x60<br /> [ 5325.317457] ? asm_exc_invalid_op+0x1f/0x30<br /> [ 5325.319490] ? skb_panic+0x4f/0x60<br /> [ 5325.321161] skb_put+0x4e/0x50<br /> [ 5325.322670] mana_poll+0x6fa/0xb50 [mana]<br /> [ 5325.324578] __napi_poll+0x33/0x1e0<br /> [ 5325.326328] net_rx_action+0x12e/0x280<br /> <br /> As discussed internally, this alignment is not necessary. To fix<br /> this bug, remove it from the code. So oversized packets will be<br /> marked as CQE_RX_TRUNCATED by NIC, and dropped.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_skbmod: prevent kernel-infoleak<br /> <br /> syzbot found that tcf_skbmod_dump() was copying four bytes<br /> from kernel stack to user space [1].<br /> <br /> The issue here is that &amp;#39;struct tc_skbmod&amp;#39; has a four bytes hole.<br /> <br /> We need to clear the structure before filling fields.<br /> <br /> [1]<br /> BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]<br /> BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]<br /> BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]<br /> BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]<br /> BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185<br /> instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> copy_to_user_iter lib/iov_iter.c:24 [inline]<br /> iterate_ubuf include/linux/iov_iter.h:29 [inline]<br /> iterate_and_advance2 include/linux/iov_iter.h:245 [inline]<br /> iterate_and_advance include/linux/iov_iter.h:271 [inline]<br /> _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185<br /> copy_to_iter include/linux/uio.h:196 [inline]<br /> simple_copy_to_iter net/core/datagram.c:532 [inline]<br /> __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420<br /> skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546<br /> skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]<br /> netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962<br /> sock_recvmsg_nosec net/socket.c:1046 [inline]<br /> sock_recvmsg+0x2c4/0x340 net/socket.c:1068<br /> __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242<br /> __do_sys_recvfrom net/socket.c:2260 [inline]<br /> __se_sys_recvfrom net/socket.c:2256 [inline]<br /> __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256<br /> do_syscall_64+0xd5/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> Uninit was stored to memory at:<br /> pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253<br /> netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317<br /> netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351<br /> nlmsg_unicast include/net/netlink.h:1144 [inline]<br /> nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610<br /> rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741<br /> rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]<br /> tcf_add_notify net/sched/act_api.c:2048 [inline]<br /> tcf_action_add net/sched/act_api.c:2071 [inline]<br /> tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119<br /> rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595<br /> netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559<br /> rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]<br /> netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361<br /> netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:745<br /> ____sys_sendmsg+0x877/0xb60 net/socket.c:2584<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638<br /> __sys_sendmsg net/socket.c:2667 [inline]<br /> __do_sys_sendmsg net/socket.c:2676 [inline]<br /> __se_sys_sendmsg net/socket.c:2674 [inline]<br /> __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674<br /> do_syscall_64+0xd5/0x1f0<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> Uninit was stored to memory at:<br /> __nla_put lib/nlattr.c:1041 [inline]<br /> nla_put+0x1c6/0x230 lib/nlattr.c:1099<br /> tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256<br /> tcf_action_dump_old net/sched/act_api.c:1191 [inline]<br /> tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227<br /> tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251<br /> tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628<br /> tcf_add_notify_msg net/sched/act_api.c:2023 [inline]<br /> tcf_add_notify net/sched/act_api.c:2042 [inline]<br /> tcf_action_add net/sched/act_api.c:2071 [inline]<br /> tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119<br /> rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595<br /> netlink_rcv_skb+0x375/0x650 net/netlink/af_netli<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Prevent lock inversion deadlock in map delete elem<br /> <br /> syzkaller started using corpuses where a BPF tracing program deletes<br /> elements from a sockmap/sockhash map. Because BPF tracing programs can be<br /> invoked from any interrupt context, locks taken during a map_delete_elem<br /> operation must be hardirq-safe. Otherwise a deadlock due to lock inversion<br /> is possible, as reported by lockdep:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;htab-&gt;buckets[i].lock);<br /> local_irq_disable();<br /> lock(&amp;host-&gt;lock);<br /> lock(&amp;htab-&gt;buckets[i].lock);<br /> <br /> lock(&amp;host-&gt;lock);<br /> <br /> Locks in sockmap are hardirq-unsafe by design. We expects elements to be<br /> deleted from sockmap/sockhash only in task (normal) context with interrupts<br /> enabled, or in softirq context.<br /> <br /> Detect when map_delete_elem operation is invoked from a context which is<br /> _not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an<br /> error.<br /> <br /> Note that map updates are not affected by this issue. BPF verifier does not<br /> allow updating sockmap/sockhash from a BPF tracing program today.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: validate user input for expected length<br /> <br /> I got multiple syzbot reports showing old bugs exposed<br /> by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc<br /> in cgroup/{s,g}etsockopt")<br /> <br /> setsockopt() @optlen argument should be taken into account<br /> before copying data.<br /> <br /> BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]<br /> BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]<br /> BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]<br /> BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627<br /> Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238<br /> <br /> CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> kasan_check_range+0x282/0x290 mm/kasan/generic.c:189<br /> __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105<br /> copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]<br /> copy_from_sockptr include/linux/sockptr.h:55 [inline]<br /> do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]<br /> do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627<br /> nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101<br /> do_sock_setsockopt+0x3af/0x720 net/socket.c:2311<br /> __sys_setsockopt+0x1ae/0x250 net/socket.c:2334<br /> __do_sys_setsockopt net/socket.c:2343 [inline]<br /> __se_sys_setsockopt net/socket.c:2340 [inline]<br /> __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340<br /> do_syscall_64+0xfb/0x240<br /> entry_SYSCALL_64_after_hwframe+0x72/0x7a<br /> RIP: 0033:0x7fd22067dde9<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:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036<br /> RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9<br /> RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003<br /> RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8<br /> <br /> <br /> Allocated by task 7238:<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:370 [inline]<br /> __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387<br /> kasan_kmalloc include/linux/kasan.h:211 [inline]<br /> __do_kmalloc_node mm/slub.c:4069 [inline]<br /> __kmalloc_noprof+0x200/0x410 mm/slub.c:4082<br /> kmalloc_noprof include/linux/slab.h:664 [inline]<br /> __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869<br /> do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293<br /> __sys_setsockopt+0x1ae/0x250 net/socket.c:2334<br /> __do_sys_setsockopt net/socket.c:2343 [inline]<br /> __se_sys_setsockopt net/socket.c:2340 [inline]<br /> __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340<br /> do_syscall_64+0xfb/0x240<br /> entry_SYSCALL_64_after_hwframe+0x72/0x7a<br /> <br /> The buggy address belongs to the object at ffff88802cd73da0<br /> which belongs to the cache kmalloc-8 of size 8<br /> The buggy address is located 0 bytes inside of<br /> allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)<br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73<br /> flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)<br /> page_type: 0xffffefff(slab)<br /> raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122<br /> raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00<br /> ---truncated---