media: qcom: camss: Cityman 8x94 Hill CCS bringup (WIP) by EpicLPer · Pull Request #1 · EpicLPer/linux

EpicLPer · 2026-08-30T14:39:44Z

Summary

WIP Cityman (Lumia 950 XL / MSM8994) CAMSS + CCS for the rear Hill module (0x0a-eaca / CDCC 0AEACA05). One commit on top of talkman-dsi-20nm-pll. Reviewer ping for @sonic011gamer.

This is not a rebase onto Android4Lumia950 camss / mdss. Those branches share merge-base cc54e0e with this tree, but octagon-camss is ~1252 commits ahead (display + later mainline). A PR onto camss would be unreadable; the camera delta is this tip only.

What is in the commit

MSM8994 CAMSS DT (camss@fda00000) + Cityman Hill on CCI1 rfc_sensor@10, CSIPHY0, 4-lane <0 2 3 4>, MCLK 9.6 MHz
link-frequencies379200000 (WP10 viewfinder SensorMode[11].DDRClk)
VFE 4.6 (camss-vfe-4-6.c), CSID 4.1, 20nm CSIPHY csiphy_ops_2ph_1_0
MMCC CSI clock bits; CCS =y; CCS quirk + prints for SMIA 0x0a-eaca

What works / what does not (testDU, Image `#183`)

CCS binds Hill as 0x0a-eaca
STREAMON of 5344×4016 RAW12 succeeds (MODE_SELECT ok)
CSID sees packets (pkts≈0xc7555) but never forms long packets: ecc=0xffff0000, long=0, MISR 0, hill.raw 0 bytes
CCS set_fmtclamps 2496×1872 SRGGB8 to 5344×4016 SRGGB12 (pipeline EPIPE if you force the WP VF size)
8 bpp is no longer rejected at the CSID/VFE probe after the 379.2 MHz link freq

Do not

Overlay 3.10 smia65pp_crop_vfe or invent analog / FF0B PLL writes
Paste Talkman 0xfd996000 into msm8994.dtsi
Flip Cityman CSIPHY to 3ph, or copy Talkman settle 0x16 onto 20nm
Put CAM_VIO/LVS1 on the CCS vio-supply / power-up at init
Flash boot; living fallback is still the GPU series pack

Test plan

Read the tip commit only (5b25aeb7e722), not the 1252-commit delta vs camss
Compare DCC 0AEACA05 modes: WP VF is RAW8 2496×1872 @ 379.2 MHz; no 5344×4016 RAW12 in the DCC
CSID ECC / long-packet path on 8x94 20nm (why ecc=0xffff0000 with non-zero pkts)

Made with Cursor

Add MSM8994 CAMSS (VFE 4.6, CSID 4.1, 20nm CSIPHY) and a CCS quirk for SMIA 0x0a-eaca. MODE_SELECT streams; CSID still sees packets with ECC and long=0. Link freq is the WP viewfinder 379.2 MHz. Co-authored-by: Cursor <cursoragent@cursor.com>

Our v6.18 based Android system is continuely suffering livelock and bad page stat as shown in[1] which related to broken xarray slot status. By investigating big folio operations within f2fs, we find below races and fix it by get the nr_pages before drop the refcount and folio_lock. f2fs_get_read_data_folio() calls f2fs_folio_put() before folio_nr_pages() when invalidating a large folio from the page cache. That unlocks the folio and drops the caller reference, leaving a window where a concurrent truncate or folio split can shrink the compound folio or free it before the invalidate range is computed. An undersized range then leaves split sub-folios in mapping->i_pages, which can later interact badly with truncate and reclaim (stale xarray entries and bad page state when folio->mapping no longer matches the mapping being truncated). [1] PID: 2594 TASK: ffffff8169b81580 CPU: 7 COMMAND: "Thread-3" #0 [ffffffc08ef2b8a0] xas_load at ffffffe52d1f42a4 #1 [ffffffc08ef2b900] find_get_entries at ffffffe52c185798 Android4Lumia950#2 [ffffffc08ef2bb60] truncate_inode_pages_range at ffffffe52c19e83c Android4Lumia950#3 [ffffffc08ef2bbc0] truncate_inode_pages_final at ffffffe52c19ec2c #4 [ffffffc08ef2bc20] f2fs_evict_inode at ffffffe52c4c8400 #5 [ffffffc08ef2bcc0] evict at ffffffe52c2de9f4 #6 [ffffffc08ef2bd00] iput at ffffffe52c2db1b4 #7 [ffffffc08ef2bd30] dentry_unlink_inode at ffffffe52c2d7204 #8 [ffffffc08ef2bd50] __dentry_kill at ffffffe52c2d3dcc #9 [ffffffc08ef2bd80] dput at ffffffe52c2d3c3c #10 [ffffffc08ef2bda0] __fput at ffffffe52c2b0a7c #11 [ffffffc08ef2bde0] ____fput at ffffffe52c2b1034 #12 [ffffffc08ef2bdf0] task_work_run at ffffffe52beea200 #13 [ffffffc08ef2be20] exit_to_user_mode_loop at ffffffe52bfbc17c #14 [ffffffc08ef2be80] el0_svc at ffffffe52d1f8e54 #15 [ffffffc08ef2beb0] el0t_64_sync_handler at ffffffe52d1f8d10 Cc: stable@kernel.org Fixes: 05e65c1 ("f2fs: support large folio for immutable non-compressed case") Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>

rt6_nh_dump_exceptions() uses hlist_for_each_entry() to iterate over RCU-protected exception lists. The caller holds rcu_read_lock(), but does not hold rt6_exception_lock, so rt6_insert_exception() can concurrently add an entry with hlist_add_head_rcu(). KCSAN reports this race (irrelevant details omitted): ================================================================== BUG: KCSAN: data-race in rt6_insert_exception / rt6_nh_dump_exceptions write (marked) to 0xffff8a7c44c59620 of 8 bytes by interrupt on cpu 5: rt6_insert_exception+0x3bb/0x760 __ip6_rt_update_pmtu+0x4fe/0x750 ip6_sk_update_pmtu+0x19a/0x3b0 udpv6_err+0x3ff/0x800 icmpv6_notify+0x1e1/0x440 icmpv6_rcv+0x8c0/0xab0 ip6_protocol_deliver_rcu+0x616/0x840 ip6_input_finish+0xb9/0x160 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff8a7c44c59620 of 8 bytes by task 549 on cpu 14: rt6_nh_dump_exceptions+0xb3/0x260 rt6_dump_route+0x53e/0x5f0 fib6_dump_node+0x6d/0xf0 fib6_walk_continue+0x290/0x2d0 fib6_dump_table+0x28d/0x360 inet6_dump_fib+0x37d/0x620 rtnl_dumpit+0x7b/0xd0 netlink_dump+0x3ae/0x7e0 ... entry_SYSCALL_64_after_hwframe+0x77/0x7f 4 locks held by dumper/549: ... #1: (rcu_read_lock){....}-{1:3}, at: inet6_dump_fib+0x88/0x620 Android4Lumia950#2: (&tb->tb6_lock){+.-.}-{3:3}, at: fib6_dump_table+0x1e9/0x360 Android4Lumia950#3: (rcu_read_lock){....}-{1:3}, at: rt6_dump_route+0x483/0x5f0 value changed: 0xffff8a7c44e05700 -> 0xffff8a7c45d60100 Reported by Kernel Concurrency Sanitizer on: CPU: 14 UID: 0 PID: 549 Comm: dumper Not tainted 7.2.0-rc7-virtme #38 PREEMPT(lazy) ... Use hlist_for_each_entry_rcu() to safely iterate over the exception list. Fixes: 1e47b48 ("ipv6: Dump route exceptions if requested") Cc: stable@vger.kernel.org Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260815084651.69477-1-sigefriedhyy@gmail.com Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>

…ommands' Tariq Toukan says: ==================== net/mlx5: Preserve speed and state across vport modify commands The firmware vport modify command bundles both admin state and max tx speed in a single operation, which requires each side to preserve the other field when it only intends to change one. When modifying max tx speed, the driver already queries the current admin state and passes it back to avoid overwriting it. However, this query and the subsequent modify were not atomic, a state change between the two could cause the modify to overwrite the new state with a stale value. The fix holds esw->state_lock across the query-modify sequence. When support for setting max tx speed via the vport modify command was introduced, the existing admin state modify path was not updated to preserve the current speed. As a result, the firmware interprets the zero speed field as an intentional reset. The fix adds a speed query before the state modify and passes the result back in the command. To support that, mlx5_query_vport_max_tx_speed() had to be fixed first: it was returning zero whenever the vport was DOWN, which was correct for the query_port_speed verb but would defeat the purpose of querying before a state modify. The DOWN-to-zero logic is moved to the verb-layer caller so the function returns the raw firmware value. Patch #1 holds esw->state_lock across the state query and modify in the speed modify path Patch Android4Lumia950#2 moves the vport DOWN zero mapping to the verb-layer caller so the query returns the raw firmware value Patch Android4Lumia950#3 queries current max tx speed before modifying vport state to preserve it ==================== Link: https://patch.msgid.link/20260816065015.3280733-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>

rt6_multipath_rebalance() calculates the total eligible nexthop weight in one pass and programs upper bounds in a second pass. Since RTM_NEWROUTE is RTNL-free, a concurrent ignore_routes_with_linkdown update can make the first pass return zero while the second sees an eligible nexthop, causing rt6_upper_bound_set() to divide by zero. UBSAN: division-overflow in net/ipv6/route.c:4845:17 Oops: divide error: 0000 [#1] SMP KASAN NOPTI rt6_upper_bound_set() net/ipv6/route.c:4845 rt6_multipath_rebalance() fib6_add_rt2node() ip6_route_multipath_add() inet6_rtm_newroute() Skip upper-bound calculation when the first pass reports a zero total. This respects the lock-free performance considerations here and solves insecure scenarios. Fixes: bd11ff4 ("ipv6: Get rid of RTNL for SIOCDELRT and RTM_DELROUTE.") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Xiang Mei (Microsoft) <xmei5@asu.edu> Reported-by: Cen Zhang (Microsoft) <blbllhy@gmail.com> Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260817013237.2797-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>

…ntries Net drivers request GFP flags according to both the current context and the device constraints, but the XArray entry itself is by no mean used by the device. Passing though device constraints to XArray allocation is a bug and will be warned and fixed up by slab, e.g.: Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0x82820 (GFP_ATOMIC|__GFP_NOWARN|__GFP_NOMEMALLOC). Fix your code! CPU: 2 UID: 0 PID: 1071629 Comm: kworker/u80:1 Not tainted 7.2.0-rc7+ #1 PREEMPT(lazy) Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN27WW 10/20/2025 Workqueue: mt76 mt792x_pm_wake_work [mt792x_lib] Call Trace: <TASK> dump_stack_lvl+0x6e/0x90 kmalloc_fix_flags+0x4d/0x6a refill_objects+0x10a/0x330 __pcs_replace_empty_main+0x292/0x5c0 kmem_cache_alloc_lru_noprof+0x4c2/0x680 ? __xas_nomem+0x3a/0x120 __xas_nomem+0x3a/0x120 __xa_alloc+0xd4/0x190 page_pool_dma_map+0xef/0x400 __page_pool_alloc_netmems_slow+0xed/0x480 ? lock_release+0x280/0x490 page_pool_alloc_frag_netmem+0xe0/0x3a0 page_pool_alloc_frag+0xe/0x20 mt76_dma_rx_fill_buf+0x1f6/0x580 [mt76] mt76_dma_rx_reset+0x1cf/0x230 [mt76] mt792x_wpdma_reset+0x183/0x1b0 [mt792x_lib] mt792x_wpdma_reinit_cond+0x5e/0xa0 [mt792x_lib] mt792xe_mcu_drv_pmctrl+0x28/0x60 [mt792x_lib] mt792x_mcu_drv_pmctrl+0x3e/0x90 [mt792x_lib] mt792x_pm_wake_work+0x2d/0x1d0 [mt792x_lib] ? process_one_work+0x20e/0x600 process_one_work+0x230/0x600 ? process_one_work+0x256/0x600 worker_thread+0x1ec/0x3c0 ? rescuer_thread+0x610/0x610 kthread+0xf2/0x130 ? kthread_affine_node+0x140/0x140 ret_from_fork+0x2a5/0x380 ? kthread_affine_node+0x140/0x140 ret_from_fork_asm+0x11/0x20 </TASK> Currently mt76 and stmmac may allocate page pool pages with GFP_DMA32. Fix it by removing zone/policy GFP flags when allocating XArray entries. This is inspired by commit 96d5780 ("iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()"). Fixes: ee62ce7 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool") Signed-off-by: Rong Zhang <i@rong.moe> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://patch.msgid.link/20260821-page-pool-xa-drop-dma32-v1-1-6eab295c3478@rong.moe Signed-off-by: Jakub Kicinski <kuba@kernel.org>

'uuid_count' member of struct 'discovery_state' is assigned and read without any locks, so there is a chance of situation when uuid_count != 0, but uuids is NULL and there will be NULL pointer dereference. Possible race: 'hci_update_passive_scan_sync' 'hci_discovery_filter_clear' hdev->discovery.uuid_count = 0; <----------------------preempted-----------------------------> 'start_service_discovery' // Set uuid_count to value != 0 hdev->discovery.uuid_count = uuid_count; hdev->discovery.uuids = kmemdup(...); <----------------------preempted-----------------------------> spin_lock(&hdev->discovery.lock); kfree(hdev->discovery.uuids); hdev->discovery.uuids = NULL; spin_unlock(&hdev->discovery.lock); Now uuids == NULL and uuid_count != 0. So 'mgmt_device_found' -> 'is_filter_match' -> 'eir_has_uuids' receives non consistent discovery state, where NULL dereference of uuids happens. To fix it let's add discovery.lock around every read/write of uuid_count, uuids pair of struct members. It is also important to assign uuid_count value only after success kmemdup() allocation in start_service_discovery(), otherwise uuids is NULL, because kmemdup failed, but uuid_count is already assigned to non zero value. The following panic happens: [ ] ------------[ cut here ]------------ [ ] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ ] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP [ ] CPU: 0 PID: 15056 Comm: kworker/u9:2 [ ] Workqueue: hci0 hci_rx_work [ ] pstate: 10400009 (nzcV daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : eir_has_uuids+0x2d8/0x590 [ ] lr : is_filter_match+0x258/0x320 ... [ ] Call trace: [ ] eir_has_uuids+0x2d8/0x590 [ ] is_filter_match+0x258/0x320 [ ] mgmt_device_found+0x5b0/0xafc [ ] process_adv_report.part.0+0x8c8/0xf14 [ ] hci_le_adv_report_evt+0x338/0x3f0 [ ] hci_le_meta_evt+0x1f0/0x4c8 [ ] hci_event_packet+0x440/0xc9c [ ] hci_rx_work+0x44c/0xaf8 [ ] process_one_work+0x54c/0x103c [ ] worker_thread+0x6c4/0x10c4 [ ] kthread+0x274/0x2ec [ ] ret_from_fork+0x10/0x20 [ ] Code: 14000004 91004021 eb14003f 54000180 (f9400024) [ ] ---[ end trace 0000000000000000 ]--- Fixes: 2935e55 ("Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'") Signed-off-by: Pavel Shpakovskiy <pashpakovskii@salutedevices.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

Found with syzkaller and a local syzbot instance running on top of a netdevsim TLS offload emulation; tls_device.c is otherwise only reachable on a machine with a NIC that implements the offload. tls_push_data() only checks whether the open record still has room for another frag at the bottom of its loop, and the MSG_MORE early break skips that check. The record survives to the next syscall with the frag count it already had, and tls_append_frag() does not check either, so with TLS_TX_ZEROCOPY_RO every splice(SPLICE_F_MORE) of a byte or two adds a non-coalescing pipe page and num_frags walks off the end of tls_record_info.frags[MAX_SKB_FRAGS]. Once the record is pushed, tls_push_record() runs the same index over sg_tx_data[MAX_SKB_FRAGS] and the sg_set_page() writes land on the destruct_work that follows it, which the workqueue then calls. The byte limit is fine because copy drops to 0 and the loop falls through to the same check; the frag count has no such feedback. Push the record rather than keep a full one open, which is what a plain TCP socket does - tcp_sendmsg_locked() uses tcp_mark_push() and new_segment in both the copy and the MSG_SPLICE_PAGES paths, and tls_sw already sets full_record when the sk_msg ring fills up, MSG_MORE or not. BUG: KASAN: slab-out-of-bounds in tls_append_frag ( net/tls/tls_device.c:269) Write of size 8 at addr ffff8881104d1530 by task tls_oob/450 CPU: 2 UID: 0 PID: 450 Comm: tls_oob Not tainted 7.2.0-rc7+ #329 PREEMPT Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) tls_append_frag (net/tls/tls_device.c:269) tls_push_data (net/tls/tls_device.c:518) tls_device_sendmsg (net/tls/tls_device.c:583) inet_sendmsg (net/ipv4/af_inet.c:865) sock_sendmsg (net/socket.c:775 net/socket.c:790 net/socket.c:813) splice_to_socket (fs/splice.c:884) do_splice (fs/splice.c:936 fs/splice.c:1349) __do_splice (fs/splice.c:1431) __x64_sys_splice (fs/splice.c:1634 fs/splice.c:1616) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) </TASK> and, once the record is pushed: UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:300:24 index 18 is out of range for type 'skb_frag_t [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:301:41 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:302:39 index 18 is out of range for type 'scatterlist [17]' UBSAN: array-index-out-of-bounds in net/tls/tls_device.c:307:38 index 26 is out of range for type 'scatterlist [17]' kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle page fault for address: ffffea000411a680 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0011) - permissions violation Oops: Oops: 0011 [#1] SMP KASAN PTI Workqueue: ktls_device_destruct 0xffffea000411a680 RIP: 0010:0xffffea000411a680 Call Trace: <TASK> worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) </TASK> Fixes: e8f6979 ("net/tls: Add generic NIC offload infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> Link: https://patch.msgid.link/20260823084758.20936-1-jiayuan.chen@linux.dev Signed-off-by: Paolo Abeni <pabeni@redhat.com>

teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that skb - arp_error_report() on timeout, or neigh_direct_output() -> dev_queue_xmit() once the neighbour resolves - causes a UAF like the one below: BUG: KASAN: slab-use-after-free in __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) Read of size 4 at addr ffff888106e100b0 by task flood_packet/527 CPU: 0 UID: 0 PID: 527 Comm: flood_packet Not tainted 7.2.0-rc6-g594d90519502 #1 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) ? __pfx__raw_spin_lock_irqsave (./include/asm-generic/qrwlock.h:122 (discriminator 4)) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) kasan_report (mm/kasan/report.c:595) ? __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) __icmp_send (net/ipv4/icmp.c:914 (discriminator 2)) [...] ipv4_link_failure (net/ipv4/route.c:1251 net/ipv4/route.c:1258) ? __pfx_ipv4_link_failure (./include/linux/skbuff.h:4327) ? _raw_write_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:1301 ./include/asm-generic/qrwlock.h:98 ./include/linux/rwlock_api_smp.h:230 kernel/locking/spinlock.c:304) ? __pfx__raw_write_lock (kernel/locking/spinlock.c:175) arp_error_report (./include/net/dst.h:438 net/ipv4/arp.c:296) neigh_invalidate (net/core/neighbour.c:1077) neigh_timer_handler (net/core/neighbour.c:1169) [...] Allocated by task 505: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) __kvmalloc_node_noprof (./include/linux/kasan.h:263 mm/slub.c:5334 mm/slub.c:6905) alloc_netdev_mqs (net/core/dev.c:12055 (discriminator 2)) rtnl_create_link (net/core/rtnetlink.c:3721) rtnl_newlink (net/core/rtnetlink.c:3903 net/core/rtnetlink.c:4044 net/core/rtnetlink.c:4159) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Freed by task 536: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2677 mm/slub.c:6377 mm/slub.c:6692) device_release (drivers/base/core.c:2636) kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737) netdev_run_todo (net/core/dev.c:11756) rtnl_dellink (net/core/rtnetlink.c:157 ./include/linux/rtnetlink.h:135 net/core/rtnetlink.c:3651) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) [...] Fix this by restoring skb->dev to the master at the end of each slave's iteration. Fixes: 0cc0c2e ("net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit") Reported-by: Vega <vega@nebusec.ai> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260824115928.4099988-1-victor@mojatatu.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>

The `rustc-dev` components for Rust 1.82.0 through 1.87.0 include a precompiled `zerocopy_derive` procedural macro in the sysroot. This range includes Rust 1.85.0, our minimum supported version. This makes `rusttest` fail because the compiler finds both the sysroot copy and the copy built in `rust/test`: error[E0464]: multiple candidates for `dylib` dependency `zerocopy_derive` found --> rust/kernel/prelude.rs:70:9 | 70 | pub use zerocopy_derive::{ | ^^^^^^^^^^^^^^^ | = note: candidate #1: .../lib/rustlib/x86_64-unknown-linux-gnu/lib/libzerocopy_derive-54d2b38896fa6bc5.so = note: candidate Android4Lumia950#2: .../rust/test/libzerocopy_derive.so Commit fe39a23 ("rust: kbuild: disambiguate `zerocopy` for `rusttest`") fixed the equivalent ambiguity for `zerocopy`. Thus point to the dependency explicitly in this case too. Cc: Antoni Boucher <bouanto@zoho.com> Cc: stable@vger.kernel.org Fixes: 5060549 ("rust: zerocopy-derive: enable support in kbuild") Link: https://patch.msgid.link/20260823193529.156066-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Since the RX path was converted to zero-copy, the page pool page is handed to the stack directly as the skb head, and the offset the DMA engine writes at is what determines the alignment of the packet headers. Before the conversion the payload was copied into an skb obtained from napi_alloc_skb(), which reserves NET_SKB_PAD + NET_IP_ALIGN. The conversion moved the headroom into stmmac_rx_offset() but did not carry over NET_IP_ALIGN, so on architectures where NET_IP_ALIGN is 2 the IP header now lands misaligned: 64 (NET_SKB_PAD) + 14 (ethernet) + 20 (IP) = 98 Same for the XDP branch: 256 (XDP_PACKET_HEADROOM) + 14 (ethernet) + 20 (IP) = 290 On ARM32 this is fatal, because ldm and ldrd trap on unaligned addresses even when CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set. Any received echo request panics the machine, e.g: Unhandled fault: alignment exception (0x001) at 0x81873062 Internal error: : 1 [#1] SMP ARM Hardware name: Altera SOCFPGA Arria10 PC is at icmp_echo+0x38/0xa8 LR is at icmp_rcv+0x22c/0x370 Call trace: icmp_echo from icmp_rcv+0x22c/0x370 icmp_rcv from ip_protocol_deliver_rcu+0x2c/0x224 ip_protocol_deliver_rcu from ip_local_deliver+0xc8/0x1a0 ip_local_deliver from ip_sublist_rcv_finish+0x3c/0x50 ip_sublist_rcv_finish from ip_list_rcv_finish+0x110/0x118 ip_list_rcv_finish from ip_list_rcv+0xc8/0xdc ip_list_rcv from __netif_receive_skb_list_core+0x170/0x1c0 ... napi_complete_done from stmmac_napi_poll_rx+0xcb0/0x1030 Code: e24dd068 e59020a0 e28dc010 e0822001 (e8920003) Kernel panic - not syncing: Fatal exception in interrupt The faulting instruction is the ldm of *icmp_hdr(skb) in icmp_echo(). Fix by adding NET_IP_ALIGN back to the RX offset, which restores the alignment the stack used to get. Note that commit a955318 ("stmmac: align RX buffers") made a similar change in 2021 and was reverted by commit 12d125b ("stmmac: Revert "stmmac: align RX buffers"") because it caused packet corruption. That patch raised the offset from 0 without adjusting the buffer size accounting, so the DMA engine could arguably write past the end of the RX buffers, though this was never root caused. Commit df542f6 ("net: stmmac: Switch to zero-copy in non-XDP RX path") since derives the page pool allocation from stmmac_rx_offset(), so the extra bytes are accounted for. Fixes: df542f6 ("net: stmmac: Switch to zero-copy in non-XDP RX path") Cc: Daniel Baldin <DBaldin@dspace.de> Signed-off-by: Pascal Kneuper <PKneuper@dspace.de> Link: https://patch.msgid.link/20260824125014.47862-1-PKneuper@dspace.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>

A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ Android4Lumia950#2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: <TASK> __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 </TASK> Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb1 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list") and by commit 9e4b7a9 ("net: gso: fix panic on frag_list with mixed head alloc types") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c ("tun: Allow GSO using virtio_net_hdr"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged. Fixes: f43798c ("tun: Allow GSO using virtio_net_hdr") Cc: stable@kernel.org Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Xinyang Ge <xinyang@anthropic.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/937926e509f2acd8e0e66520dc2b30fd6b4d1687.1787839506.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>

EpicLPer · 2026-08-30T14:39:44Z