Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: Fix error cleanup path in nfsd_rename()<br /> <br /> Commit a8b0026847b8 ("rename(): avoid a deadlock in the case of parents<br /> having no common ancestor") added an error bail out path. However this<br /> path does not drop the remount protection that has been acquired. Fix<br /> the cleanup path to properly drop the remount protection.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()<br /> <br /> nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can<br /> concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().<br /> And thhere is not any protection when iterate over nf_tables_flowtables<br /> list in __nft_flowtable_type_get(). Therefore, there is pertential<br /> data-race of nf_tables_flowtables list entry.<br /> <br /> Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list<br /> in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller<br /> nft_flowtable_type_get() to protect the entire type query process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: flush pending destroy work before exit_net release<br /> <br /> Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy<br /> work before netlink notifier") to address a race between exit_net and<br /> the destroy workqueue.<br /> <br /> The trace below shows an element to be released via destroy workqueue<br /> while exit_net path (triggered via module removal) has already released<br /> the set that is used in such transaction.<br /> <br /> [ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]<br /> [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465<br /> [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359<br /> [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]<br /> [ 1360.547984] Call Trace:<br /> [ 1360.547991] <br /> [ 1360.547998] dump_stack_lvl+0x53/0x70<br /> [ 1360.548014] print_report+0xc4/0x610<br /> [ 1360.548026] ? __virt_addr_valid+0xba/0x160<br /> [ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]<br /> [ 1360.548176] kasan_report+0xae/0xe0<br /> [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]<br /> [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]<br /> [ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables]<br /> [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30<br /> [ 1360.548591] process_one_work+0x2f1/0x670<br /> [ 1360.548610] worker_thread+0x4d3/0x760<br /> [ 1360.548627] ? __pfx_worker_thread+0x10/0x10<br /> [ 1360.548640] kthread+0x16b/0x1b0<br /> [ 1360.548653] ? __pfx_kthread+0x10/0x10<br /> [ 1360.548665] ret_from_fork+0x2f/0x50<br /> [ 1360.548679] ? __pfx_kthread+0x10/0x10<br /> [ 1360.548690] ret_from_fork_asm+0x1a/0x30<br /> [ 1360.548707] <br /> <br /> [ 1360.548719] Allocated by task 192061:<br /> [ 1360.548726] kasan_save_stack+0x20/0x40<br /> [ 1360.548739] kasan_save_track+0x14/0x30<br /> [ 1360.548750] __kasan_kmalloc+0x8f/0xa0<br /> [ 1360.548760] __kmalloc_node+0x1f1/0x450<br /> [ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables]<br /> [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink]<br /> [ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]<br /> [ 1360.548927] netlink_unicast+0x367/0x4f0<br /> [ 1360.548935] netlink_sendmsg+0x34b/0x610<br /> [ 1360.548944] ____sys_sendmsg+0x4d4/0x510<br /> [ 1360.548953] ___sys_sendmsg+0xc9/0x120<br /> [ 1360.548961] __sys_sendmsg+0xbe/0x140<br /> [ 1360.548971] do_syscall_64+0x55/0x120<br /> [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d<br /> <br /> [ 1360.548994] Freed by task 192222:<br /> [ 1360.548999] kasan_save_stack+0x20/0x40<br /> [ 1360.549009] kasan_save_track+0x14/0x30<br /> [ 1360.549019] kasan_save_free_info+0x3b/0x60<br /> [ 1360.549028] poison_slab_object+0x100/0x180<br /> [ 1360.549036] __kasan_slab_free+0x14/0x30<br /> [ 1360.549042] kfree+0xb6/0x260<br /> [ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables]<br /> [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables]<br /> [ 1360.549221] ops_exit_list+0x50/0xa0<br /> [ 1360.549229] free_exit_list+0x101/0x140<br /> [ 1360.549236] unregister_pernet_operations+0x107/0x160<br /> [ 1360.549245] unregister_pernet_subsys+0x1c/0x30<br /> [ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables]<br /> [ 1360.549345] __do_sys_delete_module+0x253/0x370<br /> [ 1360.549352] do_syscall_64+0x55/0x120<br /> [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d<br /> <br /> (gdb) list *__nft_release_table+0x473<br /> 0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).<br /> 11349 list_for_each_entry_safe(flowtable, nf, &amp;table-&gt;flowtables, list) {<br /> 11350 list_del(&amp;flowtable-&gt;list);<br /> 11351 nft_use_dec(&amp;table-&gt;use);<br /> 11352 nf_tables_flowtable_destroy(flowtable);<br /> 11353 }<br /> 11354 list_for_each_entry_safe(set, ns, &amp;table-&gt;sets, list) {<br /> 11355 list_del(&amp;set-&gt;list);<br /> 11356 nft_use_dec(&amp;table-&gt;use);<br /> 11357 if (set-&gt;flags &amp; (NFT_SET_MAP | NFT_SET_OBJECT))<br /> 11358 nft_map_deactivat<br /> ---truncated---

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.