)]}' { "log": [ { "commit": "647b81ddefc6364290e67bf33c89d54971f8995e", "tree": "a38fd39ef780b1828152746baa11bddd6a936bec", "parents": [ "7b1fd973214de07b83468a1363856f048aa2d80a" ], "author": { "name": "Kyle Zeng", "email": "kylebot@openai.com", "time": "Fri Oct 30 08:58:43 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 15:43:22 2026 +0100" }, "message": "tcp: wait for TIME_WAIT teardown before freeing per-netns ehash\n\ninet_twsk_kill() removes a TIME_WAIT socket from the established hash\nbefore it finishes using the ehash lock, hashinfo and bind tables, and\nbefore it drops the death-row reference. A running timer can therefore\nunhash its socket before inet_twsk_purge() reaches it. The purge cannot\nsynchronize with that timer, and tcp_sk_exit_batch() can free the\nprivate ehash and hashinfo while inet_twsk_kill() is still using them.\n\nAn unprivileged reproducer using user and network namespaces, a private\nTCP ehash and a FIN_WAIT2 timer triggers a KASAN slab-use-after-free in\ninet_twsk_kill(). The allocation and free stacks point to\ninet_pernet_hashinfo_alloc() and inet_pernet_hashinfo_free().\n\nWait for an RCU grace period after purging the whole batch, if one\nnetns in the batch uses a private ehash. TIME_WAIT removal runs with\nbottom halves disabled, so this also waits for removers that were\nalready invisible to the purge. Keep the wait under\ntcp_exit_batch_mutex, before freeing any private hashinfo.\n\nThe same window exists with the shared tcp_hashinfo. There, the\nhashinfo memory stays valid, but tcp_sk_exit_batch() can decrement\ntcp_death_row.tw_refcount from 2 to 1 before inet_twsk_kill() drops its\nown reference. This triggers the WARN_ON_ONCE() in tcp_sk_exit_batch(),\nthen a refcount_t \"decrement hit 0\" warning from inet_twsk_kill().\n\nAdding a grace period for the shared case would be costly on busy\nhosts. It is not needed: struct net is freed by a later cleanup_net(),\nafter the synchronize_rcu() in ops_undo_list(), so inet_twsk_kill()\ncan safely drop the last tw_refcount reference itself.\nUse refcount_dec_if_one() and only warn if tw_refcount is not 1\nafter a grace period.\n\nFixes: d1e5e6408b30 (\"tcp: Introduce optional per-netns ehash.\")\nSigned-off-by: Kyle Zeng \u003ckylebot@openai.com\u003e\n[edumazet: only call synchronize_net() if one netns in the batch uses a private ehash,\n use refcount_dec_if_one() to avoid a false WARN with the shared ehash]\nSigned-off-by: Eric Dumazet \u003cedumazet@kernel.org\u003e\nReviewed-by: Jiayuan Chen \u003cjiayuan.chen@linux.dev\u003e\nReviewed-by: Kuniyuki Iwashima \u003ckuniyu@google.com\u003e\nLink: https://patch.msgid.link/20261030075843.2567707-1-edumazet@kernel.org\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "7b1fd973214de07b83468a1363856f048aa2d80a", "tree": "9050eac7b7c4d89a77a37accc09c75ea6e0338f7", "parents": [ "c0ef6144b4d60afb90bc6d8db3ffdac043cd6ffc", "5b5d8f351dd96f56a58bb516a80e2d4d742fe4e2" ], "author": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 15:33:15 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 15:33:16 2026 +0100" }, "message": "Merge branch \u0027inet-fix-lockless-ehash-walk-races\u0027\n\nHyunwoo Kim says:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\ninet: fix lockless ehash walk races\n\nFix two issues in lockless ehash walks. Reject unhashed sockets after\ntaking a reference in established lookups, and restore the acquire/release\nordering around refcount publication and acquisition.\n\nv4: https://lore.kernel.org/r/20261026003804.61923-1-imv4bel@gmail.com\nv3: https://lore.kernel.org/r/20261024053720.1147022-1-imv4bel@gmail.com\nv2: https://lore.kernel.org/r/20261023052542.3505250-1-imv4bel@gmail.com\nv1: https://lore.kernel.org/r/ath58Egc-oI6p3Jl@v4bel\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nLink: https://patch.msgid.link/20261029214219.1035176-1-imv4bel@gmail.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "5b5d8f351dd96f56a58bb516a80e2d4d742fe4e2", "tree": "9050eac7b7c4d89a77a37accc09c75ea6e0338f7", "parents": [ "4e2b3ef19e0e04adca38442f07dd6bc93c712bf1" ], "author": { "name": "Hyunwoo Kim", "email": "imv4bel@gmail.com", "time": "Fri Oct 30 06:42:17 2026 +0900" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 15:33:13 2026 +0100" }, "message": "net: restore refcount ordering for lockless socket access\n\nBefore commit fb041bb7c0a9 (\"locking/refcount: Consolidate implementations\nof refcount_t\"), default builds implemented refcount_inc_not_zero() using\natomic_add_unless(), which provided full memory ordering on success. The\ncommit removed that ordering on weakly ordered architectures, allowing\naccesses after a successful reference acquisition to be reordered before\nit.\n\nUse refcount_inc_not_zero_acquire() in the IPv4 and IPv6 established\nlookups and in inet_twsk_purge(), where the socket is validated again\nafter taking a reference.\n\nbpf_sk_assign() can receive a socket pointer obtained through BTF\nwithout a reference. Use acquire ordering when it takes its own reference\nfor a refcounted socket.\n\nUse refcount_set_release() when setting refcounts in the SYN cookie,\nTCP Fast Open, request migration, and TIME_WAIT paths. Keep the existing\nTIME_WAIT smp_wmb(), which separately orders the refcount store before\nehash publication.\n\nFixes: fb041bb7c0a9 (\"locking/refcount: Consolidate implementations of refcount_t\")\nFixes: 27e5203bd9c5 (\"bpf: Change bpf_sk_assign to accept ARG_PTR_TO_BTF_ID_SOCK_COMMON\")\nCc: stable@vger.kernel.org\nSigned-off-by: Hyunwoo Kim \u003cimv4bel@gmail.com\u003e\nReviewed-by: Kuniyuki Iwashima \u003ckuniyu@google.com\u003e\nLink: https://patch.msgid.link/20261029214219.1035176-3-imv4bel@gmail.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "4e2b3ef19e0e04adca38442f07dd6bc93c712bf1", "tree": "517a022f7f50629d3da508e15f705c6def391cb7", "parents": [ "c0ef6144b4d60afb90bc6d8db3ffdac043cd6ffc" ], "author": { "name": "Hyunwoo Kim", "email": "imv4bel@gmail.com", "time": "Fri Oct 30 06:42:16 2026 +0900" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 15:33:13 2026 +0100" }, "message": "inet: reject unhashed sockets during established lookups\n\nTCP established ehash lookups are lockless. The socket caches involved\nuse SLAB_TYPESAFE_BY_RCU, so memory can be reused before an RCU reader\nthat retained its old address has finished.\n\nAfter a tuple match, __inet_lookup_established() and\n__inet6_lookup_established() acquire a reference and repeat the tuple\ncheck. They do not check whether the new object is hashed. If the\naddress is reused for a socket with the same tuple, the lookup can\nacquire a reference to the new object and return it while its nulls node\nis unhashed.\n\nA PoC that drives reuse with a SYN cookie request socket reproduced the\ncrash. The new request socket is unhashed and has a NULL rsk_listener.\nA lookup that had loaded the address of the old request socket acquired\nthe reference published by tcp_get_cookie_sock() and returned the new\nobject. tcp_v4_rcv() then read sk_state through the NULL listener.\n\nThe resulting crash was:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000012\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n ...\n Oops: Oops: 0000 [#1] SMP NOPTI\n CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 7.3.0-00591-g0e135910deec #1 PREEMPT(lazy)\n ...\n RIP: 0010:tcp_v4_rcv+0x44e/0x1280\n ...\n R10: 0000000000000001 R11: 00000000024ca8c0 R12: 0000000000000000\n ...\n CR2: 0000000000000012 CR3: 0000000103d50004 CR4: 0000000000770ef0\n ...\n Call Trace:\n \u003cIRQ\u003e\n ? raw_local_deliver+0xae/0x240\n ip_protocol_deliver_rcu+0x2d/0x180\n ip_local_deliver_finish+0x84/0x100\n ip_sublist_rcv_finish+0x5f/0x70\n ip_sublist_rcv+0x12a/0x1d0\n ip_list_rcv+0xfd/0x130\n __netif_receive_skb_list_core+0x223/0x250\n netif_receive_skb_list_internal+0x1d2/0x2c0\n ? try_fill_recv+0x39/0x7b0\n napi_complete_done+0x74/0x170\n virtnet_poll+0x445/0x600\n __napi_poll+0x27/0x1e0\n net_rx_action+0x2fe/0x3b0\n handle_softirqs+0xc2/0x2c0\n __irq_exit_rcu+0x74/0xd0\n common_interrupt+0x7f/0x90\n \u003c/IRQ\u003e\n ...\n Kernel panic - not syncing: Fatal exception in interrupt\n\nAfter taking a reference, check whether the nulls node is unhashed in\nboth IPv4 and IPv6 established lookups. If it is unhashed or the tuple\nno longer matches, drop the reference and restart the lookup.\n\nLookups racing with the TIME_WAIT hashdance, or with a request being\nreplaced by its child, now restart and find the new socket instead of\nreturning the old one.\n\nRequest sockets that were never inserted into ehash can have a nonzero\nrefcount, and a stale lookup can hold a transient reference. Therefore,\nwhen SYN cookie, Fast Open, and request migration paths fail after\nsetting a nonzero refcount, release the references held by those paths\nwith reqsk_put() instead of freeing the request directly.\n\nFixes: 079096f103fa (\"tcp/dccp: install syn_recv requests into ehash table\")\nCc: stable@vger.kernel.org\nSigned-off-by: Hyunwoo Kim \u003cimv4bel@gmail.com\u003e\nReviewed-by: Eric Dumazet \u003cedumazet@kernel.org\u003e\nReviewed-by: Kuniyuki Iwashima \u003ckuniyu@google.com\u003e\nLink: https://patch.msgid.link/20261029214219.1035176-2-imv4bel@gmail.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "c0ef6144b4d60afb90bc6d8db3ffdac043cd6ffc", "tree": "739ef2689a982d154f2a1ce9536180c4e7043650", "parents": [ "b3427f41f831adecc8ffd89afc9d30c279115658" ], "author": { "name": "Nguyen Dinh Phi", "email": "phind.uet@gmail.com", "time": "Fri Oct 30 14:43:50 2026 +0800" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 15:10:57 2026 +0100" }, "message": "vsock: reject negative tv_usec in SO_VM_SOCKETS_CONNECT_TIMEOUT\n\nThe timeval validation checks tv_usec \u003c USEC_PER_SEC but not\ntv_usec \u003e\u003d 0, so a negative tv_usec makes the timeout computation\nwrap into a bogus value, later tripping \"schedule_timeout: wrong\ntimeout value\" instead of being rejected.\n\nFixes: d021c344051a (\"VSOCK: Introduce VM Sockets\")\nSigned-off-by: Nguyen Dinh Phi \u003cphind.uet@gmail.com\u003e\nReviewed-by: Stefano Garzarella \u003csgarzare@redhat.com\u003e\nReviewed-by: Bobby Eshleman \u003cbobbyeshleman@meta.com\u003e\nLink: https://patch.msgid.link/20261030064428.73930-1-phind.uet@gmail.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "b3427f41f831adecc8ffd89afc9d30c279115658", "tree": "f1d2e9533c991c70849d5d573f42b0a69ac9392f", "parents": [ "03d36763291edfb285f08185f4ffda83360ba7ee", "5def91015ba7b59de62a81384572da7281b8a033" ], "author": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 13:20:10 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 13:20:11 2026 +0100" }, "message": "Merge tag \u0027ipsec-2026-11-02\u0027 of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec\n\nSteffen Klassert says:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\npull request (net): ipsec 2026-11-02\n\n1) xfrm: retry inexact policy lookup after node reinsertion\n Detect a concurrent change of the inexact policy tree while it is\n searched and retry the lookup, so an insertion can\u0027t make it return\n the wrong policy.\n\n2) xfrm: interface: validate the IP header on xmit\n Validate the IP header in xfrmi_xmit() like the IP receive path\n does, so packets injected into an xfrm interface can\u0027t reach the\n output path with a malformed header.\n\n3) xfrm: zero-initialise km_event in the replay-notify path\n Zero-initialise the replay event so the netlink header of a\n kernel-originated replay notification no longer carries\n uninitialised stack values.\n\n4) xfrm: espintcp: reorder operations within espintcp_init_sk\n Publish the ESP-in-TCP context before installing the socket\n callbacks, so an early callback can\u0027t dereference a context that\n isn\u0027t set up yet.\n\n5) xfrm: state: reject mark with bits outside its mask on add\n Reject a mark with bits outside its mask on state insert instead\n of silently truncating it, so a lookup can\u0027t be given a mark that\n never matches.\n\n6) xfrm: state: reject mark with bits outside its mask on ALLOCSPI\n Apply the same mark validation to ALLOCSPI, keeping the state and\n policy insert paths consistent.\n\n7) xfrm: policy: reject mark with bits outside its mask on add\n Apply the same mark validation to policy insert, so a policy can\u0027t\n be stored with a mark that never matches.\n\n8) xfrm: state: exact mark/mask match for SPI-keyed control-plane SA lookups\n Match mark and mask exactly in the SPI-keyed netlink SA lookups, so\n a catch-all SA can no longer shadow a more specific one.\n\n9) xfrm: fix use-after-free of migrated state in xfrm_do_migrate_state()\n Hold the cloned state for the whole migration, so a concurrent\n delete can\u0027t free it while it is still in use.\n\n10) xfrm: fix hw offload state leak on xfrm_do_migrate_state() error path\n Remove the hardware offload of the cloned state on the migration\n error path, so the offloaded SA entry isn\u0027t leaked.\n\n11) xfrm: include mark in MIGRATE_STATE SA collision check\n Include the mark in the SA collision check, so a migration that\n only changes the mark can\u0027t install a duplicate SA tuple.\n\n12) xfrm: pass extack through to xfrm_init_replay() from xfrm_init_state()\n Pass the extack to xfrm_init_replay(), so replay window errors can\n be reported to userspace.\n\n13) docs: xfrm: include mark in XFRM_MSG_MIGRATE_STATE EEXIST tuple\n Document the mark as part of the EEXIST tuple of the SA migration\n request.\n\n14) xfrm4: use a full socket for local errors\n Resolve the socket owner with skb_to_full_sk() in the IPv4 local\n error path, so a TCP request socket isn\u0027t used as a full socket.\n\nPlease pull or let me know if there are problems.\n\nipsec-2026-11-02\n\n* tag \u0027ipsec-2026-11-02\u0027 of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec:\n xfrm4: use a full socket for local errors\n docs: xfrm: include mark in XFRM_MSG_MIGRATE_STATE EEXIST tuple\n xfrm: pass extack through to xfrm_init_replay() from xfrm_init_state()\n xfrm: include mark in MIGRATE_STATE SA collision check\n xfrm: fix hw offload state leak on xfrm_do_migrate_state() error path\n xfrm: fix use-after-free of migrated state in xfrm_do_migrate_state()\n xfrm: state: exact mark/mask match for SPI-keyed control-plane SA lookups\n xfrm: policy: reject mark with bits outside its mask on add\n xfrm: state: reject mark with bits outside its mask on ALLOCSPI\n xfrm: state: reject mark with bits outside its mask on add\n xfrm: espintcp: reorder operations within espintcp_init_sk\n xfrm: zero-initialise km_event in the replay-notify path\n xfrm: interface: validate the IP header on xmit\n xfrm: retry inexact policy lookup after node reinsertion\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nLink: https://patch.msgid.link/20261102100451.2505200-1-steffen.klassert@secunet.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "03d36763291edfb285f08185f4ffda83360ba7ee", "tree": "951baad8b6b8126947efa8c1cfe685857ddac340", "parents": [ "f56daaadfecae1f760d0fb34385b256d3af68970", "60b10121db602a43ada3dbc39792bbf93d25991b" ], "author": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 13:01:24 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 13:01:25 2026 +0100" }, "message": "Merge tag \u0027for-net-2026-11-02\u0027 of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth\n\nLuiz Augusto von Dentz says:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nbluetooth pull request for net:\n\nCore:\n\n - hci_core: Initialize IRK before publication\n - hci_core: Initialize link key before publication\n - hci_core: Initialize LTK before publication\n - hci_core: Fix queuing rx_work while workqueue is drained\n - hci_core: Keep link-key filtering inside RCU\n - hci_core: Initialize advertising RPA work only once\n - hci_sync: Fix invalid Supervision_Timeout in LE Set Default Rate\n - hci_sync: re-enable legacy advertising on resume\n - hci_sync: pause advertising for the scan address update\n - hci_sync: Update the CIS host feature when enabling LE\n - hci_sync: Copy the LE accept list under hdev-\u003elock\n - hci_sync: Protect resolving-list lookups\n - hci_sync: Copy the resolving-list IRK under RCU\n - hci_event: Clear explicit connect state on LE connection\n - L2CAP: Hold incoming data until encryption key size is known\n - L2CAP: Ignore connection responses with wrong ident\n - SMP: Protect link keys during LTK derivation\n - SMP: Protect LTK encryption with RCU\n - MGMT: Return RFKILLED for Set Powered on a blocked controller\n - MGMT: Clear disabled connection parameters when loading none\n - MGMT: Fix discovery stuck after a failed Stop Discovery\n - validate retained LE Create CIS command length\n - validate retained LE Set CIG Parameters command length\n\nDrivers:\n\n - btintel: fix buffer over-read in fw payload\n - btmtk: drop zero-length ISO packets from endpoint padding\n - btmtk: bound the ISO payload length by the controller\u0027s MTU\n - btmtk: derive the firmware ISO setting from MTK_ISO_THRESHOLD\n - btmtk: fix error handling in btmtk_usb_isointf_init()\n - qca: Fix the WCN3950 NVM baud rate offset\n\n* tag \u0027for-net-2026-11-02\u0027 of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: (30 commits)\n Bluetooth: MGMT: Fix discovery stuck after a failed Stop Discovery\n Bluetooth: validate retained LE Set CIG Parameters command length\n Bluetooth: validate retained LE Create CIS command length\n Bluetooth: hci_core: Initialize advertising RPA work only once\n Bluetooth: L2CAP: Ignore connection responses with wrong ident\n Bluetooth: MGMT: Clear disabled connection parameters when loading none\n Bluetooth: hci_sync: Copy the resolving-list IRK under RCU\n Bluetooth: SMP: Protect LTK encryption with RCU\n Bluetooth: SMP: Protect link keys during LTK derivation\n Bluetooth: hci_core: Keep link-key filtering inside RCU\n Bluetooth: btmtk: fix error handling in btmtk_usb_isointf_init()\n Bluetooth: qca: Fix the WCN3950 NVM baud rate offset\n Bluetooth: MGMT: Return RFKILLED for Set Powered on a blocked controller\n Bluetooth: hci_sync: Protect resolving-list lookups\n Bluetooth: hci_sync: Copy the LE accept list under hdev-\u003elock\n Bluetooth: btmtk: derive the firmware ISO setting from MTK_ISO_THRESHOLD\n Bluetooth: btmtk: bound the ISO payload length by the controller\u0027s MTU\n Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding\n Bluetooth: hci_sync: Update the CIS host feature when enabling LE\n Bluetooth: L2CAP: Hold incoming data until encryption key size is known\n ...\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nLink: https://patch.msgid.link/20261102222018.2610820-1-luiz.dentz@gmail.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "f56daaadfecae1f760d0fb34385b256d3af68970", "tree": "bac23c1ece362c53f96f4f927c3e3fcb461e7f8a", "parents": [ "64e45ed926cdd017c9816c8006d9117a7194c7e9" ], "author": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Thu Oct 29 08:34:58 2026 -0700" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 12:54:03 2026 +0100" }, "message": "docs: netdev: try to force agents to disclose info for fixes\n\n\"LLM-driven-developers\" are not including the info about discovery\nmethod we want to see in commit messages. Try to add more forceful\nlanguage to make agents ask for it. claude and codex seem to load\nmaintainer-netdev.rst already.\n\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\nReviewed-by: Nicolai Buchwitz \u003cnb@tipi-net.de\u003e\nLink: https://patch.msgid.link/20261029153459.2257998-1-kuba@kernel.org\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "64e45ed926cdd017c9816c8006d9117a7194c7e9", "tree": "61b3f332c3210a9153e807a7731c0dc413d32a6b", "parents": [ "2e54b3e187300893688c2c7517894f5d96732e05" ], "author": { "name": "Eric Dumazet", "email": "edumazet@kernel.org", "time": "Fri Oct 30 09:33:58 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 12:29:21 2026 +0100" }, "message": "xfrm: iptfs: fix skb leak on error in __input_process_payload()\n\nsyzbot reported a memory leak of the received skb (and its sec_path\nextension) in the IP-TFS receive path.\n\n__input_process_payload() parses the inner packets of an IP-TFS payload\nand queues them on @sublist, which is only sent after the parsing loop.\nThree error paths inside the loop (skb_copy_seq_read() failure, invalid\ninner IPv4 header length, unknown IP version) jump to the \"done\" label,\nwhich is placed after the code sending @sublist.\n\nAny skb already queued on @sublist is then neither delivered nor freed.\nThis includes skbs added by iptfs_reassem_cont() before the call, newly\nallocated inner packets, and, since the received skb can be reused for\nthe first inner packet, the received skb itself.\n\nMove the \"done\" label before the trim/send code, so that inner packets\nparsed before the error are delivered as on the normal exit path. The\nreceived skb is then still freed (or consumed) as before when it was\nnot reused.\n\nFixes: 6c82d2433671 (\"xfrm: iptfs: add basic receive packet (tunnel egress) handling\")\nReported-by: syzbot+a3f21220cbbb6e14ee2e@syzkaller.appspotmail.com\nCloses: https://lore.kernel.org/netdev/6ae4102e.9c6421ad.36baac.0005.GAE@google.com/\nSigned-off-by: Eric Dumazet \u003cedumazet@kernel.org\u003e\nAcked-by: Steffen Klassert \u003csteffen.klassert@secunet.com\u003e\nLink: https://patch.msgid.link/20261030083358.2653599-1-edumazet@kernel.org\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "2e54b3e187300893688c2c7517894f5d96732e05", "tree": "291a0016450491c30aa5d0ba9a064cd89982942a", "parents": [ "213d491308b99d026514c93980cf8dd572226b1b" ], "author": { "name": "Kyle Zeng", "email": "kylebot@openai.com", "time": "Thu Oct 29 14:09:57 2026 -0400" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 11:04:43 2026 +0100" }, "message": "net/sched: sch_qfq: prevent aggregate self-replacement\n\nqfq_change_class() snapshots the current aggregate settings while\nholding the qdisc tree lock, but drops the lock before selecting the\ndestination aggregate. During that gap, qfq_enqueue() can move the\nclass to an aggregate matching the requested settings.\n\nWhen qfq_change_class() resumes, qfq_find_agg() then returns cl-\u003eagg.\nIf it is a singleton, qfq_deact_rm_from_agg() frees the aggregate\nbefore qfq_add_to_agg() immediately accesses the same pointer, causing\na use-after-free.\n\nWhile holding the tree lock, skip the replacement when the destination\nis already the current aggregate. Any estimator replacement has already\ncompleted, so the class change can finish normally.\n\nFixes: 462dbc9101ac (\"pkt_sched: QFQ Plus: fair-queueing service at DRR cost\")\nLink: https://lore.kernel.org/netdev/20260731140533.566493-1-david.lee@trailofbits.com/\nCc: stable@vger.kernel.org\nSigned-off-by: Kyle Zeng \u003ckylebot@openai.com\u003e\nCo-developed-by: David Lee \u003cdavid.lee@trailofbits.com\u003e\nSigned-off-by: David Lee \u003cdavid.lee@trailofbits.com\u003e\nLink: https://patch.msgid.link/20261029180957.43015-1-david.lee@trailofbits.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "213d491308b99d026514c93980cf8dd572226b1b", "tree": "f086a648b652664b1a2eb50a74acf32ad65dbaee", "parents": [ "c8848b2ca6e6620b56afafba7dd4367e98b049c0" ], "author": { "name": "Eric Dumazet", "email": "edumazet@kernel.org", "time": "Fri Oct 30 13:09:56 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 10:43:06 2026 +0100" }, "message": "soreuseport: annotate data-races around reuse-\u003esocks[] and num_socks\n\nreuseport_select_sock() and reuseport_migrate_sock() read\nreuse-\u003enum_socks and reuse-\u003esocks[] locklessly under RCU, while\nwriters holding reuseport_lock can change them.\n\nReaders snapshot num_socks once, then index socks[] with it.\nMeanwhile, writers can perform several operations, storing into\nslots below the reader\u0027s stale count:\n\n- __reuseport_detach_sock() moves the last socket into slot i.\n- __reuseport_add_sock() then writes the new socket at the\n (now smaller) num_socks index.\n- reuseport_stop_listen_sock() calls __reuseport_detach_sock()\n then __reuseport_add_closed_sock(), which writes slot\n max_socks - num_closed_socks - 1. This can be the slot a reader\n still considers part of the listener region when the array is full.\n- __reuseport_detach_closed_sock() can then rewrite that slot.\n\nAll pointers stored in socks[] remain valid for the RCU grace period,\nbut without annotations the compiler is allowed to tear or reload\nthese accesses. For instance, reuseport_select_sock_by_hash() could\nreload reuse-\u003esocks[i] between the sk_state/sk_incoming_cpu checks\nand the return, returning a socket that did not pass them.\n\nUse WRITE_ONCE() for all socks[] stores done while the array is\nvisible to readers, and for num_socks updates (readers already use\nREAD_ONCE()). Use READ_ONCE() in the two lockless readers.\n\nFixes: ef456144da8e (\"soreuseport: define reuseport groups\")\nLink: https://lore.kernel.org/netdev/20260902071900.395567-1-ruanjinjie@huawei.com/\nCc: Kuniyuki Iwashima \u003ckuniyu@google.com\u003e\nSigned-off-by: Eric Dumazet \u003cedumazet@kernel.org\u003e\nReviewed-by: Kuniyuki Iwashima \u003ckuniyu@google.com\u003e\nReviewed-by: Jiayuan Chen \u003cjiayuan.chen@linux.dev\u003e\nLink: https://patch.msgid.link/20261030120956.3026324-1-edumazet@kernel.org\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "c8848b2ca6e6620b56afafba7dd4367e98b049c0", "tree": "062f341601203a7e1e45678b24e934a8922f3dd7", "parents": [ "750eb5ab457e62e221a9c8521e2274f14c85b387" ], "author": { "name": "Björn Töpel", "email": "bjorn@kernel.org", "time": "Fri Oct 30 15:14:50 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 10:30:25 2026 +0100" }, "message": "eth: fbnic: Report the logical RX queue to XDP\n\nfbnic reports queue 0 to XDP on all RX queues. The XDP RX queue is\nregistered with the header buffer queue index, which is always 0,\ninstead of the completion queue index, which is the netdev queue id.\n\nAny XDP program that reads rx_queue_index gets 0 on every queue, so a\nprogram that uses the queue id uses the wrong queue. AF_XDP has the\nsame problem: XSKMAP finds the wrong socket, and redirect to a socket\non another queue fails.\n\nTriggered on fbnic hardware (50G, firmware 25.08.05-004) with AF_XDP\nzero-copy: sockets on queues other than 0 got no packets. With this\nfix, a socket on queue 43, and sockets on four queues at once, get\ntheir packets. On the QEMU model with two queues, a kprobe shows 0 and\n0 before the fix, and 0 and 1 after it.\n\nFixes: 894d4a4ea6cb (\"eth: fbnic: move xdp_rxq_info_reg() to resource alloc\")\nSigned-off-by: Björn Töpel \u003cbjorn@kernel.org\u003e\nReviewed-by: Simon Horman \u003chorms@kernel.org\u003e\nLink: https://patch.msgid.link/20261030141452.1173282-1-bjorn@kernel.org\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "750eb5ab457e62e221a9c8521e2274f14c85b387", "tree": "05f66b675cfb3a4e7b46c2eb59e56a7a9a09e046", "parents": [ "684603842b78f75835d21fdf5c19ae717ed8eb1a" ], "author": { "name": "Bart Van Assche", "email": "bvanassche@acm.org", "time": "Thu Oct 29 11:00:39 2026 -0700" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 09:57:58 2026 +0100" }, "message": "mctp i3c: Fix locking in an error path\n\nIf netdev_alloc_skb() fails, mctp_i3c_read() jumps to a label that\nunlocks mi-\u003elock although that mutex has not been locked yet. Fix this\nby returning -ENOMEM directly. This bug has been detected by the Clang\nthread-safety analyzer.\n\nCc: Leo Yang \u003cLeo-Yang@quantatw.com\u003e\nCc: Paolo Abeni \u003cpabeni@redhat.com\u003e\nCc: Jeremy Kerr \u003cjk@codeconstruct.com.au\u003e\nCc: Matt Johnston \u003cmatt@codeconstruct.com.au\u003e\nCc: netdev@vger.kernel.org\nFixes: 2d2d4f60ed26 (\"mctp i3c: fix MCTP I3C driver multi-thread issue\")\nSigned-off-by: Bart Van Assche \u003cbvanassche@acm.org\u003e\nAcked-by: Matt Johnston \u003cmatt@codeconstruct.com.au\u003e\nLink: https://patch.msgid.link/71e0a880ffe7a83237e501b07884bf54343e76ca.1793296780.git.bvanassche@acm.org\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "684603842b78f75835d21fdf5c19ae717ed8eb1a", "tree": "8ba35fb48b559d39cd9ff5c9813e9274ca615ed9", "parents": [ "c3e67bd82b9b9b1a5118f09a429ccefe2aab0741" ], "author": { "name": "Sahil Chandna", "email": "sahilchandna@linux.microsoft.com", "time": "Wed Oct 28 03:40:17 2026 -0500" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Tue Nov 03 09:47:33 2026 +0100" }, "message": "net: mana: Add support to process throttled EQEs\n\nWhen an event queue nears full, the hardware coalesces the per-CQ\nGDMA_EQE_COMPLETION notifications into a single throttle EQE (type 4)\nthat carries no cq_id. The driver does not handle this event type, so\nit falls through to the default case and is dropped. Any CQ whose\ncompletion notification was replaced by the throttle EQE can remain\nunserviced, causing its queue to stall.\n\nThis was observed internally as a TX stall:\n\n ens1: NETDEV WATCHDOG: CPU: 45: transmit queue 1 timed out 15133 ms\n mana 7870:00:00.0: HWC: Request timed out: 60000 ms\n mana 7870:00:00.0: Gf stats wk handler: gf stats query timed out.\n ens1: NETDEV WATCHDOG: CPU: 20: transmit queue 0 timed out 15859 ms\n ens1: NETDEV WATCHDOG: CPU: 15: transmit queue 0 timed out 31731 ms\n ens1: NETDEV WATCHDOG: CPU: 21: transmit queue 0 timed out 47603 ms\n ens1: NETDEV WATCHDOG: CPU: 42: transmit queue 0 timed out 62451 ms\n\nHandle the throttle EQE:\n\n- Record up to two child CQs per EQ when a CQ is created with a parent\n EQ. A mana_en EQ serves one TX CQ and one RX CQ, and the HWC EQ\n serves the HWC CQ.\n- On a throttle EQE, call the callback of each child CQ that is still\n in cq_table[].\n- Before a child CQ is freed, unlink it from its parent EQ and from\n cq_table[] in mana_gd_detach_cq(), then wait for an RCU\n grace period, because mana_gd_intr() reads both under\n rcu_read_lock(). mana_destroy_txq() and mana_destroy_rxq() detach\n the CQ before deleting its NAPI, so the synchronize_net() that NAPI\n deletion already needs also covers the CQ. mana_hwc_destroy_channel()\n detaches the HWC CQ and waits for a grace period before freeing the\n HWC queues.\n- Advertise the capability bit for throttled EQE.\n- Add a throttle eqe counter per queue.\n\nFixes: ca9c54d2d6a5 (\"net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)\")\nCc: stable@vger.kernel.org\nSigned-off-by: Sahil Chandna \u003csahilchandna@linux.microsoft.com\u003e\nLink: https://patch.msgid.link/20261028084020.2051254-1-sahilchandna@linux.microsoft.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "60b10121db602a43ada3dbc39792bbf93d25991b", "tree": "71f7fbabaad586e1b5f9e557c5d225e01bf5f170", "parents": [ "ed4d302af778b9e2ead28134a2196c09a4ad248a" ], "author": { "name": "Kevin Dewald", "email": "kevin@simpleble.org", "time": "Mon Nov 02 09:00:00 2026 -0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:03 2026 -0500" }, "message": "Bluetooth: MGMT: Fix discovery stuck after a failed Stop Discovery\n\nStop Discovery moves the discovery to DISCOVERY_STOPPING, and\nstop_discovery_complete() only moves it on to DISCOVERY_STOPPED when\nstopping succeeded. When it fails, for example because LE Set Scan\nEnable times out, nothing moves the discovery out of\nDISCOVERY_STOPPING: Stop Discovery is rejected, as the discovery is not\nactive anymore, and the LE scan timeout was cancelled before the scan\nwas disabled. Until the controller is powered off, every Start\nDiscovery then fails with Busy, and hci_update_passive_scan_sync()\nskips background scanning, so devices set to auto-connect are not\nconnected anymore.\n\nMove the discovery back to DISCOVERY_FINDING when stopping it failed\nwhile its inquiry or active LE scan is still running, so that it can be\nstopped again. Only change the state while the discovery is still\nstopping, as Inquiry Cancel may already have stopped it, for example\nwhen only the passive scan could not be disabled, and a new Start\nDiscovery may have followed. Do this under hci_dev_lock(), like the\ncommand completions that change these flags, and before replying, so\nthat a client acting on the reply sees the new state. Only cancel the\nLE scan timeout once the scan is disabled, so that the discovery still\nends on its own, except when suspending, where it is still cancelled\nfirst.\n\nA timed out LE Set Scan Enable can still complete afterwards, which\ncancels the timeout as well, so also stop the discovery when its scan\nis disabled while the timeout is pending, or while the timeout work\nwaits for the lock.\n\nFixes: 0e05bba6f6f8 (\"Bluetooth: Update stop_discovery to use HCI request\")\nAssisted-by: Claude:claude-opus-5.5\nSigned-off-by: Kevin Dewald \u003ckevin@simpleble.org\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "ed4d302af778b9e2ead28134a2196c09a4ad248a", "tree": "c39a5f484f65bc5f0460484db5a41d9a3954b994", "parents": [ "1eb52f35fc8fb06ab7f2973fff29cba81f96b947" ], "author": { "name": "Yifan Zhang", "email": "yfzhang23@stu.pku.edu.cn", "time": "Mon Nov 02 19:58:37 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:03 2026 -0500" }, "message": "Bluetooth: validate retained LE Set CIG Parameters command length\n\nhci_cc_le_set_cig_params() validates the controller response but not the\nparameters of the previously sent command. A short command can claim a\nlarge num_cis without containing the corresponding cis[] array. A\ncomplete successful response then makes the handler read beyond the\ncommand skb while looking up each CIS ID.\n\nKASAN reports:\n\n BUG: KASAN: slab-out-of-bounds in hci_cc_le_set_cig_params\n Read of size 1\n hci_cc_le_set_cig_params\n hci_cmd_complete_evt\n hci_event_packet\n\nObtain the retained parameter length and require both the fixed header and\nthe complete CIS array before using the command data.\n\nThe reproducer no longer triggers a KASAN report with this change.\n\nFixes: 71e9588435c3 (\"Bluetooth: ISO: use correct CIS order in Set CIG Parameters event\")\nCloses: https://lore.kernel.org/linux-bluetooth/179317463153.87610.8996555110609321376@stu.pku.edu.cn/\nSigned-off-by: Yifan Zhang \u003cyfzhang23@stu.pku.edu.cn\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "1eb52f35fc8fb06ab7f2973fff29cba81f96b947", "tree": "c2e847bfc78c955f52a942c52c6da030f7b89a84", "parents": [ "a7c5c18b7cc30dcd2a9ae5a0fb38378d3998417e" ], "author": { "name": "Yifan Zhang", "email": "yfzhang23@stu.pku.edu.cn", "time": "Mon Nov 02 19:58:37 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:03 2026 -0500" }, "message": "Bluetooth: validate retained LE Create CIS command length\n\nhci_cs_le_create_cis() retrieves the parameters of the previously sent\ncommand without their length. It then trusts num_cis and walks the\nflexible cis[] array when a controller reports a failed command.\n\nA five-byte HCI command containing only num_cis can therefore make the\nhandler read beyond the command skb. KASAN reports:\n\n BUG: KASAN: slab-out-of-bounds in hci_cs_le_create_cis\n Read of size 2\n hci_cs_le_create_cis\n hci_cmd_status_evt\n hci_event_packet\n\nAdd a length-returning saved-command helper and require the fixed header\nand complete CIS array before walking it.\n\nThe reproducer no longer triggers a KASAN report with this change.\n\nFixes: 26afbd826ee3 (\"Bluetooth: Add initial implementation of CIS connections\")\nCloses: https://lore.kernel.org/linux-bluetooth/179317462624.87574.6271582002629080499@stu.pku.edu.cn/\nSigned-off-by: Yifan Zhang \u003cyfzhang23@stu.pku.edu.cn\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "a7c5c18b7cc30dcd2a9ae5a0fb38378d3998417e", "tree": "5eb31ec76e57d98a3a737da1ea100c1566fea38f", "parents": [ "a9f9eeb5344fc7dc625e5700ccf09891bc2603b5" ], "author": { "name": "Cen Zhang", "email": "zzzccc427@gmail.com", "time": "Fri Oct 30 22:27:45 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:03 2026 -0500" }, "message": "Bluetooth: hci_core: Initialize advertising RPA work only once\n\nhci_add_adv_instance() also updates existing instances and calls\nINIT_DELAYED_WORK() on their rpa_expired_cb every time, even when the\nwork is pending or running. cancel_delayed_work_sync() then no longer\nfinds the work, so hci_remove_adv_instance() can free the instance\nunder it:\n\n hdev-\u003eworkqueue MGMT_OP_ADD_EXT_ADV_PARAMS\n adv_instance_rpa_expired()\n hci_dev_lock(hdev)\n hci_add_adv_instance()\n INIT_DELAYED_WORK()\n mgmt_pending_new() fails\n hci_remove_adv_instance()\n cancel_delayed_work_sync()\n returns without waiting\n kfree(adv)\n hci_dev_unlock(hdev)\n adv-\u003erpa_expired \u003d true\n\nThe work has been initialized on every update since it was added.\nInitialize it only when the instance is allocated.\n\nKASAN report as below:\n\n BUG: KASAN: slab-use-after-free in adv_instance_rpa_expired+0x139/0x160\n Write of size 1 at addr ffff888108d84b2e by task kworker/u17:0/504\n\n Workqueue: hci0 adv_instance_rpa_expired\n Call Trace:\n adv_instance_rpa_expired+0x139/0x160\n\n Allocated by task 560:\n hci_add_adv_instance+0x68d/0x9d0\n add_ext_adv_params+0x4d4/0xb60\n hci_sock_sendmsg+0x128b/0x22e0\n\n Freed by task 594:\n kfree+0x307/0x580\n hci_remove_adv_instance+0x230/0x540\n add_ext_adv_params+0xa43/0xb60\n hci_sock_sendmsg+0x128b/0x22e0\n\n Last potentially related work creation:\n insert_work+0x37/0x210\n __queue_work+0xaba/0x1270\n call_timer_fn+0x171/0x500\n\n The buggy address belongs to the object at ffff888108d84800\n which belongs to the cache kmalloc-1k of size 1024\n The buggy address is located 814 bytes inside of\n freed 1024-byte region [ffff888108d84800, ffff888108d84c00)\n\nFixes: a73c046a2869 (\"Bluetooth: Implement Set ADV set random address\")\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "a9f9eeb5344fc7dc625e5700ccf09891bc2603b5", "tree": "b773290f251e704ace8070693e600a68e4f632a8", "parents": [ "d90f24dc389b9a7524aaac109021d1530fa180f0" ], "author": { "name": "Jinwang Li", "email": "jinwang.li@oss.qualcomm.com", "time": "Thu Oct 29 17:41:04 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:03 2026 -0500" }, "message": "Bluetooth: L2CAP: Ignore connection responses with wrong ident\n\nL2CAP/COS/CED/BI-28-C requires the IUT to ignore a Connection Response\nthat carries an invalid Identifier.\n\nl2cap_connect_create_rsp() only checks that a connection request is\noutstanding, not that the response answers it. Add an ident check\nagainst the pending request so that a mismatched response is dropped.\n\nFixes: 1da177e4c3f4 (\"Linux-2.6.12-rc2\")\nSigned-off-by: Jinwang Li \u003cjinwang.li@oss.qualcomm.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "d90f24dc389b9a7524aaac109021d1530fa180f0", "tree": "767778319e37294c81cd8d141fd2a324cfbbed63", "parents": [ "9ff737119177a6c1ce6083ef8c0fc06355f11869" ], "author": { "name": "Kevin Dewald", "email": "kevin@simpleble.org", "time": "Thu Oct 29 13:28:32 2026 -0700" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:03 2026 -0500" }, "message": "Bluetooth: MGMT: Clear disabled connection parameters when loading none\n\nLoad Connection Parameters only clears the disabled connection\nparameters when it loads more than one entry, so that loading a single\nentry can update the parameters of one device without dropping the\nothers. Loading no entries does not clear them either, though, which is\nwhat bluetoothd does when it starts without stored connection\nparameters.\n\nPair Device adds disabled connection parameters for the device it pairs\nwith, so these now survive bluetoothd restarts, and new connections to\nthe device keep using the parameters they were created with instead of\nthe defaults set since, e.g. the connection interval from main.conf.\n\nClear the disabled connection parameters unless a single entry is\nloaded, as was done for any number of entries before.\n\nFixes: 0ece498c27d8 (\"Bluetooth: MGMT: Make MGMT_OP_LOAD_CONN_PARAM update existing connection\")\nAssisted-by: Claude:claude-opus-5.5\nSigned-off-by: Kevin Dewald \u003ckevin@simpleble.org\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "9ff737119177a6c1ce6083ef8c0fc06355f11869", "tree": "88a24f1569640e7117605f8d8bf12048a62aaf9a", "parents": [ "add463a65802bb117e4a17b8c00d747fa70399fc" ], "author": { "name": "Cen Zhang", "email": "zzzccc427@gmail.com", "time": "Thu Oct 29 21:12:29 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:02 2026 -0500" }, "message": "Bluetooth: hci_sync: Copy the resolving-list IRK under RCU\n\nhci_le_add_resolve_list_sync() copies the peer IRK into the LE Add\nDevice To Resolving List command after hci_find_irk_by_addr() has\nreturned. The finder ends its RCU read-side section before returning\nthe borrowed entry, and neither the request worker nor\ninterleave_scan_work() holds hdev-\u003elock here. The resolving-list\nmembership check between the lookup and the copy takes hdev-\u003elock and\nmay sleep on it, which widens the window.\n\nWhen LL privacy programs a peer with address resolution enabled,\nMGMT_OP_LOAD_IRKS can free its IRK before the copy:\n\n Request worker Management / RCU reclamation\n hci_le_add_resolve_list_sync()\n irk \u003d hci_find_irk_by_addr()\n load_irks()\n hci_dev_lock(hdev)\n hci_smp_irks_clear(hdev)\n list_del_rcu(), kfree_rcu()\n hci_dev_unlock(hdev)\n grace period ends, irk is freed\n resolving-list membership check\n memcpy(cp.peer_irk, irk-\u003eval, 16)\n\nCopy the IRK value in an RCU read-side section right after the lookup,\nas hci_le_set_privacy_mode_sync() does for the identity address. The\nsection ends before hdev-\u003elock is taken and before the synchronous HCI\ncommand is sent.\n\nKASAN reported this on a test kernel with scheduling hooks, whose\nframes appear in the trace. The report predates the hdev-\u003elock taken\nby the membership check.\n\nKASAN report as below:\n\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n BUG: KASAN: slab-use-after-free in hci_le_add_resolve_list_sync+0x8d9/0x910\n Read of size 16 at addr ffff88810d21452d by task kworker/u17:0/504\n\n CPU: 2 UID: 0 PID: 504 Comm: kworker/u17:0 Not tainted 7.2.0-rc6-pmb-bt-functional-v1+ #2 PREEMPT(lazy)\n 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\n Workqueue: hci0 interleave_scan_work\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x93/0xd0\n print_report+0xce/0x630\n ? hci_le_add_resolve_list_sync+0x8d9/0x910\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __virt_addr_valid+0x20d/0x410\n ? hci_le_add_resolve_list_sync+0x8d9/0x910\n kasan_report+0xe0/0x110\n ? hci_le_add_resolve_list_sync+0x8d9/0x910\n hci_le_add_resolve_list_sync+0x8d9/0x910\n ? __pfx_hci_le_add_resolve_list_sync+0x10/0x10\n ? pmbd_probe_hit_cookie+0xe7/0x1c0\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? pmbd_probe_hit_cookie+0xee/0x1c0\n ? __pfx_pmbd_probe_hit_cookie+0x10/0x10\n hci_le_add_accept_list_sync+0x18e/0x820\n ? conn_params_copy+0x36e/0x650\n ? __pfx_hci_le_add_accept_list_sync+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? conn_params_copy+0x3a0/0x650\n hci_passive_scan_sync+0x95f/0x1f10\n ? __pfx_hci_passive_scan_sync+0x10/0x10\n ? debug_object_deactivate+0x2f8/0x3c0\n ? pwq_dec_nr_in_flight+0x880/0xdf0\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? lock_acquire+0x17b/0x2f0\n ? process_one_work+0x895/0x19c0\n interleave_scan_work+0x11b/0x470\n process_one_work+0x908/0x19c0\n ? __pfx_process_one_work+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? lock_is_held_type+0x8f/0x100\n ? srso_alias_return_thunk+0x5/0xfbef5\n worker_thread+0x65c/0xe40\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x34f/0x460\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x659/0x940\n ? __pfx_ret_from_fork+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __switch_to+0x74f/0xf80\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\n Allocated by task 535:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n __kmalloc_cache_noprof+0x251/0x610\n hci_add_irk+0xb6/0x220\n load_irks+0x5f9/0x840\n hci_sock_sendmsg+0x128b/0x22e0\n __sys_sendto+0x425/0x470\n __x64_sys_sendto+0xe5/0x1c0\n do_syscall_64+0x115/0x6a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n Freed by task 0:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x5f/0x80\n __rcu_free_sheaf_prepare+0x65/0x2a0\n rcu_free_sheaf+0x1f/0xe0\n rcu_core+0x661/0x1d10\n handle_softirqs+0x201/0x930\n __irq_exit_rcu+0x110/0x1e0\n irq_exit_rcu+0xe/0x20\n sysvec_apic_timer_interrupt+0x6c/0x80\n asm_sysvec_apic_timer_interrupt+0x1a/0x20\n\n The buggy address belongs to the object at ffff88810d214500\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 45 bytes inside of\n freed 64-byte region [ffff88810d214500, ffff88810d214540)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10d214\n flags: 0x200000000000000(node\u003d0|zone\u003d2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000428c0 dead000000000100 dead000000000122\n raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff88810d214400: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ffff88810d214480: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n \u003effff88810d214500: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ^\n ffff88810d214580: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ffff88810d214600: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nFixes: e8907f76544f (\"Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 3\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "add463a65802bb117e4a17b8c00d747fa70399fc", "tree": "951b964cd88d8468f830504302086bbf01ea9ddf", "parents": [ "ebc4f217c1fbe8364b5ef2ad8e3a8e9a1b2701a7" ], "author": { "name": "Cen Zhang", "email": "zzzccc427@gmail.com", "time": "Thu Oct 29 21:12:28 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:02 2026 -0500" }, "message": "Bluetooth: SMP: Protect LTK encryption with RCU\n\nsmp_ltk_encrypt() checks the security level of the LTK returned by\nhci_find_ltk() and then starts encryption with its EDIV, Rand, value\nand key size. The finder ends its RCU read-side section before\nreturning the borrowed entry, and neither caller holds hdev-\u003elock: the\nSMP Security Request handler runs from the receive path, and\nsetsockopt(BT_SECURITY) reaches smp_conn_security() with only the\nsocket and channel locks held.\n\nMGMT_OP_LOAD_LONG_TERM_KEYS can therefore free the LTK in between:\n\n Socket security request Management / RCU reclamation\n smp_ltk_encrypt()\n key \u003d hci_find_ltk()\n load_long_term_keys()\n hci_dev_lock(hdev)\n hci_smp_ltks_clear(hdev)\n list_del_rcu(), kfree_rcu()\n hci_dev_unlock(hdev)\n grace period ends, key is freed\n smp_ltk_sec_level(key)\n hci_le_start_enc(hcon, key-\u003eediv, key-\u003erand, key-\u003eval, ...)\n\nKeep an RCU read-side section across the lookup and every use of the\nkey. hci_le_start_enc() copies the key into the command and queues it\nwith a GFP_ATOMIC allocation, so the whole sequence can stay inside the\nsection.\n\nKFENCE reported this on a test kernel where the socket thread was\npaused after the lookup until the RCU callback had freed the key.\n\nKFENCE report as below:\n\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n BUG: KFENCE: use-after-free read in smp_ltk_encrypt.isra.0+0xf3/0x370\n\n Use-after-free read at 0x00000000c45332eb (in kfence-#128):\n smp_ltk_encrypt.isra.0+0xf3/0x370\n smp_conn_security+0x489/0x9d0\n l2cap_sock_setsockopt+0x1bbe/0x2300\n do_sock_setsockopt+0x1fb/0x430\n __sys_setsockopt+0x106/0x180\n __x64_sys_setsockopt+0xc2/0x160\n do_syscall_64+0x115/0x6a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n kfence-#128: 0x00000000d45af9b0-0x0000000053c1365e, size\u003d72, cache\u003dkmalloc-96\n\n allocated by task 533 on cpu 0 at 50.484258s (0.449177s ago):\n hci_add_ltk+0x1f5/0x3a0\n load_long_term_keys+0x6ea/0x930\n hci_sock_sendmsg+0x128b/0x22e0\n sock_write_iter+0x4c0/0x550\n vfs_write+0x637/0x1010\n ksys_write+0x1b7/0x200\n do_syscall_64+0x115/0x6a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n freed by task 0 on cpu 0 at 50.846944s (0.093664s ago):\n __rcu_free_sheaf_prepare+0x261/0x2a0\n rcu_free_sheaf_nobarn+0x1d/0x50\n rcu_core+0x661/0x1d10\n handle_softirqs+0x201/0x930\n __irq_exit_rcu+0x110/0x1e0\n irq_exit_rcu+0xe/0x20\n sysvec_apic_timer_interrupt+0x6c/0x80\n asm_sysvec_apic_timer_interrupt+0x1a/0x20\n pv_native_safe_halt+0xf/0x20\n default_idle+0x9/0x10\n default_idle_call+0x6c/0xb0\n do_idle+0x3a7/0x650\n cpu_startup_entry+0x54/0x60\n rest_init+0x15e/0x2b0\n start_kernel+0x412/0x4b0\n x86_64_start_reservations+0x18/0x30\n x86_64_start_kernel+0x111/0x120\n common_startup_64+0x13e/0x158\n\n CPU: 2 UID: 0 PID: 534 Comm: l2cap-ltk-actor Not tainted 7.2.0-rc6-pmb-bt-functional-v1+ #5 PREEMPT(lazy)\n 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\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nFixes: 988c5997d320 (\"Bluetooth: Use the LTK after receiving a LE Security Request\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "ebc4f217c1fbe8364b5ef2ad8e3a8e9a1b2701a7", "tree": "059f0465077ca4fee0a02f32beb0ee00a87ef5ce", "parents": [ "281ddc4e01ab54cab07995f2a1b72cf81bf90eb5" ], "author": { "name": "Cen Zhang", "email": "zzzccc427@gmail.com", "time": "Thu Oct 29 21:12:27 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:02 2026 -0500" }, "message": "Bluetooth: SMP: Protect link keys during LTK derivation\n\nsc_generate_ltk() reads the type and value of the peer link key after\nhci_find_link_key() has returned. The finder ends its RCU read-side\nsection before returning the borrowed entry, and the SMP receive path\ndoes not hold hdev-\u003elock: l2cap_recv_acldata() releases it before the\nPDU is dispatched. The L2CAP connection and channel locks held by SMP\ndo not serialize with management link-key removal.\n\nWhen BR/EDR Secure Connections pairing derives an LTK from the stored\nlink key, MGMT_OP_LOAD_LINK_KEYS can free that key mid-derivation:\n\n HCI RX worker (SMP) Management / RCU reclamation\n sc_generate_ltk()\n key \u003d hci_find_link_key()\n load_link_keys()\n hci_dev_lock(hdev)\n hci_link_keys_clear(hdev)\n list_del_rcu(), kfree_rcu()\n hci_dev_unlock(hdev)\n grace period ends, key is freed\n read key-\u003etype\n smp_h6() or smp_h7() reads key-\u003eval\n\nHold an RCU read-side section from the lookup until the type and value\nhave been consumed. smp_h6() and smp_h7() only run the synchronous\nAES-CMAC library code, which neither sleeps nor allocates. Release the\nsection before sc_add_ltk(), which allocates with GFP_KERNEL.\n\nKASAN reported this on a test kernel whose scheduling hook paused the\nreceive worker after the lookup; the hook frames appear in the trace.\n\nKASAN report as below:\n\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n BUG: KASAN: slab-use-after-free in smp_distribute_keys+0x2983/0x2b70\n Read of size 1 at addr ffff88810618e9a6 by task kworker/u17:0/500\n\n CPU: 0 UID: 0 PID: 500 Comm: kworker/u17:0 Not tainted 7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy)\n 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\n Workqueue: hci1 hci_rx_work\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x93/0xd0\n print_report+0xce/0x630\n ? smp_distribute_keys+0x2983/0x2b70\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __virt_addr_valid+0x20d/0x410\n ? smp_distribute_keys+0x2983/0x2b70\n kasan_report+0xe0/0x110\n ? smp_distribute_keys+0x2983/0x2b70\n smp_distribute_keys+0x2983/0x2b70\n ? __pfx_smp_distribute_keys+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? pmbd_gate_maybe+0x47/0x60\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? pmbd_probe_hit_cookie+0xe7/0x1c0\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? pmbd_probe_hit_cookie+0xee/0x1c0\n ? __pfx_pmbd_probe_hit_cookie+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __asan_memset+0x23/0x50\n ? smp_recv_cb+0x12e2/0x8f30\n ? srso_alias_return_thunk+0x5/0xfbef5\n smp_recv_cb+0x12e2/0x8f30\n ? __pfx_smp_recv_cb+0x10/0x10\n ? __pfx___might_resched+0x10/0x10\n ? __pfx_sched_balance_find_src_group+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __mutex_lock+0x182c/0x2590\n ? l2cap_recv_frame+0x9ef/0x8830\n ? __pfx___mutex_lock+0x10/0x10\n ? __lock_acquire+0x466/0x2260\n ? __pfx_l2cap_chan_hold_unless_zero+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? l2cap_recv_frame+0x13cc/0x8830\n ? __pfx_smp_recv_cb+0x10/0x10\n l2cap_recv_frame+0x13cc/0x8830\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __mutex_lock+0x182c/0x2590\n ? __pfx_l2cap_recv_frame+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? find_held_lock+0x2b/0x80\n ? l2cap_recv_acldata+0x1eb/0x10e0\n ? __pfx___mutex_lock+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __mutex_unlock_slowpath+0x147/0x920\n ? __pfx_l2cap_conn_hold_unless_zero+0x10/0x10\n ? __pfx_hci_conn_enter_active_mode+0x10/0x10\n ? l2cap_recv_acldata+0x13d/0x10e0\n ? srso_alias_return_thunk+0x5/0xfbef5\n l2cap_recv_acldata+0xe9f/0x10e0\n ? srso_alias_return_thunk+0x5/0xfbef5\n hci_rx_work+0x5a6/0xf00\n ? srso_alias_return_thunk+0x5/0xfbef5\n process_one_work+0x908/0x19c0\n ? __pfx_process_one_work+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? lock_is_held_type+0x8f/0x100\n ? srso_alias_return_thunk+0x5/0xfbef5\n worker_thread+0x65c/0xe40\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x34f/0x460\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x659/0x940\n ? __pfx_ret_from_fork+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __switch_to+0x74f/0xf80\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\n Allocated by task 500:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n __kmalloc_cache_noprof+0x251/0x610\n hci_add_link_key+0x474/0x840\n hci_link_key_notify_evt+0x492/0xce0\n hci_event_packet+0x894/0xc70\n hci_rx_work+0x367/0xf00\n process_one_work+0x908/0x19c0\n worker_thread+0x65c/0xe40\n kthread+0x34f/0x460\n ret_from_fork+0x659/0x940\n ret_from_fork_asm+0x1a/0x30\n\n Freed by task 0:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x5f/0x80\n __rcu_free_sheaf_prepare+0x65/0x2a0\n rcu_free_sheaf+0x1f/0xe0\n rcu_core+0x661/0x1d10\n handle_softirqs+0x201/0x930\n __irq_exit_rcu+0x110/0x1e0\n irq_exit_rcu+0xe/0x20\n sysvec_apic_timer_interrupt+0x6c/0x80\n asm_sysvec_apic_timer_interrupt+0x1a/0x20\n\n The buggy address belongs to the object at ffff88810618e980\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 38 bytes inside of\n freed 64-byte region [ffff88810618e980, ffff88810618e9c0)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10618e\n flags: 0x200000000000000(node\u003d0|zone\u003d2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000428c0 dead000000000122 0000000000000000\n raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff88810618e880: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ffff88810618e900: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n \u003effff88810618e980: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ^\n ffff88810618ea00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ffff88810618ea80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nFixes: b5ae344d4c0f (\"Bluetooth: Add full SMP BR/EDR support\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "281ddc4e01ab54cab07995f2a1b72cf81bf90eb5", "tree": "940e4d54e1a9a7c1581b38b8499256bf529dfe3c", "parents": [ "3b70dd827b27bfadd89e7b1a2d422b04da38797c" ], "author": { "name": "Cen Zhang", "email": "zzzccc427@gmail.com", "time": "Thu Oct 29 21:12:26 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:02 2026 -0500" }, "message": "Bluetooth: hci_core: Keep link-key filtering inside RCU\n\nhci_find_link_key() must keep the matching link key allocated while it\nchecks the key against the blocked-key list. It currently leaves the\nkey-list RCU read-side section before passing k-\u003eval to\nhci_is_blocked_key(). That helper\u0027s own RCU section protects the\nblocked-key list, but it cannot keep an unlinked link key from being\nreclaimed.\n\nThe SMP receive path calls the finder without hdev-\u003elock: Secure\nConnections key distribution over BR/EDR reaches it through\nsmp_distribute_keys() and sc_generate_ltk(). With a stored peer link\nkey and a link-key entry in the blocked-key list,\nMGMT_OP_LOAD_LINK_KEYS can free the selected key before the comparison:\n\n HCI RX worker (SMP) Management / RCU reclamation\n hci_find_link_key()\n rcu_read_lock()\n select k\n rcu_read_unlock()\n load_link_keys()\n hci_dev_lock(hdev)\n hci_link_keys_clear(hdev)\n list_del_rcu(), kfree_rcu()\n hci_dev_unlock(hdev)\n grace period ends, k is freed\n hci_is_blocked_key(hdev, ..., k-\u003eval)\n memcmp() reads the freed key\n\nKeep the RCU read-side section active through the blocked-key\ncomparison and the warning that prints k-\u003ebdaddr, and release it before\nreturning on both matched-key paths. hci_find_ltk() already handles its\nblocked-key check this way.\n\nKASAN reported this on a test kernel whose scheduling hook paused the\nreceive worker after the lookup until the key had been freed.\n\nKASAN report as below:\n\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n BUG: KASAN: slab-use-after-free in hci_is_blocked_key+0x2db/0x300\n Read of size 1 at addr ffff88810b5f89a7 by task kworker/u17:0/502\n\n CPU: 1 UID: 0 PID: 502 Comm: kworker/u17:0 Not tainted 7.2.0-rc6-pmb-bt-functional-v1+ #5 PREEMPT(lazy)\n 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\n Workqueue: hci1 hci_rx_work\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x93/0xd0\n print_report+0xce/0x630\n ? hci_is_blocked_key+0x2db/0x300\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __virt_addr_valid+0x20d/0x410\n ? hci_is_blocked_key+0x2db/0x300\n kasan_report+0xe0/0x110\n ? hci_is_blocked_key+0x2db/0x300\n hci_is_blocked_key+0x2db/0x300\n hci_find_link_key+0x12e/0x400\n smp_distribute_keys+0x1830/0x2950\n ? trace_hardirqs_on+0x18/0x160\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? queue_delayed_work_on+0xb3/0xf0\n ? __pfx_smp_distribute_keys+0x10/0x10\n ? __pfx_smp_send_cmd.isra.0+0x10/0x10\n ? __cancel_work+0x1b0/0x290\n ? __entry_text_end+0x1020f7/0x1020f9\n ? lockdep_hardirqs_on_prepare+0xea/0x1a0\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __asan_memset+0x23/0x50\n ? smp_recv_cb+0x12c7/0x8d80\n ? srso_alias_return_thunk+0x5/0xfbef5\n smp_recv_cb+0x12c7/0x8d80\n ? __pfx_smp_recv_cb+0x10/0x10\n ? __pfx___might_resched+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? stack_depot_save_flags+0x29/0x9a0\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __mutex_lock+0x182c/0x2590\n ? kasan_save_stack+0x42/0x60\n ? l2cap_recv_frame+0x9ef/0x8830\n ? __kasan_slab_free+0x5f/0x80\n ? kmem_cache_free+0x242/0x580\n ? kfree_skbmem+0x15e/0x1d0\n ? sk_skb_reason_drop+0x12f/0x490\n ? hci_event_packet+0x556/0xc70\n ? hci_rx_work+0x367/0xf00\n ? process_one_work+0x908/0x19c0\n ? worker_thread+0x65c/0xe40\n ? __pfx___mutex_lock+0x10/0x10\n ? __lock_acquire+0x466/0x2260\n ? __pfx_l2cap_chan_hold_unless_zero+0x10/0x10\n ? l2cap_recv_frame+0x13cc/0x8830\n ? __pfx_smp_recv_cb+0x10/0x10\n l2cap_recv_frame+0x13cc/0x8830\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __mutex_lock+0x182c/0x2590\n ? __pfx_l2cap_recv_frame+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? find_held_lock+0x2b/0x80\n ? l2cap_recv_acldata+0x1eb/0x10e0\n ? __pfx___mutex_lock+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __mutex_unlock_slowpath+0x147/0x920\n ? __pfx_l2cap_conn_hold_unless_zero+0x10/0x10\n ? __pfx_hci_conn_enter_active_mode+0x10/0x10\n ? l2cap_recv_acldata+0x13d/0x10e0\n ? srso_alias_return_thunk+0x5/0xfbef5\n l2cap_recv_acldata+0xe9f/0x10e0\n ? srso_alias_return_thunk+0x5/0xfbef5\n hci_rx_work+0x5a6/0xf00\n ? srso_alias_return_thunk+0x5/0xfbef5\n process_one_work+0x908/0x19c0\n ? __pfx_process_one_work+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? lock_is_held_type+0x8f/0x100\n ? srso_alias_return_thunk+0x5/0xfbef5\n worker_thread+0x65c/0xe40\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x34f/0x460\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x659/0x940\n ? __pfx_ret_from_fork+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __switch_to+0x74f/0xf80\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\n Allocated by task 504:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n __kmalloc_cache_noprof+0x251/0x610\n hci_add_link_key+0x474/0x840\n hci_link_key_notify_evt+0x492/0xce0\n hci_event_packet+0x894/0xc70\n hci_rx_work+0x367/0xf00\n process_one_work+0x908/0x19c0\n worker_thread+0x65c/0xe40\n kthread+0x34f/0x460\n ret_from_fork+0x659/0x940\n ret_from_fork_asm+0x1a/0x30\n\n Freed by task 29:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x5f/0x80\n __rcu_free_sheaf_prepare+0x65/0x2a0\n rcu_free_sheaf_nobarn+0x1d/0x50\n rcu_core+0x661/0x1d10\n handle_softirqs+0x201/0x930\n run_ksoftirqd+0x33/0x60\n smpboot_thread_fn+0x3bd/0x9a0\n kthread+0x34f/0x460\n ret_from_fork+0x659/0x940\n ret_from_fork_asm+0x1a/0x30\n\n The buggy address belongs to the object at ffff88810b5f8980\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 39 bytes inside of\n freed 64-byte region [ffff88810b5f8980, ffff88810b5f89c0)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10b5f8\n flags: 0x200000000000000(node\u003d0|zone\u003d2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000428c0 dead000000000100 dead000000000122\n raw: 0000000000000000 0000000000200020 00000000f5000000 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff88810b5f8880: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ffff88810b5f8900: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n \u003effff88810b5f8980: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ^\n ffff88810b5f8a00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ffff88810b5f8a80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nFixes: 600a87490ff9 (\"Bluetooth: Implementation of MGMT_OP_SET_BLOCKED_KEYS.\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "3b70dd827b27bfadd89e7b1a2d422b04da38797c", "tree": "bcd78b6aed4c90ae7127c160536d35ef256858e6", "parents": [ "5b7d0386a4e75c85479da0fbd9fd66a3e9201375" ], "author": { "name": "Ismail Tarim", "email": "ismailtarim7@gmail.com", "time": "Fri Oct 30 01:40:15 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:02 2026 -0500" }, "message": "Bluetooth: btmtk: fix error handling in btmtk_usb_isointf_init()\n\nbtmtk_usb_isointf_init() submits the ISO interrupt IN URB and then\nsends the vendor command 0xfd98. If that command fails, the function\nreturns an error without killing the URB it has just submitted. The\ncaller then leaves BTMTK_ISOPKT_RUNNING clear, so the driver treats the\nISO path as inactive while its RX URB is still in flight, and\nbtmtk_usb_suspend() skips killing it. Kill the anchored URBs on this\npath, as the URB submission failure path already does.\n\nThe return value of __set_mtk_intr_interface() is also ignored: a\nfailure to select the ISO alternate setting or to find its endpoints\nis logged, but the function goes on to submit the URB. Return the\nerror instead.\n\nFixes: ceac1cb0259d (\"Bluetooth: btusb: mediatek: add ISO data transmission functions\")\nSigned-off-by: Ismail Tarim \u003cismailtarim7@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "5b7d0386a4e75c85479da0fbd9fd66a3e9201375", "tree": "8cb3557741268b475c81a6d6a523408cdf6b8255", "parents": [ "7eac80614300563470cffabf4df2b63616787ee7" ], "author": { "name": "Michael McAllister", "email": "me@michaelmcallister.org", "time": "Wed Oct 21 20:51:12 2026 +0100" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:02 2026 -0500" }, "message": "Bluetooth: qca: Fix the WCN3950 NVM baud rate offset\n\nWCN3950 uses the HCI transport tag layout that stores the UART baud rate\nat byte 1, like WCN3991. However, QCA_WCN3950 precedes QCA_WCN3991 in\nqca_btsoc_type, so qca_tlv_check_data() writes the baud rate to byte 2\ninstead.\n\nOn a Motorola Moto G10 with WCN3950 and cmnv12.bin, configuring a 3 Mbps\nUART therefore leaves the NVM baud rate at its default 3.2 Mbps and\noverwrites the following byte. Firmware download completes, but the\nsubsequent HCI_RESET times out and Bluetooth initialization fails.\n\nInclude WCN3950 in the byte-1 case so the NVM baud rate matches the host\nUART without altering the following transport parameter.\n\nFixes: d5712c511cb3 (\"Bluetooth: qca: add WCN3950 support\")\nCc: stable@vger.kernel.org\nAssisted-by: LLM\nSigned-off-by: Michael McAllister \u003cme@michaelmcallister.org\u003e\nReviewed-by: Bartosz Golaszewski \u003cbartosz.golaszewski@oss.qualcomm.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "7eac80614300563470cffabf4df2b63616787ee7", "tree": "073798d716053f166ecd0a5fca565497eb91e09d", "parents": [ "f05bd61a3213613de7848c8df2865492d5225023" ], "author": { "name": "Tobias Wilken", "email": "tooangel@tooangel.de", "time": "Wed Oct 21 08:58:33 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:02 2026 -0500" }, "message": "Bluetooth: MGMT: Return RFKILLED for Set Powered on a blocked controller\n\nSince MGMT_OP_SET_POWERED runs through hci_cmd_sync, powering on a\ncontroller that is blocked by rfkill fails with -ERFKILL from\nhci_dev_open_sync(), and mgmt_set_powered_complete() reports it with\nmgmt_status(err). mgmt_errno_status() has no case for -ERFKILL, so\nuserspace gets MGMT_STATUS_FAILED instead of MGMT_STATUS_RFKILLED.\n\nBefore that conversion, power on went through hci_power_on(), whose\nerror path mgmt_set_powered_failed() still maps -ERFKILL to\nMGMT_STATUS_RFKILLED. bluetoothd relies on that status: for\nRFKILLED it sets the adapter PowerState to \"off-blocked\" and returns\norg.bluez.Error.Blocked for the Powered property, for any other status\nit returns org.bluez.Error.Failed.\n\nWith the controller soft blocked, \"bluetoothctl power on\" printed\n\"Failed to set power on: org.bluez.Error.Failed\" and btmon showed\n\"Set Powered (0x0005) Status: Failed (0x03)\". With this change it\nprints org.bluez.Error.Blocked and btmon shows \"Status: RFKilled\n(0x12)\".\n\nMap -ERFKILL to MGMT_STATUS_RFKILLED in mgmt_errno_status().\n\nFixes: cf75ad8b41d2 (\"Bluetooth: hci_sync: Convert MGMT_SET_POWERED\")\nAssisted-by: LLM\nSigned-off-by: Tobias Wilken \u003ctooangel@tooangel.de\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "f05bd61a3213613de7848c8df2865492d5225023", "tree": "83989bf1bdf8ce6555fa2ad106b872523c4f1064", "parents": [ "674006912777747170ad70d7727804ad4f2d047f" ], "author": { "name": "Cen Zhang", "email": "zzzccc427@gmail.com", "time": "Thu Oct 22 20:05:56 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:02 2026 -0500" }, "message": "Bluetooth: hci_sync: Protect resolving-list lookups\n\nThe host resolving list is updated under hdev-\u003elock, and each\nbdaddr_list_with_irk entry must remain alive throughout a lookup.\nhci_le_del_resolve_list_sync() and hci_le_add_resolve_list_sync()\ntraverse that list without taking the lock.\n\nOn an LE privacy-capable controller with a programmed entry, passive\nscan reconciliation can reach hci_le_del_resolve_list_sync() while a\nprivileged HCI_RAW client sends LE Clear Resolving List. The raw\ncommand does not take req_lock, and its successful completion runs\non the controller workqueue independently of request work:\n\n Request work Raw HCI / event work\n hci_le_del_resolve_list_sync()\n lookup loads a list node\n hci_sock_sendmsg()\n queue LE Clear Resolving List\n hci_cc_le_clear_resolv_list()\n take hdev-\u003elock\n unlink and free the node\n release hdev-\u003elock\n read the node\u0027s address/type\n\nThe clear can free the node after the lookup loads it and before its\naddress/type read, causing a use-after-free. The report below shows\nthis access with the delete helper on the faulting stack. The add\nhelper uses the same unprotected lookup.\n\nTake hdev-\u003elock around each resolving-list membership lookup and\nretain only a boolean result. This serializes traversal with clear\ncompletion and keeps entry pointers inside the protected section.\nRelease the lock before issuing a synchronous HCI command, whose\ncompletion also needs the lock.\n\nKASAN report as below:\n\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n BUG: KASAN: slab-use-after-free in\n hci_bdaddr_list_lookup_with_irk+0x106/0x120\n Read of size 1 at addr ffff88810b036e16 by task kworker/u17:0/495\n\n CPU: 2 UID: 0 PID: 495 Comm: kworker/u17:0 Not tainted\n 7.2.0-rc6-pmb-bt-functional-v1+ #3 PREEMPT(lazy)\n Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix,\n 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Workqueue: hci0 hci_cmd_sync_work\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x93/0xd0\n print_report+0xce/0x630\n ? hci_bdaddr_list_lookup_with_irk+0x106/0x120\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __virt_addr_valid+0x20d/0x410\n ? hci_bdaddr_list_lookup_with_irk+0x106/0x120\n kasan_report+0xe0/0x110\n ? hci_bdaddr_list_lookup_with_irk+0x106/0x120\n hci_bdaddr_list_lookup_with_irk+0x106/0x120\n hci_le_del_resolve_list_sync.isra.0+0xd6/0x3f0\n ? __pfx_hci_le_del_resolve_list_sync.isra.0+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n hci_le_del_accept_list_sync.isra.0+0x11c/0x290\n ? __pfx_hci_le_del_accept_list_sync.isra.0+0x10/0x10\n ? hci_passive_scan_sync+0x551/0x1e80\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? lock_release+0xc8/0x280\n hci_passive_scan_sync+0x71c/0x1e80\n ? __pfx_hci_passive_scan_sync+0x10/0x10\n ? find_held_lock+0x2b/0x80\n ? hci_lookup_le_connect+0xe1/0x3c0\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? find_held_lock+0x2b/0x80\n ? hci_update_passive_scan_sync+0x437/0x950\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? lock_release+0xc8/0x280\n hci_update_passive_scan_sync+0x461/0x950\n hci_cmd_sync_work+0x1b3/0x450\n ? srso_alias_return_thunk+0x5/0xfbef5\n process_one_work+0x908/0x19c0\n ? __pfx_process_one_work+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? lock_is_held_type+0x8f/0x100\n ? srso_alias_return_thunk+0x5/0xfbef5\n worker_thread+0x65c/0xe40\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x34f/0x460\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x659/0x940\n ? __pfx_ret_from_fork+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __switch_to+0x74f/0xf80\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\n Allocated by task 495:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n __kmalloc_cache_noprof+0x251/0x610\n hci_bdaddr_list_add_with_irk+0x183/0x3e0\n hci_cc_le_add_to_resolv_list+0x18c/0x240\n hci_cmd_complete_evt+0x373/0xab0\n hci_event_packet+0x4e8/0xc70\n hci_rx_work+0x367/0xf00\n process_one_work+0x908/0x19c0\n worker_thread+0x65c/0xe40\n kthread+0x34f/0x460\n ret_from_fork+0x659/0x940\n ret_from_fork_asm+0x1a/0x30\n\n Freed by task 497:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x5f/0x80\n kfree+0x307/0x580\n hci_bdaddr_list_clear+0x134/0x230\n hci_cc_le_clear_resolv_list+0x13d/0x240\n hci_cmd_complete_evt+0x373/0xab0\n hci_event_packet+0x4e8/0xc70\n hci_rx_work+0x367/0xf00\n process_one_work+0x908/0x19c0\n worker_thread+0x65c/0xe40\n kthread+0x34f/0x460\n ret_from_fork+0x659/0x940\n ret_from_fork_asm+0x1a/0x30\n\n The buggy address belongs to the object at ffff88810b036e00\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 22 bytes inside of\n freed 64-byte region [ffff88810b036e00, ffff88810b036e40)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0\n pfn:0x10b036\n flags: 0x200000000000000(node\u003d0|zone\u003d2)\n page_type: f5(slab)\n raw: 0200000000000000 ffff8881000428c0 dead000000000100\n dead000000000122\n raw: 0000000000000000 0000000000200020 00000000f5000000\n 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff88810b036d00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n ffff88810b036d80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n \u003effff88810b036e00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ^\n ffff88810b036e80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ffff88810b036f00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n Disabling lock debugging due to kernel taint\n\nFixes: e8907f76544f (\"Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 3\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "674006912777747170ad70d7727804ad4f2d047f", "tree": "ef8aec0b852558a98b22ba24657ca091371d08e8", "parents": [ "855c9a54608f1e94f4c52afe3790def30534155a" ], "author": { "name": "Cen Zhang", "email": "zzzccc427@gmail.com", "time": "Thu Oct 22 20:16:36 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:02 2026 -0500" }, "message": "Bluetooth: hci_sync: Copy the LE accept list under hdev-\u003elock\n\nThe LE accept-list mirror consists of bdaddr_list entries that are\nadded, removed and freed under hdev-\u003elock. The ordinary branch of\nhci_update_accept_list_sync() traverses this list without that lock.\nThe request worker\u0027s req_lock does not serialize raw HCI completions,\nand the RCU sections protect connection and pending-action lookups,\nnot the accept-list nodes.\n\nChanging connectability can reach this iterator through\nset_connectable_sync(), hci_update_connectable_sync(),\nhci_update_passive_scan_sync() and hci_passive_scan_sync(). With a\npopulated mirror, a privileged raw HCI sender can issue\nHCI_OP_LE_CLEAR_ACCEPT_LIST while request work is reconciling it:\n\n Request work HCI event work\n select b and successor t\n hci_cc_le_clear_accept_list()\n hci_dev_lock(hdev)\n hci_bdaddr_list_clear()\n unlink nodes and kfree(b)\n hci_dev_unlock(hdev)\n read b-\u003ebdaddr_type\n\nThe clear completion can therefore free the selected node before its\nfield read, or the saved successor before the iterator advances.\nKASAN reported a one-byte read of bdaddr_type from the freed node.\n\nCopy each entry\u0027s address and type under hdev-\u003elock and reconcile the\nprivate array instead. Release the mutex before issuing synchronous\ncommands, since their completion handlers also acquire it. Free the\ncopy after iteration and use the existing error path to disable\naccept-list filtering if allocation fails.\n\nThis change has not been runtime-tested.\n\nKASAN report as below:\n\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n BUG: KASAN: slab-use-after-free in hci_passive_scan_sync+0x1cc4/0x1f80\n Read of size 1 at addr ffff888105ee6c56 by task kworker/u17:1/499\n\n Workqueue: hci0 hci_cmd_sync_work\n Call Trace:\n \u003cTASK\u003e\n dump_stack_lvl+0x93/0xd0\n print_report+0xce/0x630\n ? hci_passive_scan_sync+0x1cc4/0x1f80\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __virt_addr_valid+0x20d/0x410\n ? hci_passive_scan_sync+0x1cc4/0x1f80\n kasan_report+0xe0/0x110\n ? hci_passive_scan_sync+0x1cc4/0x1f80\n hci_passive_scan_sync+0x1cc4/0x1f80\n ? pmbd_gate_site_armed+0x31/0x1c0\n ? __pfx_hci_passive_scan_sync+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? pmbd_probe_hit_cookie+0x10/0x1c0\n ? __pfx_pmbd_probe_hit_cookie+0x10/0x10\n ? hci_update_passive_scan_sync+0x43f/0x9e0\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? lock_release+0xc8/0x280\n hci_update_passive_scan_sync+0x473/0x9e0\n hci_update_connectable_sync+0x13c/0x250\n set_connectable_sync+0x39/0xb0\n hci_cmd_sync_work+0x1b3/0x450\n ? srso_alias_return_thunk+0x5/0xfbef5\n process_one_work+0x908/0x19c0\n ? __pfx_process_one_work+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? lock_is_held_type+0x8f/0x100\n ? srso_alias_return_thunk+0x5/0xfbef5\n worker_thread+0x65c/0xe40\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x34f/0x460\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x659/0x940\n ? __pfx_ret_from_fork+0x10/0x10\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? __switch_to+0x74f/0xf80\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\n Allocated by task 511:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n __kmalloc_cache_noprof+0x251/0x610\n hci_bdaddr_list_add+0x179/0x390\n hci_cc_le_add_to_accept_list+0x189/0x2d0\n hci_cmd_complete_evt+0x373/0xab0\n hci_event_packet+0x4e8/0xc70\n hci_rx_work+0x367/0xf00\n process_one_work+0x908/0x19c0\n worker_thread+0x65c/0xe40\n kthread+0x34f/0x460\n ret_from_fork+0x659/0x940\n ret_from_fork_asm+0x1a/0x30\n\n Freed by task 511:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x5f/0x80\n kfree+0x307/0x580\n hci_bdaddr_list_clear+0x134/0x230\n hci_cc_le_clear_accept_list+0x80/0x1f0\n hci_cmd_complete_evt+0x373/0xab0\n hci_event_packet+0x4e8/0xc70\n hci_rx_work+0x367/0xf00\n process_one_work+0x908/0x19c0\n worker_thread+0x65c/0xe40\n kthread+0x34f/0x460\n ret_from_fork+0x659/0x940\n ret_from_fork_asm+0x1a/0x30\n\n The buggy address belongs to the object at ffff888105ee6c40\n which\n belongs to the cache kmalloc-32 of size 32\n The buggy address is located 22 bytes inside of\n freed\n 32-byte region [ffff888105ee6c40,\n ffff888105ee6c60)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000\n index:0xffff888105ee69c0 pfn:0x105ee6\n flags: 0x200000000000200(workingset|node\u003d0|zone\u003d2)\n page_type: f5(slab)\n raw: 0200000000000200 ffff888100042780 ffffea0004187150\n ffffea00042534d0\n raw: ffff888105ee69c0 000000000040003f 00000000f5000000\n 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888105ee6b00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc\n ffff888105ee6b80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc\n \u003effff888105ee6c00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc\n ^\n ffff888105ee6c80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc\n ffff888105ee6d00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc\n \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nFixes: e8907f76544f (\"Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 3\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "855c9a54608f1e94f4c52afe3790def30534155a", "tree": "980a7b0470de17a243ad1d33cb5188af691fca90", "parents": [ "d015faf684129a276f2137ad2e11c6c985294648" ], "author": { "name": "Chris Lu", "email": "chris.lu@mediatek.com", "time": "Thu Oct 22 11:21:50 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:02 2026 -0500" }, "message": "Bluetooth: btmtk: derive the firmware ISO setting from MTK_ISO_THRESHOLD\n\nThe ISO data transfer size is spelled out twice: as a raw byte pair in the\nvendor command sent by btmtk_usb_isointf_init(), and as MTK_ISO_THRESHOLD\nfor the padding in btmtk_isopkt_pad(). Build the command payload from the\nmacro so the size is stated once, and update the setting for current\nMediaTek controllers.\n\nFixes: ceac1cb0259d (\"Bluetooth: btusb: mediatek: add ISO data transmission functions\")\nSigned-off-by: Chris Lu \u003cchris.lu@mediatek.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "d015faf684129a276f2137ad2e11c6c985294648", "tree": "86335d962b6cd83931b8fcf1e2c549e1444438c7", "parents": [ "8524c3588fbb9d5c1b876e6f908c42926845650d" ], "author": { "name": "Chris Lu", "email": "chris.lu@mediatek.com", "time": "Thu Oct 22 11:21:49 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:01 2026 -0500" }, "message": "Bluetooth: btmtk: bound the ISO payload length by the controller\u0027s MTU\n\nbtmtk_recv_isopkt() bounds the Data_Total_Length reported by the\ncontroller with skb_tailroom(skb) \u003c hci_skb_expect(skb). That keeps the\nreassembly inside the skb, but it enforces no protocol limit: the head\nallocation is rounded up to the next kmalloc bucket and skb_tailroom()\nreports what the bucket can hold rather than what was requested, which is\nseveral hundred bytes more. An oversized length therefore passes, and the\nparser keeps pulling bytes out of the following transfers to fill it,\nswallowing the real ISO packets they carry until the frame is handed to\nhci_recv_frame().\n\nThe controller reports the largest ISO_Data_Packet_Length it will send in\nLE Read Buffer Size [v2], which hci_cc_le_read_buffer_size_v2() keeps in\nhdev-\u003eiso_mtu. Once that is available, bound the length by it and size the\nreceive skb to hold that much plus the 4-byte header. HCI_MAX_ISO_SIZE is\nkept only as a fallback for the window before the command completes.\n\nKeep the skb_tailroom() test as well, because a fragment started before\nhdev-\u003eiso_mtu was populated sits in an skb sized for the fallback.\n\nFixes: ceac1cb0259d (\"Bluetooth: btusb: mediatek: add ISO data transmission functions\")\nCo-developed-by: Hao Qin \u003chao.qin@mediatek.com\u003e\nSigned-off-by: Hao Qin \u003chao.qin@mediatek.com\u003e\nCo-developed-by: Wenlong Tian \u003cot_wenlong.tian@mediatek.com\u003e\nSigned-off-by: Wenlong Tian \u003cot_wenlong.tian@mediatek.com\u003e\nSigned-off-by: Chris Lu \u003cchris.lu@mediatek.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "8524c3588fbb9d5c1b876e6f908c42926845650d", "tree": "3d1730a304697f2b6cd17b39457152171ef8b950", "parents": [ "e24bfbc5e20711dafa0cdc2b3325c69de1cff068" ], "author": { "name": "Chris Lu", "email": "chris.lu@mediatek.com", "time": "Thu Oct 22 11:21:48 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:01 2026 -0500" }, "message": "Bluetooth: btmtk: drop zero-length ISO packets from endpoint padding\n\nThe ISO interrupt IN endpoint delivers a fixed-size transfer that holds\none HCI ISO packet and zero-fills the remainder. That padding belongs to\nthe transfer rather than to the stream, so it has to be dropped instead of\nreported to the host.\n\nbtmtk_recv_isopkt() keeps parsing it: the zero bytes read as an ISO header\nwith handle 0 and a Data_Total_Length of zero, and each one is passed to\nhci_recv_frame() as a complete frame. A single transfer yields a long run\nof them, which is what fills the HCI log with malformed ISO packets, and\niso_recv() drops the SDU it is reassembling whenever handle 0 belongs to a\nlive CIS/BIS.\n\nA zero Data_Total_Length carries no ISO Data Load, so such a packet is\nnever part of the stream. Check for the zero-filled remainder before\nstarting to parse the next frame, rather than after assembling a 4-byte\nheader: a remainder shorter than HCI_ISO_HDR_SIZE would otherwise be held\nacross calls as a partial header, corrupting the next transfer\u0027s framing.\nThis also means a fully zero-filled remainder no longer costs an skb\nallocation that gets immediately freed. Reaching a zero Data_Total_Length\nany other way is then a genuine error, not padding.\n\nThis was observed on MT7925, but btmtk_recv_isopkt() is shared by every\nMediaTek USB controller that supports ISO data.\n\nFixes: ceac1cb0259d (\"Bluetooth: btusb: mediatek: add ISO data transmission functions\")\nCo-developed-by: Hao Qin \u003chao.qin@mediatek.com\u003e\nSigned-off-by: Hao Qin \u003chao.qin@mediatek.com\u003e\nCo-developed-by: Wenlong Tian \u003cot_wenlong.tian@mediatek.com\u003e\nSigned-off-by: Wenlong Tian \u003cot_wenlong.tian@mediatek.com\u003e\nSigned-off-by: Chris Lu \u003cchris.lu@mediatek.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "e24bfbc5e20711dafa0cdc2b3325c69de1cff068", "tree": "bffdf8bee0a4b7a76e8a2d89c0518431d845a748", "parents": [ "5d005ded2cb14531c4d4ab5d02383407c75dbee6" ], "author": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Oct 22 17:03:37 2026 -0400" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:01 2026 -0500" }, "message": "Bluetooth: hci_sync: Update the CIS host feature when enabling LE\n\nThe Connected Isochronous Stream (Host Support) feature bit is only set\nduring init, based on LE being enabled at that time. If LE is enabled\nafterwards without the init being repeated, as happens when the\ncontroller is still auto powered on after registration, the bit stays\ncleared and controllers enforcing it reject LE Create CIS with Command\nDisallowed.\n\nUpdate the bit whenever LE Host Supported is written, so it follows the\nLE state.\n\nFixes: 709788b154ca (\"Bluetooth: hci_core: Fix using {cis,bis}_capable for current settings\")\nAssisted-by: OpenCode:claude-opus-5.5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "5d005ded2cb14531c4d4ab5d02383407c75dbee6", "tree": "5e6615723e1cccf129211a63e4400e351f28883a", "parents": [ "1eebde8ecede18e351ccf438f17b53d3b62a75a9" ], "author": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Oct 21 13:49:35 2026 -0400" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:01 2026 -0500" }, "message": "Bluetooth: L2CAP: Hold incoming data until encryption key size is known\n\nOnce encryption is enabled on an ACL link, the encryption key size is\nread from the controller, using hdev-\u003emin_enc_key_size in the meantime.\nData received before the reply is processed with that key size, so a\npeer starting SMP over BR/EDR right after encryption, which it may do,\ngets its Pairing Request rejected with \"Encryption Key Size\" whenever\nthe pending security level is FIPS, as that requires a 16 octet key:\n\n \u003e HCI Event: Encryption Change (0x08) plen 4\n \u003e ACL Data RX: Handle 1 flags 0x02 dlen 11\n BR/EDR SMP: Pairing Request (0x01) len 6\n @ MGMT Event: Authentication Failed (0x0011) plen 8\n Status: Authentication Failed (0x05)\n \u003c HCI Command: Read Encryption Key Size (0x05|0x0008) plen 2\n \u003e HCI Event: Command Complete (0x0e) plen 7\n Key size: 16\n \u003c ACL Data TX: Handle 1 flags 0x00 dlen 6\n BR/EDR SMP: Pairing Failed (0x05) len 1\n Reason: Encryption key size (0x06)\n\nMark the connection with HCI_CONN_ENC_KEY_SIZE_PEND while the key size\nis read and hold incoming L2CAP data back in pending_rx meanwhile,\nprocessing it once the reply is handled.\n\nFound with mgmt-tester \"Pairing Acceptor - SMP over BR/EDR 2\" under User\nMode Linux time travel, where the emulated peer always replies before\nthe key size is read.\n\nFixes: e3f6a257a73d (\"Bluetooth: Use actual encryption key size for SMP over BR/EDR\")\nAssisted-by: OpenCode:claude-opus-5.5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "1eebde8ecede18e351ccf438f17b53d3b62a75a9", "tree": "52813f5fbf3ac5f922e9109297bfebb790fe413d", "parents": [ "f5cd268af1c6f87fb3847e98274e22b8c6324aa4" ], "author": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Fri Oct 23 17:19:10 2026 -0400" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:01 2026 -0500" }, "message": "Bluetooth: hci_core: Convert hci_conn flags to a bitmap\n\nstruct hci_conn stores its flags in a single unsigned long, but the\nHCI_CONN_* enum already has 33 entries (up to HCI_CONN_PA_SYNC_FAILED\n\u003d 32), so on 32-bit architectures set_bit()/test_bit() on the highest\nflags access memory past the flags field, aliasing the adjacent\nconn_reason field.\n\nFix this by declaring flags with DECLARE_BITMAP() sized by a new\n__HCI_CONN_NUM_FLAGS terminator so it can accommodate any number of\nflags.\n\nAssisted-by: OpenCode:claude-opus-5.5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "f5cd268af1c6f87fb3847e98274e22b8c6324aa4", "tree": "a39d16dec222229b1464b6a2391e9e0d6db255db", "parents": [ "f92b7bca985205082c86140d0bd7c86c5be00efc" ], "author": { "name": "Kevin Dewald", "email": "kevin@simpleble.org", "time": "Fri Oct 23 12:14:37 2026 -0700" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:01 2026 -0500" }, "message": "Bluetooth: hci_event: Clear explicit connect state on LE connection\n\nSince commit 6cd29ec6ae5e (\"Bluetooth: hci_sync: Wait for proper events\nwhen connecting LE\"), create_le_conn_complete() only runs once the LE\nConnection Complete event has been handled, and le_conn_complete_evt()\nhas already removed the connection parameters from pend_le_conns by\nthen. hci_connect_le_scan_cleanup() looks the parameters up in\npend_le_conns, so after a successful connection it no longer clears\nexplicit_connect, nor deletes the parameters that were only created for\nthe explicit connect.\n\nThe parameters of every device connected through an explicit connect,\nsuch as an L2CAP or ATT connect or MGMT Pair Device, are thus left with\nexplicit_connect set. MGMT Remove Device for all devices then keeps\nthem as HCI_AUTO_CONN_EXPLICIT instead of freeing them, and if the\ndevice was set to auto-connect and is disconnected, they also stay on\npend_le_conns: the kernel keeps scanning for the device and connects to\nit as soon as it advertises, although no one asked for it any more.\n\nDo the cleanup in le_conn_complete_evt() instead, where the explicit\nconnect request is fulfilled: clear explicit_connect, delete the\nparameters if they only existed for it, and put report parameters back\non pend_le_reports. Auto-connect parameters are added back to\npend_le_conns on disconnection, as before. Update the comment in\nhci_explicit_conn_params_set() that names hci_connect_le_scan_cleanup()\nas the only place deleting them.\n\nFixes: 6cd29ec6ae5e (\"Bluetooth: hci_sync: Wait for proper events when connecting LE\")\nAssisted-by: Claude:claude-opus-5.5\nSigned-off-by: Kevin Dewald \u003ckevin@simpleble.org\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "f92b7bca985205082c86140d0bd7c86c5be00efc", "tree": "6ec160179a5193c90b13b5aa72d70ca9321ad69b", "parents": [ "19b4e5701712f74d005cc66a36374559e8dfd281" ], "author": { "name": "Catherine L", "email": "catherine.l@intel.com", "time": "Fri Oct 23 11:30:26 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:01 2026 -0500" }, "message": "Bluetooth: btintel: fix buffer over-read in fw payload\n\nThe firmware decoder cast fw_ptr + frag_len to struct\nhci_command_hdr and read cmd-\u003eplen before confirming the\nheader and payload still fit in the remaining firmware\nbuffer.\n\nAdd explicit bounds checks before each dereference:\n1. Reject if the command header is not fully contained\n in remain.\n2. Reject if the full command including payload exceeds\n remain.\n3. Log the offending fragment length and remaining size\n before returning -EINVAL.\n\nFixes: fbbe83c52bc0d (\"Bluetooth: btintel: Create common function for firmware download\")\nSigned-off-by: Catherine L \u003ccatherine.l@intel.com\u003e\nTested-by: Kiran K \u003ckiran.k@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "19b4e5701712f74d005cc66a36374559e8dfd281", "tree": "54849b64d99d596757ea2a958c74af078ef7178f", "parents": [ "56ed6b127a27c418dc2daa3fd076539d8fe69c4c" ], "author": { "name": "Akhil Arul", "email": "akhilarul324@gmail.com", "time": "Fri Oct 23 21:46:09 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:01 2026 -0500" }, "message": "Bluetooth: hci_core: Fix queuing rx_work while workqueue is drained\n\nhci_recv_frame() drops a frame unless HCI_UP or HCI_INIT is set, but the\ncheck is not synchronized with hci_dev_close_sync(). A driver can pass\nthe check, then close clears HCI_UP, flushes rx_work and starts\ndrain_workqueue(), and the late queue_work() of rx_work hits the\ndraining workqueue:\n\n workqueue: cannot queue hci_rx_work on wq hci0\n WARNING: kernel/workqueue.c:2352 at __queue_work+0x2c0/0x780\n Call Trace:\n queue_work_on+0xb2/0xc0\n hci_recv_frame+0x18f/0x330\n vhci_write+0x174/0x240\n vfs_write+0x271/0x680\n ksys_write+0x7c/0x110\n\nSkipping the queue_work() while HCI_CMD_DRAIN_WORKQUEUE is set, as done\nfor tx_work, does not work for rx_work: the flag covers the whole close,\nand events still have to be received in that window, for the commands\nsent by hdev-\u003eshutdown() and for the reset done with\nHCI_QUIRK_RESET_ON_CLOSE.\n\nRun hci_recv_frame() under rcu_read_lock() and wait with\nsynchronize_rcu() once HCI_UP has been cleared, so that every caller\nwhich still saw HCI_UP has queued its work before the workqueue is\ndrained, and later callers drop the frame.\n\nHCI_INIT does not reopen that window. Apart from the\nHCI_QUIRK_RESET_ON_CLOSE reset, which runs after drain_workqueue() has\nreturned, it is only set by hci_dev_init_sync() during open, and open\nand close are serialized by hci_req_sync_lock. So once the grace period\nhas ended, nothing can pass the check and queue rx_work until the drain\nis over.\n\nTested in qemu with the syzbot C reproducer, one run per boot: the\nwarning showed up on 12 of 30 boots before and on none of 42 boots after.\nBringing a vhci controller up and down 50 times behaves the same with\nand without this change.\n\nFixes: 76727c02c1e1 (\"Bluetooth: Call drain_workqueue() before resetting state\")\nReported-by: syzbot+2344fb8002f3ef5b1712@syzkaller.appspotmail.com\nCloses: https://syzkaller.appspot.com/bug?extid\u003d2344fb8002f3ef5b1712\nSigned-off-by: Akhil Arul \u003cakhilarul324@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "56ed6b127a27c418dc2daa3fd076539d8fe69c4c", "tree": "3e85245256db11c4ca667e9b7177f4bfd8d60cd1", "parents": [ "737139f4157d302292a6b937d96922879ecabfa3" ], "author": { "name": "Valentin Kindschi", "email": "valentin.kindschi@fiveco.ch", "time": "Tue Oct 20 12:51:50 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:01 2026 -0500" }, "message": "Bluetooth: hci_sync: pause advertising for the scan address update\n\nhci_active_scan_sync() programs a non-resolvable private address with LE\nSet Random Address on every active scan start.\n\nBLUETOOTH CORE SPECIFICATION Vol 4, Part E, 7.8.4 says the controller\nshall return Command Disallowed (0x0C) for that command while legacy\nadvertising or scanning is enabled. hci_pause_addr_resolution(), called\njust above, only stops advertising when LL privacy is in use, so on a\ncontroller without it the command is issued while advertising is still\non:\n\n Bluetooth: hci0: Opcode 0x2005 failed: -16\n\nIt does not converge either. hdev-\u003erandom_addr is only set on a\nsuccessful command complete, so it stays BDADDR_ANY, and the deferral\nadded by commit c2994b008492 (\"Bluetooth: hci_sync: Fix not setting\nRandom Address when required\") requires it to be set. Unlike the\nresolvable address a few lines above, which is reused while rpa_valid(),\nthe non-resolvable one is regenerated and rewritten on every call, so a\ncontroller that refuses the write is asked again at the scan restart\nperiod of about 10 s, for as long as discovery keeps restarting.\nObserved on a BCM43455, which has no LL privacy and no extended\nadvertising, 190 rejections in one capture, every one retrying the same\naddress:\n\n \u003c LE Set Random Address Address: 02:16:91:90:F1:D4 (Non-Resolvable)\n \u003e Command Complete LE Set Random Address, Command Disallowed\n \u003c LE Set Random Address Address: 26:90:57:96:9A:3E (Non-Resolvable)\n \u003e Command Complete LE Set Random Address, Command Disallowed\n\nPause advertising for the address update, and resume it once the update\nis done and before the scan is started. The pause does not outlive the\nfunction: it is taken only when nothing else holds it, and every exit\nresumes advertising, which also releases the pause taken by\nhci_pause_addr_resolution(). A failed pause returns before marking\nanything paused, so the error path is a no-op.\n\nThe resume in the error path is no longer guarded by ll_privacy_capable().\nThat guard matched a pause taken only under LL privacy; the pause added\nhere is unconditional, and hci_resume_advertising_sync() returns early\nwhen nothing was paused.\n\nOne caveat this widens, raised on the previous posting. When\nHCI_ADVERTISING is set, hci_pause_advertising_sync() also clears\nHCI_DISCOVERABLE and HCI_LIMITED_DISCOVERABLE and zeroes discov_timeout,\nand hci_resume_advertising_sync() restores only HCI_ADVERTISING, so the\ndiscoverable state is lost. It reproduces today on an LL privacy\ncontroller through hci_pause_addr_resolution(); the unconditional pause\nmakes it reachable without LL privacy as well. hci_suspend_sync() also\npauses unconditionally, so a device that suspends loses the same state\non any controller today. That asymmetry is pre-existing and is left\nalone here rather than folded into a scan path fix.\n\nLegacy controllers have one random address register, shared by the\nscanner and the advertiser. Restoring the advertiser here can reprogram\nit when the advertiser is non-connectable, so the scan then uses that\naddress rather than the one generated for it. Both are non-resolvable\nand neither is linkable to the identity address. With privacy enabled\nboth roles already share one resolvable address the same way.\n\nWith the patch, on the same hardware:\n\n \u003c LE Set Advertising Enable Enable: 0x00 Success\n \u003c LE Set Random Address Success\n \u003c LE Set Advertising Parameters Success\n \u003c LE Set Advertising Enable Enable: 0x01 Success\n \u003c LE Set Scan Parameters Success\n \u003c LE Set Scan Enable Enable: 0x01 Success\n\nThe address write is accepted, and advertising is restored before the\nscan is started.\n\nOver 119369 btmon records and about 12 minutes of the normal workload of\nthat device, alternating active and passive scanning with ten outgoing\nconnection attempts, every LE Set Random Address succeeded and there were\nno Command Disallowed responses of any opcode, against one per scan\nrestart before.\n\nPatch 1 is required: without it the resume added here returns -EPERM on\nthe controllers this fixes and leaves advertising disabled.\n\nFixes: 3c44a431d62b (\"Bluetooth: hci_sync: Resume adv with no RPA when active scan\")\nCc: stable@vger.kernel.org\nAssisted-by: Claude:claude-opus-5.5 btmon\nSigned-off-by: Valentin Kindschi \u003cvalentin.kindschi@fiveco.ch\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "737139f4157d302292a6b937d96922879ecabfa3", "tree": "77b08d2f5776b495da892ff1d32d70c7a1cd18fa", "parents": [ "4335849380aa1081ee9a1c2b934cbdda0961fa57" ], "author": { "name": "Valentin Kindschi", "email": "valentin.kindschi@fiveco.ch", "time": "Tue Oct 20 12:51:49 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:01 2026 -0500" }, "message": "Bluetooth: hci_sync: re-enable legacy advertising on resume\n\nhci_resume_advertising_sync() never re-enables advertising on a\ncontroller without extended advertising.\n\nIt restores HCI_ADVERTISING from advertising_old_state, then calls\nhci_schedule_adv_instance_sync(), which starts with:\n\n if (hci_dev_test_flag(hdev, HCI_ADVERTISING) \u0026\u0026 !ext_adv_capable(hdev))\n return -EPERM;\n\nThe flag it tests was set a few lines earlier by the resume itself, so\nthe call returns -EPERM without sending anything. The return value is\ndiscarded by every caller, so the failure is silent: advertising_paused\nis cleared, HCI_ADVERTISING is set, and the controller is not\nadvertising.\n\nObserved on a BCM43455 (no extended advertising) after an active scan:\nbtmon shows the pause disabling advertising and no re-enable in the ten\nseconds that follow, the device does not appear in another controller\u0027s\nscan, and btmgmt info still reports \"advertising\" in current settings.\n\nEnable instance 0x00 directly in that case, the way reenable_adv_sync()\nalready does for the same situation. Instances continue to go through\nhci_schedule_adv_instance_sync() so the software rotation loop is\nrearmed.\n\nThis affects every caller of hci_resume_advertising_sync(), not only the\nscan path: address resolution changes, accept list updates, discovery\nstop, suspend/resume and the end of an LE connection attempt all leave\nadvertising disabled on such a controller today.\n\nThe resume does nothing when the controller is already advertising, as\nit is after directed advertising was started for a peripheral\nconnection, so it does not replace that advertising.\n\nerr is initialised because the extended branch leaves it unset when\nadv_instances is empty and HCI_LE_ADV_0 is clear.\n\nFixes: ad383c2c65a5 (\"Bluetooth: hci_sync: Enable advertising when LL privacy is enabled\")\nCc: stable@vger.kernel.org\nAssisted-by: Claude:claude-opus-5.5 btmon\nSigned-off-by: Valentin Kindschi \u003cvalentin.kindschi@fiveco.ch\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "4335849380aa1081ee9a1c2b934cbdda0961fa57", "tree": "5f3a7a6668a5d5010a2111628e138b7b7b72805f", "parents": [ "ae9c8df1ffb84560ac01cbdc26cfb19027f4d25f" ], "author": { "name": "Binbin Deng", "email": "18983559317@163.com", "time": "Mon Oct 19 18:56:24 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:00 2026 -0500" }, "message": "Bluetooth: hci_core: Initialize LTK before publication\n\nhci_add_ltk() publishes a newly allocated LTK on hdev-\u003elong_term_keys\nbefore initializing its address, type, value, authentication state,\nencryption size, EDIV, and random value. hci_find_ltk() and the debugfs\nlong_term_keys_show() traverse this list under RCU and can therefore see\na zero or partially initialized key before those stores complete.\n\nThe race is reachable by racing an LTK addition with another CPU looking\nup or dumping long-term keys. For example, userspace can issue\nMGMT_OP_LOAD_LONG_TERM_KEYS while another process reads the corresponding\ndebugfs file.\n\nInitialize all fields of a new LTK before list_add_rcu() makes it visible\nto RCU readers. Existing LTKs remain published and continue to be updated\nin place.\n\nFound during a static-analysis-assisted audit: candidate sites were\nsurfaced by a Coccinelle rule, and the reader/writer paths were\nconfirmed by LLM-assisted (GLM-5.3) code inspection. The issue was\nnot observed at runtime; it is identified by code inspection only.\n\nFixes: 970d0f1b2803 (\"Bluetooth: Convert LTK list to RCU\")\nAssisted-by: GLM-5.3 coccinelle\nSigned-off-by: Binbin Deng \u003c18983559317@163.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "ae9c8df1ffb84560ac01cbdc26cfb19027f4d25f", "tree": "263105a11f49348faac23d5a43e13de7fef14c37", "parents": [ "f0cf5a24cefeb629876bd15d668ff062c8655e28" ], "author": { "name": "Binbin Deng", "email": "18983559317@163.com", "time": "Mon Oct 19 16:17:11 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:00 2026 -0500" }, "message": "Bluetooth: hci_core: Initialize link key before publication\n\nhci_add_link_key() allocates a new link key with kzalloc(), inserts it into\nhdev-\u003elink_keys with list_add_rcu(), and only then initializes its address,\nvalue, type, and PIN length. RCU readers such as hci_find_link_key()\nand the debugfs link_keys_show() do not take hci_dev_lock, so they can\ntraverse the new entry during that initialization window and observe\na zero or partially initialized key.\n\nThis can be triggered by racing a link-key update with another CPU looking\nup or dumping keys. In particular, userspace can issue\nMGMT_OP_LOAD_LINK_KEYS while another process reads the corresponding\ndebugfs file.\n\nComplete all fields of a newly allocated key before publishing it with\nlist_add_rcu(). Existing keys remain visible and keep their current\nin-place update behavior.\n\nFound during a static-analysis-assisted audit: candidate sites were\nsurfaced by a Coccinelle rule, and the reader/writer paths were\nconfirmed by LLM-assisted (GLM-5.3) code inspection. The issue was\nnot observed at runtime; it is identified by code inspection only.\n\nFixes: 0378b5977013 (\"Bluetooth: Convert link keys list to use RCU\")\nSigned-off-by: Binbin Deng \u003c18983559317@163.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "f0cf5a24cefeb629876bd15d668ff062c8655e28", "tree": "e4e7b2aadbb59cf95025a75c6a14d8fe3ed3605e", "parents": [ "fb1baa000d7a0b597ab9eb29b179b03e70e5f6ee" ], "author": { "name": "Binbin Deng", "email": "18983559317@163.com", "time": "Mon Oct 19 19:16:11 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:00 2026 -0500" }, "message": "Bluetooth: hci_core: Initialize IRK before publication\n\nhci_add_irk() initializes the identity address and address type of a newly\nallocated IRK, publishes it on hdev-\u003eidentity_resolving_keys, and only then\ninitializes its value and RPA. RCU readers such as hci_find_irk_by_rpa()\nand the debugfs identity_resolving_keys_show() can traverse the new entry\nduring that window and see a zero or partially initialized IRK.\n\nThe race is reachable by racing an IRK addition with another CPU resolving\nor dumping IRKs. In particular, userspace can issue MGMT_OP_LOAD_IRKS\nwhile another process reads the corresponding debugfs file or triggers RPA\nresolution.\n\nInitialize the IRK value and RPA before publishing a newly allocated IRK.\nExisting IRKs remain published and continue to be updated in place.\n\nFound during a static-analysis-assisted audit: candidate sites were\nsurfaced by a Coccinelle rule, and the reader/writer paths were\nconfirmed by LLM-assisted (GLM-5.3) code inspection. The issue was\nnot observed at runtime; it is identified by code inspection only.\n\nFixes: adae20cb2d20 (\"Bluetooth: Convert IRK list to RCU\")\nAssisted-by: GLM-5.3 coccinelle\nSigned-off-by: Binbin Deng \u003c18983559317@163.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "fb1baa000d7a0b597ab9eb29b179b03e70e5f6ee", "tree": "11b59404bc8b1177524bd207a2be0228260b07c9", "parents": [ "c3e67bd82b9b9b1a5118f09a429ccefe2aab0741" ], "author": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Oct 15 11:37:52 2026 -0400" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Nov 02 17:09:00 2026 -0500" }, "message": "Bluetooth: hci_sync: Fix invalid Supervision_Timeout in LE Set Default Rate\n\nThe LE Set Default Rate Parameters command is rejected with Invalid HCI\nCommand Parameters (0x12) because the Supervision_Timeout of 120 ms is\nexactly the minimum recommended by HOGP v1.2:\n\n Greater than or equal to (1 + Peripheral Latency) x Subrate max x\n Connection Interval max x 2\n\nBut the Core spec treats the equality as invalid:\n\nBLUETOOTH CORE SPECIFICATION Version 6.3 | Vol 4, Part E\n7.8.158. LE Set Default Rate Parameters command\n\n If Connection_Interval_Max x Subrate_Max x (Max_Latency + 1) is\n greater than or equal to Supervision_Timeout x 40, the Controller\n shall return the error code Invalid HCI Command Parameters (0x12).\n\nWith the current values 0x78 x 4 x 1 \u003d 480 \u003e\u003d 0x0c x 40 \u003d 480.\n\nFix this by using 2 s as the default Supervision_Timeout, which is 10x\nlower than the 20 s used for non-SCI connections while still well above\nthe minimum required, and make sure it remains above the minimum in\ncase interval_max is raised to match the controller\u0027s minimum supported\nconnection interval.\n\nFixes: 2f8784cfe8a9 (\"Bluetooth: Add support for Shorter Connection Interval (SCI) feature\")\nAssisted-by: OpenCode:claude-opus-5.5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "c3e67bd82b9b9b1a5118f09a429ccefe2aab0741", "tree": "d3bbde02f6c33028fedfa43bcae72e9d162f8ba7", "parents": [ "3ae20e4697eb969104fe4b1e98a675f0100382b6" ], "author": { "name": "Yingjie Wang", "email": "1075151112@qq.com", "time": "Fri Oct 30 15:30:56 2026 +0800" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 22:31:32 2026 +0100" }, "message": "ipv6: reject wrapped temporary address preferred lifetimes\n\nipv6_create_tempaddr() raises a temporary address\u0027s preferred lifetime to\nregen_advance + age + 1 when the configured lifetime is too short. The\nresult is stored in a u32, while regen_advance and age are unsigned long.\nIf the sum wraps or is truncated, the stored lifetime can still be less\nthan or equal to regen_advance + age.\n\naddrconf_verify_rtnl() then sees the new address as due for regeneration\nand creates another one. Temporary addresses are not limited by\nmax_addresses since commit 4b08a8f1bd8c (\"ipv6: remove max_addresses\ncheck from ipv6_create_tempaddr\"), so this can cause unbounded address\ngrowth. With dad_transmits set to -1, a baseline kernel reached 2859\nloopback addresses in two seconds.\n\nAfter storing the adjusted lifetime, verify that it is still greater than\nregen_advance + age. Reject the new address if the check fails.\n\nOn an x86-64 KASAN kernel, the normal configuration created three IPv6\naddresses. The negative dad_transmits, positive multiplication overflow,\nand large retransmission-time cases each left only the loopback and public\naddresses. An i386 defconfig and an x86-64 allmodconfig both built\naddrconf.o with W\u003d1.\n\nFixes: f4bcbf360ac8 (\"net: ipv6/addrconf: clamp preferred_lft to the minimum required\")\nCc: stable@vger.kernel.org\nSuggested-by: Ido Schimmel \u003cidosch@nvidia.com\u003e\nLink: https://lore.kernel.org/netdev/20261029175827.GA1411453@shredder/\nSigned-off-by: Yingjie Wang \u003c1075151112@qq.com\u003e\nReviewed-by: Ido Schimmel \u003cidosch@nvidia.com\u003e\nReviewed-by: Alex Henrie \u003calexhenrie24@gmail.com\u003e\nLink: https://patch.msgid.link/tencent_7A270291DDE5CD89DAFFE8A745D094D5BD06@qq.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "3ae20e4697eb969104fe4b1e98a675f0100382b6", "tree": "cfa65fee4df6c6f16af03aeadd752b2500ed5a12", "parents": [ "7308ef8b4a6779a39f68d053c19b53a5c584a663" ], "author": { "name": "Eric Dumazet", "email": "edumazet@kernel.org", "time": "Fri Oct 30 09:12:25 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 22:00:27 2026 +0100" }, "message": "inet: frags: limit the truesize of a reassembly queue\n\nThe truesize of fragments in a reassembly queue is only bounded by\nthe per netns ipfrag_high_thresh sysctl, which has no upper limit.\n\ninet_frag_reasm_finish() sums the truesize of all fragments in an int.\nIf this sum reaches 2^32, it wraps, and the final sk_wmem_alloc\nadjustment of the socket owning the reassembled skb can cancel its own\nreference, leading to a use-after-free of this socket.\n\nThis can be triggered from an unprivileged user/network namespace,\nraising ipfrag_high_thresh and using padded TUN packets, which keep\na large truesize after being trimmed by ip_rcv_core().\n\nTrack the sum of the truesize of fragments in each queue, and refuse\na fragment that would make it bigger than INT_MAX / 2. Callers kill\nthe queue on this error. This bound is far above the needs of\nlegitimate traffic.\n\nFixes: 18685451fc4e (\"inet: inet_defrag: prevent sk release while still in use\")\nCc: stable@vger.kernel.org\nReported-by: Kyle Zeng \u003ckylebot@openai.com\u003e\nCc: Florian Westphal \u003cfw@strlen.de\u003e\nSigned-off-by: Eric Dumazet \u003cedumazet@kernel.org\u003e\nReviewed-by: Ido Schimmel \u003cidosch@nvidia.com\u003e\nReviewed-by: Jiayuan Chen \u003cjiayuan.chen@linux.dev\u003e\nTested-by: Wang Zhan \u003cwang.zhan@smartx.com\u003e\nLink: https://patch.msgid.link/20261030081225.2575462-1-edumazet@kernel.org\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "7308ef8b4a6779a39f68d053c19b53a5c584a663", "tree": "8ea9146a5bad49916f5a97321724a0944d0013d7", "parents": [ "e55f9e70b8ae6fc01550343e43874f59784dc5c7" ], "author": { "name": "Ido Schimmel", "email": "idosch@nvidia.com", "time": "Fri Oct 30 15:37:50 2026 +0200" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 17:07:43 2026 +0100" }, "message": "vxlan: Stop rejecting dynamic FDB entries with a nexthop ID\n\nCommit 98fc57d16744 (\"vxlan: reject dynamic fdb entries that reference a\nnexthop id\") started rejecting FDB entries that point to FDB nexthops\nunless they are configured as \"permanent\" or \"static\". The intent was to\nprevent such entries from being aged out by vxlan_cleanup(), which runs\nwithout RTNL and can therefore race with other VXLAN devices that modify\nthe same per-nexthop FDB list.\n\nHowever, FRR installs remote MACs that are behind a multihomed Ethernet\nSegment (EVPN-MH) as dynamic FDB entries that point to an FDB nexthop\ngroup. Since the above commit, these entries are rejected and traffic\ntowards the corresponding MACs is flooded to all the remote VTEPs.\n\nThese entries are also marked as externally learned (\"extern_learn\")\nand are therefore skipped by vxlan_cleanup(), but exempting externally\nlearned entries from the checks is not enough: vxlan_cleanup() reads\nthe state and flags of an entry without the hash lock, so an entry that\nis concurrently changed from dynamic and externally learned to static\ncan still be aged out.\n\nInstead, remove the checks added by the above commit and make\nvxlan_cleanup() skip FDB entries that point to FDB nexthops. Such\nentries can only be configured from user space, cannot be learned and\ncannot roam, so there is no reason to age them out. The nexthop pointer\nof an FDB entry is set before the entry is linked and is only cleared\nafter it was unlinked and an RCU grace period has passed, so it can be\nchecked without the hash lock.\n\nAdjust the test cases added by the above commit and add a test case\nthat checks that dynamic FDB entries that point to FDB nexthops are not\naged out. Without the fix:\n\n # ./fib_nexthops.sh -t \"ipv4_fdb_grp_fcnal ipv6_fdb_grp_fcnal\"\n\n IPv4 fdb groups functional\n --------------------------\n [...]\n TEST: Fdb mac add with nexthop group and dynamic state [FAIL]\n TEST: Fdb mac add with nexthop group and extern_learn [FAIL]\n TEST: Fdb mac without nexthop group aged out [ OK ]\n TEST: Fdb mac with nexthop group not aged out [FAIL]\n [...]\n\n IPv6 fdb groups functional\n --------------------------\n [...]\n TEST: Fdb mac add with nexthop group and dynamic state [FAIL]\n TEST: Fdb mac add with nexthop group and extern_learn [FAIL]\n TEST: Fdb mac without nexthop group aged out [ OK ]\n TEST: Fdb mac with nexthop group not aged out [FAIL]\n [...]\n\n Tests passed: 44\n Tests failed: 6\n Tests skipped: 0\n\nWith the fix:\n\n # ./fib_nexthops.sh -t \"ipv4_fdb_grp_fcnal ipv6_fdb_grp_fcnal\"\n\n IPv4 fdb groups functional\n --------------------------\n [...]\n TEST: Fdb mac add with nexthop group and dynamic state [ OK ]\n TEST: Fdb mac add with nexthop group and extern_learn [ OK ]\n TEST: Fdb mac without nexthop group aged out [ OK ]\n TEST: Fdb mac with nexthop group not aged out [ OK ]\n [...]\n\n IPv6 fdb groups functional\n --------------------------\n [...]\n TEST: Fdb mac add with nexthop group and dynamic state [ OK ]\n TEST: Fdb mac add with nexthop group and extern_learn [ OK ]\n TEST: Fdb mac without nexthop group aged out [ OK ]\n TEST: Fdb mac with nexthop group not aged out [ OK ]\n [...]\n\n Tests passed: 50\n Tests failed: 0\n Tests skipped: 0\n\nFixes: 1274e1cc4226 (\"vxlan: ecmp support for mac fdb entries\")\nFixes: 98fc57d16744 (\"vxlan: reject dynamic fdb entries that reference a nexthop id\")\nCc: stable@vger.kernel.org\nReported-by: Sascha Frey \u003csf@techfak.net\u003e\nCloses: https://lore.kernel.org/netdev/20261028142928.GA8406@techfak.de/\nTested-by: Sascha Frey \u003csf@techfak.net\u003e\nSigned-off-by: Ido Schimmel \u003cidosch@nvidia.com\u003e\nReviewed-by: Nikolay Aleksandrov \u003crazor@blackwall.org\u003e\nLink: https://patch.msgid.link/20261030133750.28668-1-idosch@nvidia.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "e55f9e70b8ae6fc01550343e43874f59784dc5c7", "tree": "c8438055fc9c1fba75080833fd9e8b2fd5ce408f", "parents": [ "743b5c86276b1c3241e6f0f395b55f98f0756ef0", "23d96de472f735858a7dd227c77aebff21ea09f5" ], "author": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 16:59:45 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 16:59:45 2026 +0100" }, "message": "Merge branch \u0027net-stmmac-re-apply-taprio-offload-in-__stmmac_open-and-stmmac_resume\u0027\n\nLorenzo Bianconi says:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nnet: stmmac: re-apply taprio offload in __stmmac_open() and stmmac_resume()\n\nReconfigure MTL_EST registers after sw reset in __stmmac_open().\nRemove priv-\u003eest-\u003eenable dependency in est_configure().\nInitialize est_lock at probe time.\n\nv4: https://lore.kernel.org/r/20261026-stmmac-est-fixes-v4-0-999dac4de44f@oss.qualcomm.com\nv2: https://lore.kernel.org/r/20260829-stmmac-est-reapply-after-open-v2-1-5e5ccb185e92@oss.qualcomm.com\nv1: https://lore.kernel.org/r/20260825-stmmac-est-reapply-after-open-v1-1-dfa80735e0a1@oss.qualcomm.com\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nLink: https://patch.msgid.link/20261029-stmmac-est-fixes-v5-0-85b830a795a9@oss.qualcomm.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "23d96de472f735858a7dd227c77aebff21ea09f5", "tree": "c8438055fc9c1fba75080833fd9e8b2fd5ce408f", "parents": [ "e4f5b46dfb8ac27a822fa0b411bd4526abf5ba97" ], "author": { "name": "Lorenzo Bianconi", "email": "lorenzo.bianconi@oss.qualcomm.com", "time": "Thu Oct 29 11:33:57 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 16:59:43 2026 +0100" }, "message": "net: stmmac: re-apply taprio offload in __stmmac_open() and stmmac_resume()\n\nThe core soft reset issued by stmmac_init_dma_engine(), called from\nstmmac_hw_setup(), clears the MTL_EST registers. Nothing re-applies the\ntaprio offload afterwards, so priv-\u003eest-\u003eenable stays true while the\nhardware EST block is left disabled: taprio keeps being reported as\noffloaded, the TX/XDP paths keep dropping frames larger than\npriv-\u003eest-\u003emax_sdu[], and the programmed base time is stale.\n\nRe-apply the offload from __stmmac_open() and stmmac_resume() after PTP\nhas been brought up. The base time is recomputed from the reserved base\ntime and the current PTP time, because the timestamp counter has been\nre-initialised and the previously programmed base time cannot be reused.\n\nFactor the recompute-and-program sequence into __stmmac_setup_est(),\nwhich must be called with est_lock held, and into stmmac_setup_est(),\nwhich takes the lock and re-applies the offload only when it is\ncurrently enabled and PTP has been brought up. Use the same helper in\nstmmac_adjust_time() so the PTP adjust path shares the base time\ncomputation.\n\nOnly tc_taprio_configure() updates priv-\u003eest-\u003eenable: it is set when a\nREPLACE succeeds and cleared on DESTROY or a programming failure. The\nre-apply helpers leave it untouched, so the flag records that an offload\nis installed rather than the current hardware programming state.\n__stmmac_setup_est() only reprograms the EST block, and\nstmmac_setup_est() replays the FPE mapping afterwards. On a failed\nre-apply the open and resume callers abort, while stmmac_adjust_time()\nkeeps the offload configured.\n\nThe same reset also discards the FPE preemption programming, and on XGMAC\nstmmac_dma_tx_mode() overwrites the queue-to-traffic-class map. Save the\npreemptible traffic class mask in priv-\u003eest-\u003epclass when a REPLACE\nsucceeds and replay the FPE mapping from stmmac_setup_est() as well.\n\nRe-applying the offload is best-effort with respect to PTP:\nstmmac_setup_est() does nothing when PTP was not enabled (for example\nwhen clk_ptp_rate is 0), so a missing PTP reference clock does not by\nitself fail ndo_open(). If re-applying the EST or FPE programming fails\nwhile restoring the interface, the failure is fatal to the caller:\n__stmmac_open() aborts the open, and stmmac_resume() takes the same error\npath already used for a failed timestamp counter restore.\n\nSince __stmmac_open() and stmmac_resume() now trust priv-\u003eest-\u003eenable,\nalso make tc_taprio_configure() consistent: hold est_lock across the\nwhole validate-and-program sequence, build the gate list in a temporary\nbuffer, and only commit it and enable EST after validation and hardware\nprogramming succeed. A REPLACE rejected during validation then leaves the\ncurrently installed schedule intact in both software and hardware, while\na hardware or FPE mapping failure disables EST instead of leaving a stale\nenable flag behind. Reject cycle times whose seconds field would not fit\nin priv-\u003eest-\u003ectr[1].\n\nFixes: b60189e0392f (\"net: stmmac: Integrate EST with TAPRIO scheduler API\")\nSigned-off-by: Lorenzo Bianconi \u003clorenzo.bianconi@oss.qualcomm.com\u003e\nReviewed-by: Maxime Chevallier \u003cmaxime.chevallier@bootlin.com\u003e\nTested-by: Maxime Chevallier \u003cmaxime.chevallier@bootlin.com\u003e\nLink: https://patch.msgid.link/20261029-stmmac-est-fixes-v5-3-85b830a795a9@oss.qualcomm.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "e4f5b46dfb8ac27a822fa0b411bd4526abf5ba97", "tree": "9569b3200e6e97ce128a513a6df6cf2a20b40f50", "parents": [ "98caed39c1db002b2c34b8040ab765c5fa9c6675" ], "author": { "name": "Lorenzo Bianconi", "email": "lorenzo.bianconi@oss.qualcomm.com", "time": "Thu Oct 29 11:33:56 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 16:59:43 2026 +0100" }, "message": "net: stmmac: pass the desired EST enable state to est_configure()\n\nPass the desired EST enable state explicitly to est_configure() instead\nof having it derive from cfg-\u003eenable. This decouples the hardware\nprogramming state from the priv-\u003eest-\u003eenable flag, which records whether\nthe taprio offload is attached.\n\nNo functional change intended: the callers keep toggling\npriv-\u003eest-\u003eenable around the EST programming, as before.\n\nReviewed-by: Maxime Chevallier \u003cmaxime.chevallier@bootlin.com\u003e\nSigned-off-by: Lorenzo Bianconi \u003clorenzo.bianconi@oss.qualcomm.com\u003e\nLink: https://patch.msgid.link/20261029-stmmac-est-fixes-v5-2-85b830a795a9@oss.qualcomm.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "98caed39c1db002b2c34b8040ab765c5fa9c6675", "tree": "d11163ba9a6f64e7e566750abb10549e6982f36b", "parents": [ "743b5c86276b1c3241e6f0f395b55f98f0756ef0" ], "author": { "name": "Lorenzo Bianconi", "email": "lorenzo.bianconi@oss.qualcomm.com", "time": "Thu Oct 29 11:33:55 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 16:59:43 2026 +0100" }, "message": "net: stmmac: initialize est_lock at probe time\n\npriv-\u003eest is allocated with devm_kzalloc() on the first TAPRIO REPLACE\nand priv-\u003eest_lock is initialized in the same place, which ties the\nvalidity of the lock to whether TAPRIO has ever been configured. The\nlock is also never destroyed.\n\nInitialize priv-\u003eest_lock in __stmmac_dvr_probe() next to priv-\u003elock\nand destroy it in stmmac_dvr_remove(). This keeps the lock valid for\nthe entire lifetime of the device, independent of the TAPRIO state,\nand removes the lazy initialization from the TAPRIO configuration\npath.\n\nNo functional change intended.\n\nReviewed-by: Maxime Chevallier \u003cmaxime.chevallier@bootlin.com\u003e\nSigned-off-by: Lorenzo Bianconi \u003clorenzo.bianconi@oss.qualcomm.com\u003e\nLink: https://patch.msgid.link/20261029-stmmac-est-fixes-v5-1-85b830a795a9@oss.qualcomm.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "743b5c86276b1c3241e6f0f395b55f98f0756ef0", "tree": "10d814d1a4a702d62a93d0fc97527d7ccaaf2025", "parents": [ "d1cf56164dc25c2c54853b23eab42369f53c8329" ], "author": { "name": "Joonhoe Kim", "email": "26rote@gmail.com", "time": "Thu Oct 29 19:51:42 2026 +0900" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 16:39:52 2026 +0100" }, "message": "net: qrtr: announce local services again once our HELLO is sent\n\nSince commit 544d85de4dc2 (\"net: qrtr: Send HELLO message on endpoint\nregister\"), qrtr_node_enqueue() drops every packet but HELLO with\n-EAGAIN until our HELLO has gone out to the node. When the remote\u0027s\nHELLO arrives first, the NEW_SERVER replies from the name service are\ndropped, and so are the broadcasts for services registered before our\nHELLO goes out. Nothing announces these services again, so the remote\nnever learns about them.\n\nOn Kaanapali the modem sends its HELLO before it accepts ours. With\nrmtfs started first, the modem never learns about rmtfs and its\nwatchdog resets the SoC about 40 s later.\n\nRemember that the remote has sent a HELLO. Once our HELLO has been\nsent to such a node, pass a HELLO from it to the local name service\nagain, so that it announces the services it has at that point. Retry\nthe replay if it cannot be queued, and queue it under ep_lock only\nwhile the endpoint is registered, so that it cannot follow the BYE\nfrom qrtr_endpoint_unregister().\n\nThe flag is not cleared when qrtr_endpoint_hello() restarts the\nhandshake on resume, so a HELLO that the remote sent before then is\nnot lost. The cost is that the remote gets the same NEW_SERVER\nannouncements twice when its HELLO arrives before ours goes out but\nthe name service handles it after, and on every resume.\n\nFixes: 544d85de4dc2 (\"net: qrtr: Send HELLO message on endpoint register\")\nCc: stable@vger.kernel.org\nTested-by: Filippo Falezza \u003ceffeffe99@gmail.com\u003e # Motorola Moto G 5G Plus nairo (SM7250)\nSigned-off-by: Joonhoe Kim \u003c26rote@gmail.com\u003e\nLink: https://patch.msgid.link/20261029105142.2503-1-26rote@gmail.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "d1cf56164dc25c2c54853b23eab42369f53c8329", "tree": "39a1000eb85911be895459d547307bdd732e6ec2", "parents": [ "f38bce9af9e2a3cced7d303a1476f21c1f42bcb7" ], "author": { "name": "Nguyen Ngoc Thang", "email": "ngocthang2710.1999@gmail.com", "time": "Thu Oct 29 21:24:23 2026 +0700" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 16:09:39 2026 +0100" }, "message": "net: phy: don\u0027t require RTNL to detach a PHY from an unregistered netdev\n\nphy_detach_internal() reads dev-\u003ehwprov with rtnl_dereference(), but\nMAC drivers commonly attach and detach PHYs while their net_device is\nnot registered, without holding RTNL. Before register_netdev(), a failed\nphylink_connect_phy() or phy_attach_direct() unwinds through\nphy_detach_internal(). After unregister_netdev(), a driver\u0027s remove path\nmay call phy_disconnect(). Both trip lockdep:\n\n WARNING: suspicious RCU usage\n drivers/net/phy/phy_device.c:1831 suspicious rcu_dereference_protected() usage!\n phy_detach_internal+0x6a5/0x830 drivers/net/phy/phy_device.c:1831\n phylink_connect_phy+0x22e/0x2b0 drivers/net/phy/phylink.c:2452\n ax88772_bind+0xbb1/0x1520 drivers/net/usb/asix_devices.c:925\n usbnet_probe+0xbb3/0x27e0 drivers/net/usb/usbnet.c:1812\n\nsyzbot hits this with an emulated asix device. phy_eee_rx_clock_stop()\nfails on a USB MDIO error, so phylink_bringup_phy() fails and the PHY is\ndetached from inside usbnet_probe(), before the netdev is registered.\n\nhwprov is only set through ethtool, under RTNL, on a registered device.\nreg_state also changes only under RTNL. So if the device is not\nregistered, no one else can reach hwprov, and RTNL is not needed. Tell\nlockdep that. A detach from a registered device without RTNL still\nwarns.\n\nFixes: 35f7cad1743e (\"net: Add the possibility to support a selected hwtstamp in netdevice\")\nReported-by: syzbot+583f42a41879bb60de32@syzkaller.appspotmail.com\nCloses: https://syzkaller.appspot.com/bug?extid\u003d583f42a41879bb60de32\nSigned-off-by: Nguyen Ngoc Thang \u003cngocthang2710.1999@gmail.com\u003e\nReviewed-by: Kory Maincent \u003ckory.maincent@bootlin.com\u003e\nLink: https://patch.msgid.link/20261029142423.93573-1-ngocthang2710.1999@gmail.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "f38bce9af9e2a3cced7d303a1476f21c1f42bcb7", "tree": "8e0b6dd352edd3b10db36912db65e32321c863a7", "parents": [ "873363ac591a1774aa3ced84f7ea3d93a3eb9b07" ], "author": { "name": "Bryam Vargas", "email": "hexlabsecurity@proton.me", "time": "Wed Oct 28 23:47:13 2026 -0500" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 15:39:42 2026 +0100" }, "message": "net/iucv: take a private, writable frame before rewriting it in place\n\nafiucv_hs_rcv() rewrites the frame in place -- EBCASC() on four name\nfields, then afiucv_swap_src_dest() swaps them and pushes an Ethernet\nheader -- and can hand the same skb to dev_queue_xmit(), without making\nit private first, so a packet socket that also gets the frame reads the\nrewritten names. An ETH_P_ALL tap runs first and leaves af_iucv a\ncloned skb; a socket opened for ETH_P_AF_IUCV sits on a ptype_specific\nlist, walked after ptype_base[], so deliver_skb() takes a reference and\naf_iucv runs on an skb that is shared but not cloned.\n\nUnshare, then cow, in that order: skb_cow() can reach\npskb_expand_head(), which has BUG_ON(skb_shared()). skb_cow() tests\nskb_cloned(), which is what a rewrite of the data needs; skb_cow_head()\ntests only the header. Asking for ETH_HLEN also covers the unchecked\npush in afiucv_swap_src_dest(); on the ordinary path eth_type_trans()\nhas already pulled that much, so it only compares.\n\nFixes: 3881ac441f64 (\"af_iucv: add HiperSockets transport\")\nCloses: https://sashiko.dev/#/patchset/20260813-b4-disp-60433a46-v1-1-509e1200533e@proton.me?part\u003d1\nSigned-off-by: Bryam Vargas \u003chexlabsecurity@proton.me\u003e\nReviewed-by: Simon Horman \u003chorms@kernel.org\u003e\nLink: https://patch.msgid.link/20261028-b4-disp-1edbbc34-v3-1-13495411f5b9@proton.me\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "873363ac591a1774aa3ced84f7ea3d93a3eb9b07", "tree": "d03127bc1e8cda62e2bce4c2b51481c84c8f4f6c", "parents": [ "c1f04ea0aa0f8799a303dc412b3a4820f2aedfe5" ], "author": { "name": "Daniel Machon", "email": "daniel.machon@microchip.com", "time": "Thu Oct 29 12:48:10 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 15:31:20 2026 +0100" }, "message": "net: sparx5/lan969x: release the in-flight slot of a stale TX skb\n\nsparx5_ptp_txtstamp_request() counts every two step TX skb waiting for\nits timestamp in sparx5-\u003eptp_skbs, and refuses new ones once\nSPARX5_MAX_PTP_ID are in flight. sparx5_ptp_txtstamp_old_release()\nfrees the skbs that have waited longer than SPARX5_PTP_TIMEOUT.\n\nBefore this patch, old_release() does not decrement ptp_skbs, so every\nskb whose timestamp never arrives, for example because the switch\ndiscarded the frame, keeps its slot forever. Once SPARX5_MAX_PTP_ID\nslots are lost, two step frames fail to transmit on every port of the\nswitch.\n\nReturn the number of released skbs from old_release() and subtract it\nfrom ptp_skbs in txtstamp_request(), under the ptp_ts_id_lock it already\ntakes.\n\nThis fixes the accounting only. A port\u0027s stale skbs are still aged out\nonly when that port sends a two step frame, so a port that stops sending\nthem keeps its stale skbs, and their slots, until it sends one again.\nThat behaviour is unchanged by this patch.\n\nFound by an AI code review agent. Reproduced on a lan9696 board with a\nmodified kernel that drops the TX timestamps of two step frames, after\nwhich two step timestamping stopped working on the port. With the fix,\ntimestamping keeps working on that board and on a sparx5 PCB135 board.\n\nFixes: 70dfe25cd866 (\"net: sparx5: Update extraction/injection for timestamping\")\nSigned-off-by: Daniel Machon \u003cdaniel.machon@microchip.com\u003e\nReviewed-by: Simon Horman \u003chorms@kernel.org\u003e\nLink: https://patch.msgid.link/20261029-sparx5-ptp-stale-tx-slot-v1-1-ec15f391bbb7@microchip.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "c1f04ea0aa0f8799a303dc412b3a4820f2aedfe5", "tree": "6702611641476b127519feeb46c2261f664ae9c2", "parents": [ "2d02191779345b13de91048db441191b20264d16" ], "author": { "name": "Xia Yan", "email": "yana06070@163.com", "time": "Thu Oct 29 10:42:59 2026 +0800" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 15:24:58 2026 +0100" }, "message": "selftests: net: check veth carrier after changing channel counts\n\nExtend veth.sh to check that changing channel counts preserves carrier\nstate. When only one end is up, the running end must not report LOWER_UP.\n\nCover up/up and both mixed up/down combinations. Resize RX and TX queues\nin both directions on each endpoint, and check carrier after a rejected\nout-of-range request as well. Create the pair with two queues explicitly\nso the carrier cases also run on single-CPU systems.\n\nReuse the existing namespace setup and cleanup. Run each carrier case\nin a subshell to keep its variables separate from the other tests, and\naccumulate failures in the caller. Only check LOWER_UP on running\ninterfaces, where the flag exposes carrier state.\n\nTested-by: Hangbin Liu \u003cliuhangbin@kylinos.cn\u003e\nReviewed-by: Hangbin Liu \u003cliuhangbin@kylinos.cn\u003e\nSigned-off-by: Xia Yan \u003cyana06070@163.com\u003e\nLink: https://patch.msgid.link/20261029024259.3700-2-yana06070@163.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "2d02191779345b13de91048db441191b20264d16", "tree": "1085f530bfd5e87782fa98326fe8f6ff3323890b", "parents": [ "631c3b1859809decbdb3bd96226b59efd1004389" ], "author": { "name": "Xia Yan", "email": "yana06070@163.com", "time": "Thu Oct 29 10:42:58 2026 +0800" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 15:24:53 2026 +0100" }, "message": "veth: keep carrier off when resizing channels with a down peer\n\nveth_set_channels() temporarily turns carrier off while reconfiguring a\nrunning interface. It then turns carrier on for both ends without\nchecking whether the peer is administratively up. If only one end is up,\nchanging its channel counts therefore reports LOWER_UP even though the\npeer remains down.\n\nFor example, after creating a pair with two RX and TX queues per end:\n\n ip link set vca up\n ethtool -L vca rx 1 tx 1\n\nvca incorrectly reports LOWER_UP while vcb is still down.\n\nOnly restore carrier when the peer has IFF_UP, matching veth_open().\nThe local interface is already known to be running at this point.\n\nFound during LLM-assisted source review and reproduced with a veth pair\nin network namespaces, without kernel instrumentation or error injection.\nThe companion veth.sh test reproduces the two mixed up/down failures\nbefore the fix and passes after it.\n\nFixes: 4752eeb3d891 (\"veth: implement support for set_channel ethtool op\")\nCc: stable@vger.kernel.org\nReviewed-by: Hangbin Liu \u003cliuhangbin@kylinos.cn\u003e\nSigned-off-by: Xia Yan \u003cyana06070@163.com\u003e\nReviewed-by: Jiayuan Chen \u003cjiayuan.chen@linux.dev\u003e\nLink: https://patch.msgid.link/20261029024259.3700-1-yana06070@163.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "631c3b1859809decbdb3bd96226b59efd1004389", "tree": "f4bddb54f75fea97bbb3478bfe8bd43459ecc0f9", "parents": [ "1f1f8e8c5176234fa31858cd25f2e9b88aac0a45", "23d23e6c6517d0fea4f64340a23e33c89f82c03c" ], "author": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 15:02:49 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 15:02:49 2026 +0100" }, "message": "Merge branch \u0027sfc-fix-ptp-synchronization-races\u0027\n\nAlex Austin says:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nsfc: fix PTP synchronization races\n\nThis series fixes PTP synchronization races found by code inspection, and\na related frequency-adjustment bug found while reviewing the locking.\n\nefx_ptp_start() resets the driver\u0027s cached current_adjfreq as though\nMC_CMD_PTP_OP_ENABLE also resets the NIC\u0027s frequency adjustment on the\nMC. It does not, so the next time-only adjustment reprograms the clock\nfrom a stale cache. Patch 1 removes this reset.\n\nefx_ptp_pps_worker() and the SIOCSHWTSTAMP path through\nefx_ptp_change_mode() both call efx_ptp_synchronize(). Concurrent calls\ncan interfere with the shared DMA handshake and the shared timeset\nresults, because the MCDI interface is released inside\nefx_mcdi_rpc_finish() and acquired after the handshake flag is cleared.\nPatch 2 serializes a function\u0027s synchronization transactions and clock\noperations under a new mutex. Patch 3 returns the PPS timestamp in\ncaller-owned storage to prevent concurrent synchronization from\noverwriting it while the PPS worker reads it.\n\nTested on two hosts with X2522-25G NICs cabled back to back at 25G.\nBoth PCI functions share one clock.\n\nClock operations on the function that registers the clock were run\nagainst repeated efx_ptp_change_mode() -\u003e efx_ptp_synchronize() on the\nother function:\n\n hwstamp_ctl -i ens41f0np0 -r 1 -t 1\n hwstamp_ctl -i ens41f1np1 -r 1 -t 1\n\n for i in $(seq 150); do\n phc_ctl /dev/ptp1 freq 1000\n phc_ctl /dev/ptp1 adj 0.0001\n phc_ctl /dev/ptp1 get\n done \u0026\n for i in $(seq 40); do\n hwstamp_ctl -i ens41f1np1 -r 0 -t 0\n hwstamp_ctl -i ens41f1np1 -r 1 -t 1\n done \u0026\n wait\n\n ethtool -S ens41f1np1 | grep ptp_\n\n without with\n ptp_good_syncs 400 400\n ptp_bad_syncs 0 0\n ptp_sync_timeouts 0 0\n ptp_no_time_syncs 0 0\n ptp_invalid_sync_windows 0 0\n ptp_undersize_sync_windows 0 8\n ptp_oversize_sync_windows 0 0\n\nThe undersize counter rejects readings as implausibly fast rather than\ninaccurate. FW reports a 40ns minimum sync window; without the series\nthe fastest readings sit exactly on that limit, and with it they sit a\nfew nanoseconds below. The shift tracks the barrier in the mutex\nacquisition rather than the serialization it provides: an smp_mb() alone\nwhere the mutex is taken reproduces the counter on an otherwise\nunmodified driver, while a plain memory access there does not. No\nsynchronization failed: each takes eight readings and needs one to\nsucceed.\n\nEnd-to-end PTP sync quality is unchanged (tested with ptp4l and\nphc2sys).\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nLink: https://patch.msgid.link/20261026123023.3566549-1-alex.austin@amd.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "23d23e6c6517d0fea4f64340a23e33c89f82c03c", "tree": "f4bddb54f75fea97bbb3478bfe8bd43459ecc0f9", "parents": [ "f707347b33feebdd67633bccea52f96807c18d6e" ], "author": { "name": "Alex Austin", "email": "alex.austin@amd.com", "time": "Mon Oct 26 12:30:23 2026 +0000" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 15:02:48 2026 +0100" }, "message": "sfc: ptp: avoid racing PPS timestamp updates\n\nefx_ptp_pps_worker() can race with SIOCHWTSTAMP via\nefx_ptp_change_mode(). After the worker completes synchronization, the\nioctl can start another synchronization and update host_time_pps while\nthe worker copies it into the PPS event. This can report a partially\nupdated timestamp. Serializing synchronization transactions alone does\nnot protect this copy, which happens after phc_lock is released.\n\nReturn the timestamp through the caller\u0027s own pps_event_time rather\nthan the shared field in efx_ptp_data, so the worker reads storage no\none else can write.\n\nFixes: 7c236c43b838 (\"sfc: Add support for IEEE-1588 PTP\")\nSigned-off-by: Alex Austin \u003calex.austin@amd.com\u003e\nReviewed-by: Alejandro Lucero \u003calucerop@amd.com\u003e\nReviewed-by: Pieter Jansen van Vuuren \u003cpieter.jansen-van-vuuren@amd.com\u003e\nLink: https://patch.msgid.link/20261026123023.3566549-4-alex.austin@amd.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "f707347b33feebdd67633bccea52f96807c18d6e", "tree": "77aa046779dfded776ac9378ee5d686dc8c14fc9", "parents": [ "21d4917cfc8b6837c44d8aa186941a6a16ec17a0" ], "author": { "name": "Alex Austin", "email": "alex.austin@amd.com", "time": "Mon Oct 26 12:30:22 2026 +0000" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 15:02:48 2026 +0100" }, "message": "sfc: ptp: serialize host and MC synchronization transactions\n\nefx_ptp_synchronize() clears the MC-ready DMA flag before\nefx_mcdi_rpc_start() acquires the MCDI interface, and processes results\ninto ptp-\u003etimeset[] after efx_mcdi_rpc_finish() has released it. The PPS\nworker and the hwtstamp enable path can therefore clobber each other\u0027s\nhandshake flag and timesets.\n\nHold a PHC mutex across the whole transaction and over the clock\noperations, so efx_phc_settime() reads and adjusts atomically and\ncurrent_adjfreq is consistently read and written under one lock. Also\nbail out when efx_mcdi_rpc_start() fails rather than finishing an RPC\nthat was never acquired.\n\nFixes: 7c236c43b838 (\"sfc: Add support for IEEE-1588 PTP\")\nSigned-off-by: Alex Austin \u003calex.austin@amd.com\u003e\nReviewed-by: Alejandro Lucero \u003calucerop@amd.com\u003e\nReviewed-by: Pieter Jansen van Vuuren \u003cpieter.jansen-van-vuuren@amd.com\u003e\nAcked-by: Edward Cree \u003cecree.xilinx@gmail.com\u003e\nLink: https://patch.msgid.link/20261026123023.3566549-3-alex.austin@amd.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "21d4917cfc8b6837c44d8aa186941a6a16ec17a0", "tree": "247b727d899644d0afa6528dabb74e0331df6d7b", "parents": [ "1f1f8e8c5176234fa31858cd25f2e9b88aac0a45" ], "author": { "name": "Alex Austin", "email": "alex.austin@amd.com", "time": "Mon Oct 26 12:30:21 2026 +0000" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 15:02:44 2026 +0100" }, "message": "sfc: ptp: drop the stale frequency reset in efx_ptp_start()\n\nFW does not touch the clock frequency state on MC_CMD_PTP_OP_DISABLE or\nMC_CMD_PTP_OP_ENABLE, so the driver doesn\u0027t need to either. Doing so\njust desyncs the driver\u0027s cached current_adjfreq from what FW still has\nprogrammed.\n\nResetting current_adjfreq to 0 here means the first efx_phc_adjtime()\ncall after efx_ptp_start() reprograms the NIC\u0027s clock frequency to 0,\nsince efx_phc_adjtime() always sends current_adjfreq to FW alongside\nthe time step. efx_ptp_start() runs on every SIOCSHWTSTAMP mode change,\non ifup, and on the reset_required path in efx_ptp_worker(), so each of\nthose silently drops any frequency correction the PTP servo had already\napplied.\n\nefx_ptp_start() is also reached from reset recovery, but that is fine:\non an FLR or PCIe reset FW does not touch the NIC clock, and on a full\nMC reboot the clock is reset to 1970, so a stale current_adjfreq from\nbefore the reset is hardly consequential - especially as it is bound to\nMAX_PPB, 1000000 ppb.\n\nFixes: 7c236c43b838 (\"sfc: Add support for IEEE-1588 PTP\")\nSigned-off-by: Alex Austin \u003calex.austin@amd.com\u003e\nLink: https://patch.msgid.link/20261026123023.3566549-2-alex.austin@amd.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "1f1f8e8c5176234fa31858cd25f2e9b88aac0a45", "tree": "f865379b70e267e14e0cb322cd410b4518b1eeb7", "parents": [ "263a5514cb9535380734b5e300b298f82570eb57" ], "author": { "name": "Qihang", "email": "q.h.hack.winter@gmail.com", "time": "Thu Oct 29 11:39:42 2026 +0800" }, "committer": { "name": "Dave Miller", "email": "davem@davem-thinkpadp1gen8.ibmlond.csb", "time": "Mon Nov 02 12:53:31 2026 +0000" }, "message": "cipso: fix optlen corruption in cipso_v4_delopt()\n\ncipso_v4_delopt() recomputes the option length by walking the option\nbuffer after the CIPSO option has been moved out. The walk then reads\nthe stale bytes at the tail of the buffer as option data, and a crafted\nsetsockopt(IP_OPTIONS) buffer can make it treat one of them as an option\nlength, increasing opt-\u003eopt.optlen beyond the valid option data.\n\nThe corrupted length stays on the socket and is later used as the copy\nlength by getsockopt(IP_OPTIONS) and by the udp/raw/ping sendmsg paths,\nwhere it exceeds the size of the buffers they copy into.\n\nCompute the new length from the intact options before the move and\nsubtract the CIPSO length, and fill the padding with IPOPT_END.\n\nAssisted-by: LLM\nFixes: 014ab19a69c32 (\"selinux: Set socket NetLabel based on connection endpoint\")\nCc: stable@vger.kernel.org\nSigned-off-by: Qihang \u003cq.h.hack.winter@gmail.com\u003e\nAcked-by: Paul Moore \u003cpaul@paul-moore.com\u003e\nSigned-off-by: Dave Miller \u003cdavem@davem-thinkpadp1gen8.ibmlond.csb\u003e\n" }, { "commit": "263a5514cb9535380734b5e300b298f82570eb57", "tree": "9de43fb8044df928c05e41eaae87ee9f4c25ad43", "parents": [ "21f57ec673a1917547c808cfa81890485fffa03b" ], "author": { "name": "Daniel Machon", "email": "daniel.machon@microchip.com", "time": "Thu Oct 29 12:47:47 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 12:59:38 2026 +0100" }, "message": "net: lan966x: don\u0027t free XDP buffers in fdma tx clear with budget 0\n\nlan966x_fdma_tx_clear_buf() runs from the NAPI poll and frees the\nbuffers of completed tx DCBs with napi_consume_skb(),\npage_pool_recycle_direct() and xdp_return_frame_bulk().\n\nnetpoll calls the NAPI poll with a budget of 0 and hardirqs disabled.\nWith a budget of 0, a driver cannot call any XDP or page pool API.\n\nBefore this patch, the XDP_TX pages and ndo_xdp_xmit frames are freed\nregardless of the budget. With netconsole on the port that owns the\nFDMA NAPI, such a buffer is freed with hardirqs disabled, and\n__page_pool_put_page() warns via lockdep_assert_no_hardirq().\n\nLeave the XDP buffers of completed DCBs in place when the budget is 0,\nand free them in the next NAPI poll. napi_consume_skb() already handles\na budget of 0, so skbs are still freed.\n\nFound by an AI code review agent. Reproduced on a lan9668 board with a\nmodified kernel that runs the NAPI poll with a budget of 0 and hardirqs\ndisabled. With the fix the warning is gone.\n\nFixes: 19c6f534f636 (\"net: lan966x: Add support for XDP_TX\")\nSigned-off-by: Daniel Machon \u003cdaniel.machon@microchip.com\u003e\nReviewed-by: Simon Horman \u003chorms@kernel.org\u003e\nLink: https://patch.msgid.link/20261029-lan966x-fdma-tx-clear-budget-v1-1-38c52d7aab8c@microchip.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "21f57ec673a1917547c808cfa81890485fffa03b", "tree": "2a8796390fe5572cc1340013c0145637953470f1", "parents": [ "031c403d13e5046750e2abebd4e770631e7c4627", "363ff816277d4c7064514b160e655bed1dfb3ed8" ], "author": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 11:43:14 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 11:43:15 2026 +0100" }, "message": "Merge branch \u0027net-stmmac-xdp-path-fixes\u0027\n\nLorenzo Bianconi says:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nnet: stmmac: XDP path fixes\n\nThis series adds some stmmac XDP preliminary fixes needed to introduce XDP\nRX multi-buff support.\n\nv1: https://lore.kernel.org/r/20261023-stmmac-xdp-fixes-v1-0-efb37e19f5bd@oss.qualcomm.com\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nLink: https://patch.msgid.link/20261027-stmmac-xdp-fixes-v2-0-10eae8a093a8@oss.qualcomm.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "363ff816277d4c7064514b160e655bed1dfb3ed8", "tree": "2a8796390fe5572cc1340013c0145637953470f1", "parents": [ "68bdbffcae08699af5c16f7a2ec61a5489b78dbe" ], "author": { "name": "Lorenzo Bianconi", "email": "lorenzo.bianconi@oss.qualcomm.com", "time": "Tue Oct 27 14:48:41 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 11:43:11 2026 +0100" }, "message": "net: stmmac: fix XDP RX buffer DMA sync length\n\nstmmac_rx() bounded the DMA sync length by the largest data_end seen\nbefore and after the XDP program and passed it to page_pool_put_page()\non the XDP_CONSUMED path. bpf_xdp_adjust_tail() zeroes the grown area,\nwhich dirties the CPU cache, but a later negative adjust only moves\ndata_end back. If the program grows and then shrinks the tail, both\nendpoints miss the zeroed range, so those dirty cache lines are not\nwritten back before the page is reused.\n\nThe length was also wrong since commit 88095728511e (\"net: stmmac: fix\nrx Scatter-Gather support\") moved the page_pool DMA window to offset 0\nand set max_len to dma_buf_sz + page_offset: the driver still\nsubtracted buf-\u003epage_offset, so it synced [base, data_end - page_offset)\ninstead of [base, data_end).\n\nOn a non-coherent platform those dirty lines can be evicted after the\ndevice has DMA\u0027d the next frame into the recycled page and corrupt it.\n\nSync the whole page_pool DMA window on the XDP_CONSUMED path with\npage_pool_recycle_direct(), as the PASS path and page_pool allocation\nalready do. The device only writes [page_offset, page_offset +\ndma_buf_sz), so syncing [base, base + max_len) covers every cache line\nit can touch, regardless of how the program adjusted the packet.\n\nFixes: be8b38a722e6 (\"net: stmmac: Add support for XDP_TX action\")\nFixes: 88095728511e (\"net: stmmac: fix rx Scatter-Gather support\")\nSigned-off-by: Lorenzo Bianconi \u003clorenzo.bianconi@oss.qualcomm.com\u003e\nLink: https://patch.msgid.link/20261027-stmmac-xdp-fixes-v2-6-10eae8a093a8@oss.qualcomm.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "68bdbffcae08699af5c16f7a2ec61a5489b78dbe", "tree": "9c93ce1a5fef5c29ce71335b5be5d6773929a49e", "parents": [ "41d78e9ac0984f0e9577e5312e62400b5a6760c8" ], "author": { "name": "Lorenzo Bianconi", "email": "lorenzo.bianconi@oss.qualcomm.com", "time": "Tue Oct 27 14:48:40 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 11:43:11 2026 +0100" }, "message": "net: stmmac: fix VLAN tag stripping on short and non-linear RX frames\n\nstmmac_rx_vlan() reads the VLAN header straight from skb-\u003edata and\nremoves it with skb_pull(), assuming the header is fully present in the\nlinear part of the skb. XDP can change the frame length and head layout\nbefore the tag is stripped.\n\nAn XDP program can use bpf_xdp_adjust_tail() to shrink a frame to as\nlittle as ETH_HLEN while bytes 12-13 still contain a VLAN ethertype. The\ndriver then reads h_vlan_TCI past skb-\u003elen and pops the tag, leaving less\nthan ETH_HLEN in the skb. eth_type_trans() cannot pull the MAC header, so\na malformed skb is passed up. The TCI is also read from the wrong place\nwhen the tag is not fully in the linear head, e.g. when it spans into a\nfrag.\n\nRead h_vlan_proto after pulling ETH_HLEN into the linear part, and check\nit together with the device features. Only if the tag is actually going\nto be popped, pull VLAN_ETH_HLEN and re-derive the header pointer\nafterwards, as pskb_may_pull() may reallocate the skb head. Return an\nerror so the callers can drop a frame that claims a VLAN tag but cannot\nprovide the full header. This also drops and counts frames shorter than\nETH_HLEN in rx_dropped, even when VLAN RX offload is disabled;\nbpf_xdp_adjust_head() and bpf_xdp_adjust_tail() cannot produce such a\nframe, so it only affects a runt that reaches the driver, and dropping it\nis safer than handing it to eth_type_trans().\n\nAlso move the XDP metadata written with bpf_xdp_adjust_meta() together\nwith the MAC header when the tag is popped, so data_meta still points at\nthe metadata after eth_type_trans() anchors mac_header, instead of at the\nfirst bytes of the destination MAC.\n\nFixes: 5fabb01207a2 (\"net: stmmac: Add initial XDP support\")\nReviewed-by: Nicolai Buchwitz \u003cnb@tipi-net.de\u003e\nSigned-off-by: Lorenzo Bianconi \u003clorenzo.bianconi@oss.qualcomm.com\u003e\nLink: https://patch.msgid.link/20261027-stmmac-xdp-fixes-v2-5-10eae8a093a8@oss.qualcomm.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "41d78e9ac0984f0e9577e5312e62400b5a6760c8", "tree": "1645396e5f1c8ba0385b364d2eb877b5672f3e7e", "parents": [ "52ffd771e0029c5ad0504b1b4a8b7f932b65eea3" ], "author": { "name": "Lorenzo Bianconi", "email": "lorenzo.bianconi@oss.qualcomm.com", "time": "Tue Oct 27 14:48:39 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 11:43:11 2026 +0100" }, "message": "net: stmmac: copy XDP metadata in AF_XDP zero-copy RX\n\nstmmac_construct_skb_zc() reserves headroom for the XDP metadata and\nrecords the length reported by the XDP program, but only copies the\npacket data starting at xdp-\u003edata. The bytes in\n[xdp-\u003edata_meta, xdp-\u003edata) are never copied into the new skb, so the\nskb advertises metadata that is not there: after eth_type_trans()\nanchors mac_header, data_meta points at uninitialized headroom instead\nof what the program wrote.\n\nCopy the metadata together with the packet data starting at\nxdp-\u003edata_meta, leaving skb-\u003edata at the start of the frame and the\nmetadata immediately before it, and record its length. This keeps\ndata_meta valid for the stack and TC BPF after eth_type_trans() anchors\nmac_header.\n\nFixes: bba2556efad6 (\"net: stmmac: Enable RX via AF_XDP zero-copy\")\nSigned-off-by: Lorenzo Bianconi \u003clorenzo.bianconi@oss.qualcomm.com\u003e\nLink: https://patch.msgid.link/20261027-stmmac-xdp-fixes-v2-4-10eae8a093a8@oss.qualcomm.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "52ffd771e0029c5ad0504b1b4a8b7f932b65eea3", "tree": "3f95ec7e8a4c056e3944708c07fb1df130a0ead0", "parents": [ "834ec95308320cbd8c162d86788ab95cc3fd6bf8" ], "author": { "name": "Lorenzo Bianconi", "email": "lorenzo.bianconi@oss.qualcomm.com", "time": "Tue Oct 27 14:48:38 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 11:43:11 2026 +0100" }, "message": "net: stmmac: drop multi-buffer frames in XDP mode\n\nstmmac_rx() runs the XDP program once per descriptor buffer and uses\nskb \u003d\u003d NULL as the only marker for the start of a frame. A frame larger\nthan one buffer is split by the hardware across several descriptors;\nGMAC4 enables jumbo frames unconditionally (GMAC_CONFIG_JE in\nGMAC_CORE_INIT), so an on-link peer can deliver such a frame even when\nthe interface MTU is left at 1500.\n\nWhen an XDP verdict ends a non-last descriptor, skb is cleared and the\nnext descriptor of the same hardware frame is parsed as a new frame.\nFor XDP_CONSUMED this happens via read_again with len preserved, so\nstmmac_rx_buf1_len() then returns min(dma_buf_sz, plen - len) for the\nlast descriptor, which can be as small as 0-3 bytes. buf1_len -\u003d\nETH_FCS_LEN underflows and xdp_prepare_buff() puts data_end far past\ndata; on XDP_PASS this produces an skb whose length is close to 4G that\nreaches the network stack (skb-\u003etail and skb-\u003elen are 32-bit and wrap\nbelow skb-\u003eend, so skb_over_panic() does not fire). A 4+ byte tail is\ninstead offered to the XDP program and delivered as a standalone\nmid-payload Ethernet frame on XDP_PASS. XDP_TX/XDP_REDIRECT instead\nfalls through to the next iteration, resetting the running length, so\nthe tail is re-parsed as a full-size new frame.\n\nThe same fault exists when a single descriptor uses its second buffer:\nbuffer2 is now handed to the hardware for non-SPH frames on GMAC4/XGMAC,\nso a frame up to 2 * dma_buf_sz can land on a single descriptor while the\nXDP program still only sees the first buffer. XDP_TX then transmits a\ntruncated frame, and XDP_PASS appends the second buffer only after the\nprogram has already run over the first one.\n\nXDP does not support scatter-gather frames until the multi-buffer\nrework, so drop the whole frame instead. When a non-last descriptor is\nseen while an XDP program is attached, mark the frame as errored and\ndrain the remaining descriptors, including the last. A descriptor that\nuses its second buffer is dropped directly before the program runs as\nwell; in XDP mode it is necessarily the last descriptor of the frame,\nso it does not need the error marker. Removing the re-parse lets both\nXDP verdict branches simply complete the packet via next.\n\nThe buffers consumed by the discard path are no longer returned to the\npage pool, and the new SG and second-buffer drops do not return them\neither. They stay in rx_q-\u003ebuf_pool[] and stmmac_rx_refill() reuses them\nin place, allocating only when a slot is empty. This is safe because the\ndrop checks run before the buffer is synced for CPU access or\nprefetched. The discard-path change and the in-place reuse apply with or\nwithout an XDP program attached.\n\nThe !error guard on the discard check also changes the accounting for\nerrored multi-descriptor frames on dwmac100/dwmac1000: rx_errors is\nincremented once per frame instead of once per descriptor. This too is\nindependent of XDP mode.\n\nNote: the subsequent \"net: stmmac: rework stmmac_rx to support XDP rx\nmulti-buff\" accumulates the whole frame into a single xdp_buff and\nsupersedes this patch; the fix is kept so the net portion of the series\nstands on its own.\n\nFixes: 5fabb01207a2 (\"net: stmmac: Add initial XDP support\")\nFixes: 88095728511e (\"net: stmmac: fix rx Scatter-Gather support\")\nReviewed-by: Nicolai Buchwitz \u003cnb@tipi-net.de\u003e\nSigned-off-by: Lorenzo Bianconi \u003clorenzo.bianconi@oss.qualcomm.com\u003e\nLink: https://patch.msgid.link/20261027-stmmac-xdp-fixes-v2-3-10eae8a093a8@oss.qualcomm.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "834ec95308320cbd8c162d86788ab95cc3fd6bf8", "tree": "3ac611d138e5b380adbdde61f86d32baf3823623", "parents": [ "26219e9402c22181f021034f127a8e278d40545f" ], "author": { "name": "Lorenzo Bianconi", "email": "lorenzo.bianconi@oss.qualcomm.com", "time": "Tue Oct 27 14:48:37 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 11:43:11 2026 +0100" }, "message": "net: stmmac: drop split frames on AF_XDP zero-copy RX\n\nstmmac_rx_zc() assumes a 1:1 mapping between a received frame and an\nXSK pool buffer and drops any frame that spans more than one RX\ndescriptor:\n\n /* XSK pool expects RX frame 1:1 mapped to XSK buffer */\n if (likely(status \u0026 rx_not_ls)) {\n xsk_buff_free(buf-\u003exdp);\n buf-\u003exdp \u003d NULL;\n dirty++;\n count++;\n goto read_again;\n }\n\nThe non-last descriptors are freed and dropped, but the frame is not\nmarked as errored. When the poll reaches the last descriptor of the\nsame frame, error is still 0, so the fragment is handled as a complete\nframe: it is passed to the XDP program, copied into an skb on XDP_PASS,\nor converted for XDP_TX. The tail starts in the middle of the original\npayload at a predictable offset and, parsed as a fresh frame (len \u003d\u003d 0),\nstmmac_rx_buf1_len() reports the full dma_buf_sz length for it even\nthough the DMA engine only wrote the tail remainder into that buffer, so\nthe reads extend past the received bytes and can reach beyond the end of\nthe XSK pool buffer. GMAC4 always enables jumbo frames (GMAC_CONFIG_JE\nin GMAC_CORE_INIT), so an on-link peer can trigger such a split even\nwhen the interface MTU is left at 1500.\n\nSet error when the 1:1 mapping check drops a descriptor, so the\nremaining descriptors of the frame - including the last one - are\ndrained and released with xsk_buff_free() instead of being processed as\na new frame. Account every freed buffer with dirty and count the\ndropped frame once in the poll budget / rx_pkt_n. The direct 1:1\nmapping drop also increments rx_dropped.\n\nUse a bit test instead of an equality test for discard_frame.\nCommit 644b8437ccef9e (\"net: stmmac: dwmac4: report Rx checksum errors\nin status\") made dwmac4_wrback_get_rx_status() set discard_frame on\nRDES3_ERROR_SUMMARY and OR in csum_none on RDES1_IP_HDR_ERROR or\nRDES1_IP_PAYLOAD_ERROR, so it can return discard_frame | csum_none.\nThe old \"status \u003d\u003d discard_frame\" test missed that value and delivered\nframes with CRC, overflow, watchdog or giant errors to the stack in\nstmmac_rx() - or to XDP/XSK in stmmac_rx_zc() - when they also failed\nthe IP checksum. The change therefore affects the regular RX path, not\nonly zero-copy. The bit test is also required for the\ndiscard_frame | rx_not_ls value returned for non-last legacy\ndescriptors below.\n\nNormalize the legacy normal and enhanced descriptor callbacks to report\nrx_not_ls together with discard_frame for non-last descriptors. This\nallows both stmmac_rx_zc() and stmmac_rx() to drain split frames on\ndwmac100 and dwmac1000 instead of reparsing the final fragment as a new\npacket.\n\nFixes: bba2556efad6 (\"net: stmmac: Enable RX via AF_XDP zero-copy\")\nFixes: 644b8437ccef9e (\"net: stmmac: dwmac4: report Rx checksum errors in status\")\nReviewed-by: Nicolai Buchwitz \u003cnb@tipi-net.de\u003e\nSigned-off-by: Lorenzo Bianconi \u003clorenzo.bianconi@oss.qualcomm.com\u003e\nLink: https://patch.msgid.link/20261027-stmmac-xdp-fixes-v2-2-10eae8a093a8@oss.qualcomm.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "26219e9402c22181f021034f127a8e278d40545f", "tree": "c462af03e59d476a85440be95bdebe1c474d31fd", "parents": [ "031c403d13e5046750e2abebd4e770631e7c4627" ], "author": { "name": "James Hilliard", "email": "james.hilliard1@gmail.com", "time": "Tue Oct 27 14:48:36 2026 +0100" }, "committer": { "name": "Paolo Abeni", "email": "pabeni@redhat.com", "time": "Mon Nov 02 11:43:11 2026 +0100" }, "message": "net: stmmac: take ownership of saved RX state at poll entry\n\nWhen a saved partial packet completes with a poll budget of one, the\nold loop can leave state_saved and state.skb pointing at an skb that\nhas already been delivered or freed. The next poll then reuses that\npointer, causing a use-after-free or double free.\n\nTake the saved state at poll entry and clear the stored ownership\nimmediately. Save it again only if the packet remains incomplete,\nincluding when the next descriptor is still DMA-owned.\n\nTrack the frame-in-progress flag independently of the status read from\nthe next descriptor. The old code keyed the save on the status of the\nlast descriptor looked at, so a loop stopped at a DMA-owned descriptor\n(rx status not yet valid) could drop the saved error/length bookkeeping\nin stmmac_rx_zc().\n\nDrop the saved state both when the queue parameters are reset and when\nthe ring is destroyed. stmmac_reset_rx_queue() is reached from\n__stmmac_open(), stmmac_xdp_open(), stmmac_resume() and\nstmmac_enable_rx_queue(); without draining it there, a partial frame\nsaved before suspend (or before a queue is disabled and re-enabled)\nsurvives while cur_rx and dirty_rx are rewound to zero. On the resume\npath the ring is only re-armed in place: stmmac_clear_descriptors()\nsets the ownership bits and stmmac_init_dma_engine() restores the tail\npointer, but the RX buffer addresses are not reprogrammed. The first\npoll would then resume the stale skb against a ring position that no\nlonger matches the descriptors it was built from.\n__free_dma_rx_desc_resources() releases it on teardown.\n\nApply the same state handling to stmmac_rx_zc(), which also leaves\nstate_saved set when a saved frame finishes at the budget boundary.\nThat path saves only error and length bookkeeping, not an skb pointer.\n\nFixes: ec222003bd94 (\"net: stmmac: Prepare to add Split Header support\")\nFixes: bba2556efad6 (\"net: stmmac: Enable RX via AF_XDP zero-copy\")\nSigned-off-by: James Hilliard \u003cjames.hilliard1@gmail.com\u003e\nReviewed-by: Nicolai Buchwitz \u003cnb@tipi-net.de\u003e\nCo-developed-by: Lorenzo Bianconi \u003clorenzo.bianconi@oss.qualcomm.com\u003e\nSigned-off-by: Lorenzo Bianconi \u003clorenzo.bianconi@oss.qualcomm.com\u003e\nLink: https://patch.msgid.link/20261027-stmmac-xdp-fixes-v2-1-10eae8a093a8@oss.qualcomm.com\nSigned-off-by: Paolo Abeni \u003cpabeni@redhat.com\u003e\n" }, { "commit": "031c403d13e5046750e2abebd4e770631e7c4627", "tree": "63dd41265b4d4a743cf60c58b686121e4c2cf7d2", "parents": [ "23fec4bd76904e9df7a8cc0a81ceb14c36971da4" ], "author": { "name": "Eric Dumazet", "email": "edumazet@kernel.org", "time": "Wed Oct 28 19:08:20 2026 +0000" }, "committer": { "name": "Dave Miller", "email": "davem@davem-thinkpadp1gen8.ibmlond.csb", "time": "Mon Nov 02 10:21:23 2026 +0000" }, "message": "tcp: do not let tcp_collapse() drive sk_forward_alloc negative\n\ntcp_collapse() charges each newly allocated skb with skb_set_owner_r()\nbefore the skbs it replaces are freed, without scheduling memory first.\n\nSince sk_mem_uncharge() reclaims eagerly, sk-\u003esk_forward_alloc has no\ncushion and can become negative. This can be durable when the collapsed\nskbs had a high payload/truesize ratio or were partially read, because\nthe new skbs can have a bigger total truesize than the old ones.\n\nA negative sk_forward_alloc then confuses tcp_wmem_schedule(), which\ncan return a negative length to tcp_sendmsg_locked(), triggering\na WARN_ON_ONCE(bytes \u003e INT_MAX) in check_copy_size().\n\nCall sk_forced_mem_schedule() before charging nskb.\n\nFixes: 4890b686f408 (\"net: keep sk-\u003esk_forward_alloc as small as possible\")\nSigned-off-by: Eric Dumazet \u003cedumazet@kernel.org\u003e\nReviewed-by: Kuniyuki Iwashima \u003ckuniyu@google.com\u003e\nSigned-off-by: Octavian Purdila \u003ctavip@google.com\u003e\nSigned-off-by: Dave Miller \u003cdavem@davem-thinkpadp1gen8.ibmlond.csb\u003e\n" }, { "commit": "23fec4bd76904e9df7a8cc0a81ceb14c36971da4", "tree": "95c504039b2db7dc8032e0fa717f335cb16157ed", "parents": [ "af449230bd8de936d6e4f759240e787b9aad7cc0" ], "author": { "name": "Cen Zhang (Microsoft)", "email": "cenzhang@linux.microsoft.com", "time": "Wed Oct 28 12:00:18 2026 -0400" }, "committer": { "name": "Dave Miller", "email": "davem@davem-thinkpadp1gen8.ibmlond.csb", "time": "Mon Nov 02 09:56:02 2026 +0000" }, "message": "ipv6: fix fib6 walker UAF on NLM_F_REPLACE\n\nfib6_walker uses w-\u003eleaf to remember the next fib6_info to dump, so an\nRTM_GETROUTE dump can continue there on the next recvmsg(). This\nassumes that whoever removes a route from the tree also updates the\nwalkers pointing at it. fib6_del_route() does: it moves w-\u003eleaf to\nthe next route. The NLM_F_REPLACE branch of fib6_add_rt2node() does\nnot: it removes the old route, fib6_add() frees it, and w-\u003eleaf keeps\npointing at the freed object.\n\nThe fn_sernum version check in fib6_dump_table() normally protects\nagainst resuming on a stale w-\u003eleaf, but it can be bypassed:\nip6_link_failure() resets fn_sernum to -1 when the default route\nfails, which an unprivileged user in a user+net namespace can cause:\n\n 1) link failure fn_sernum \u003d -1\n 2) dump pauses on route R\n 3) replace R fn_sernum changed, R freed\n 4) link failure fn_sernum \u003d -1\n 5) dump resumes -1 \u003d\u003d -1, reads freed R \u003c- UAF\n\n BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1c22/0x2cd0\n Read of size 4 at addr ff11000011fa0064 by task poc/101\n rt6_fill_node \u003c- rt6_dump_route\n\nFix by adjusting walkers separately for replacement and deletion.\nFor replacement, add fib6_walkers_replace_leaf() points w-\u003eleaf\nat the new route. For deletion and ECMP sibling removal,\nfib6_walkers_skip_rt() calls fib6_walkers_replace_leaf() with the\nnext route. Reset w-\u003eskip_in_node when updating w-\u003eleaf, and set\nw-\u003estate to FWS_U when no next route remains.\n\nFixes: 4a287eba2de3 (\"IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag\")\nCc: AutonomousCodeSecurity@microsoft.com\nSigned-off-by: Cen Zhang (Microsoft) \u003ccenzhang@linux.microsoft.com\u003e\nReviewed-by: Ido Schimmel \u003cidosch@nvidia.com\u003e\nSigned-off-by: Dave Miller \u003cdavem@davem-thinkpadp1gen8.ibmlond.csb\u003e\n" }, { "commit": "af449230bd8de936d6e4f759240e787b9aad7cc0", "tree": "5245332bda82013f9aa9e8884edcccfdf724652a", "parents": [ "902407bc588575af0ceae5de4f635fe1e024f258" ], "author": { "name": "Vlad Poenaru", "email": "vlad.wing@gmail.com", "time": "Wed Oct 28 04:49:33 2026 -0700" }, "committer": { "name": "Dave Miller", "email": "davem@davem-thinkpadp1gen8.ibmlond.csb", "time": "Mon Nov 02 09:34:18 2026 +0000" }, "message": "bnxt_en: Don\u0027t keep MSI-X vectors added before FW reserves them\n\nWhen dynamic MSI-X is supported, bnxt_check_rings() grows the MSI-X\nvectors with bnxt_change_msix() once FW says the new rings would fit,\nand keeps them. FW only reserves the extra IRQs later, when\nbnxt_reserve_rings() calls __bnxt_reserve_rings(). The MSI-X table\nentries beyond the function\u0027s reserved IRQs are not backed until then:\nthe MSI message written when the new vectors are activated is lost, and\nthe entries read back as zero. After FW reserves them they are live but\nstill zero, so the NQ rings bound to them signal address 0 and every\ncompletion on those rings is lost. The next ring change (for example\nethtool -G) then times out freeing each of those rings and the TX\nwatchdog fires:\n\n bnxt_en 0002:01:00.0 eth0: Resp cmpl intr err msg: 0x51\n bnxt_en 0002:01:00.0 eth0: hwrm_ring_free type 1 failed. rc:fffffff0 err:0\n ...\n bnxt_en 0002:01:00.0 eth0: NETDEV WATCHDOG: CPU: 17: transmit queue 18 timed out 5716 ms\n\nOn x86 this is hidden: GENERIC_IRQ_RESERVATION_MODE makes the PCI MSI\ndomains MSI_FLAG_MUST_REACTIVATE, so the message is composed and written\nagain when the IRQ is requested, after FW has reserved the vector.\nSince commit 0d6a7c417983 (\"irqchip/gic-v3-its: Enable dynamic MSI-X\nallocation\"), arm64 GICv3 systems take the dynamic path as well, but\nwrite the message only once, at allocation. On an NVIDIA Grace system\nwith a BCM57508, raising the channel count from 18 to 32 left MSI-X\nentries 18-31 all zero, and the 14 rings using them lost their\ninterrupts.\n\nKeep the allocation in bnxt_check_rings() as a check that enough vectors\nare available, but free the new vectors again right away when FW manages\nIRQ reservations (BNXT_NEW_RM). bnxt_reserve_rings() then allocates\nthem after __bnxt_reserve_rings() has reserved them. Without\nBNXT_NEW_RM there is no IRQ reservation and bnxt_reserve_rings() does\nnot grow the vectors, so keep the current behaviour there.\n\nIn bnxt_reserve_rings(), size that allocation from the rings FW actually\nreserved (bnxt_get_num_msix()) instead of the count computed before the\nreservation, so that a partial grant does not activate unreserved\nentries either, at least while no RoCE driver is registered.\n\nThe allocation can now fail after FW has committed the reservation. A\nlater open would then find nothing to reserve and return before growing\nthe vectors, and bnxt_request_irq() would use irq_tbl[] entries past\nbp-\u003etotal_irqs, which still hold the freed virqs. Grow the vectors in\nthat case as well, and clear irq_tbl[].vector when trimming.\n\nFixes: 2d51eb0bd81c (\"bnxt_en: Add MSIX check in bnxt_check_rings()\")\nReported-by: Andrew Preece \u003capreece@meta.com\u003e\nCloses: https://lore.kernel.org/all/20261022193620.2152038-1-vlad.wing@gmail.com/\nSigned-off-by: Vlad Poenaru \u003cvlad.wing@gmail.com\u003e\nReviewed-by: Michael Chan \u003cmichael.chan@broadcom.com\u003e\nSigned-off-by: Dave Miller \u003cdavem@davem-thinkpadp1gen8.ibmlond.csb\u003e\n" }, { "commit": "902407bc588575af0ceae5de4f635fe1e024f258", "tree": "2c0b6b7de249b9b3dfb2362ef274b0a78f599e32", "parents": [ "10f51f4fb99de99c64b9d35707f05fa0308f25ff" ], "author": { "name": "Joas Antonio dos Santos", "email": "joasantonio108@gmail.com", "time": "Tue Oct 27 18:17:06 2026 -0300" }, "committer": { "name": "Dave Miller", "email": "davem@davem-thinkpadp1gen8.ibmlond.csb", "time": "Mon Nov 02 09:20:26 2026 +0000" }, "message": "net/mlx5: macsec: free struct mlx5_fs_id after an RCU grace period\n\nmacsec_fs_id_del() removes a struct mlx5_fs_id from its rhashtable with\nrhashtable_remove_fast() and then frees it with kfree() right away.\n\nThe TX (SCI) table is read locklessly from the transmit path:\nmlx5e_macsec_handle_tx_skb() and mlx5e_macsec_tx_build_eseg() call\nmlx5_macsec_fs_get_fs_id_from_hashtable(), which does\nrhashtable_lookup() under rcu_read_lock() and then reads\nmlx5_fs_id-\u003eid. A transmit that looked the entry up just before it was\nremoved reads freed memory.\n\nBefore commit d4ece08f4b1d (\"net/mlx5: Maintain fs_id xarray per MACsec\ndevice inside macsec steering\") the SCI table held struct\nmlx5e_macsec_sa directly, and mlx5e_macsec_del_txsa() freed it with\nkfree_rcu_mightsleep(). That commit moved the table into macsec_fs.c\nwith the new struct mlx5_fs_id, but frees it with a plain kfree().\n\nAdd an rcu_head to struct mlx5_fs_id and free it with kfree_rcu().\n\nThe same issue was flagged by the Sashiko AI review as a pre-existing\nproblem while reviewing the HW-GRO for PSP series.\n\nFixes: d4ece08f4b1d (\"net/mlx5: Maintain fs_id xarray per MACsec device inside macsec steering\")\nLink: https://lore.kernel.org/all/20260909065542.4B80D1F00ACA@smtp.kernel.org/\nSigned-off-by: Joas Antonio dos Santos \u003cjoasantonio108@gmail.com\u003e\nAssisted-by: Yaga Agent HackerSec Claude:claude-opus-5-5\nReviewed-by: Simon Horman \u003chorms@kernel.org\u003e\nSigned-off-by: Dave Miller \u003cdavem@davem-thinkpadp1gen8.ibmlond.csb\u003e\n" }, { "commit": "10f51f4fb99de99c64b9d35707f05fa0308f25ff", "tree": "80dbc94c885a4380783243ab88bc76f15c283b5d", "parents": [ "c4ba1716853de5178a9df785844ebb5e397a80e6" ], "author": { "name": "Peter Hunt", "email": "peter.hunt@opengear.com", "time": "Tue Oct 27 11:10:55 2026 -0600" }, "committer": { "name": "Dave Miller", "email": "davem@davem-thinkpadp1gen8.ibmlond.csb", "time": "Mon Nov 02 09:15:34 2026 +0000" }, "message": "net: wwan: mhi_wwan_ctrl: send a DTR drop before it can be coalesced\n\nDTR/RTS changes are sent from a work item that only sends the latest\nstate, so a drop followed quickly by a raise, for example TIOCMBIC then\nTIOCMBIS or a quick close and reopen, can reach the modem as just the\nraise. A drop matters on its own, a modem set to AT\u0026D2 hangs up on it.\n\nFlush the work when DTR goes low so the drop is sent before -\u003edtr_rts()\nreturns, and flush it in stop() so any pending state is sent before the\nchannel is stopped. A drop that hits a full UL ring is still retried\nwith whatever state is latest by then.\n\nFixes: d509edf90bc6 (\"net: wwan: mhi_wwan_ctrl: drive DTR/RTS via the IP_CTRL channel\")\nSuggested-by: Loic Poulain \u003cloic.poulain@oss.qualcomm.com\u003e\nSigned-off-by: Peter Hunt \u003cpeter.hunt@opengear.com\u003e\nReviewed-by: Loic Poulain \u003cloic.poulain@oss.qualcomm.com\u003e\nSigned-off-by: Dave Miller \u003cdavem@davem-thinkpadp1gen8.ibmlond.csb\u003e\n" }, { "commit": "c4ba1716853de5178a9df785844ebb5e397a80e6", "tree": "ad98a3baed4c6e549a40f9d6d025a9d9d7207435", "parents": [ "cb284914e749388eef402938bdb3115fe1f6d337" ], "author": { "name": "Federico Musto", "email": "federico@rimpianto.com", "time": "Tue Oct 27 12:51:51 2026 +0100" }, "committer": { "name": "Dave Miller", "email": "davem@davem-thinkpadp1gen8.ibmlond.csb", "time": "Mon Nov 02 08:27:03 2026 +0000" }, "message": "net: atl1c: drop oversized RX frames instead of panicking\n\natl1c sizes its receive buffers from the netdev MTU plus a fixed set of L2\noverheads, which comes to 1522 bytes at the default MTU. A link partner\nthat sends a longer frame - in practice a MikroTik CCR2004-1G-2XS-PCIe,\nwhose RouterOS side defaults to l2mtu 1600 while the host stays at MTU 1500\n- makes the length reported by the RX return descriptor exceed what the\nhardware wrote, and skb_put() then either includes bytes that were never\nreceived or trips skb_over_panic and takes the host down.\n\nCompare the descriptor length against buffer_info-\u003elength, the length the\nhardware was given, rather than against skb_tailroom(): the skb carries 64\nbytes of slack for the DMA erratum, so tailroom is larger than the DMA\nbuffer and a frame in between would pass the check and still be delivered\nwith a tail the device never wrote. The same test rejects frames shorter\nthan ETH_HLEN + ETH_FCS_LEN; before this change a reported length below\nETH_FCS_LEN underflowed in skb_put().\n\nThe frame is dropped with kfree_skb_reason(SKB_DROP_REASON_PKT_TOO_BIG) so\ndrop_monitor and the kfree_skb tracepoint see it, and counted through\ndev_core_stats_rx_dropped_inc(), which survives atl1c_get_stats()\noverwriting the hardware counters on every read. It also counts as work:\natl1c_clean_rfd() has already recycled the RFD, and the refill at the end\nof the poll only runs when work_done is non-zero, so sustained oversized\ntraffic would otherwise drain the ring and stop RX.\n\nTested on a MikroTik CCR2004-1G-2XS-PCIe (4x AR8151) in a Proxmox VE host,\nwith atl1c built from a DKMS tree carrying this change: the l2mtu-1600\ntraffic that panics the stock driver is dropped and counted with the patch\napplied, and received normally once the host MTU is raised to match.\n\nThis complements commit 36c2009d90f2 (\"net: atl1c: fix soft lockup on\nout-of-range tpd_cons read\"), which fixed the TX side of the same\n\"host dies while the card resets\" problem.\n\nFixes: 43250ddd75a3 (\"atl1c: Atheros L1C Gigabit Ethernet driver\")\nCc: stable@vger.kernel.org\nSigned-off-by: Federico Musto \u003cfederico@rimpianto.com\u003e\nSigned-off-by: Dave Miller \u003cdavem@davem-thinkpadp1gen8.ibmlond.csb\u003e\n" }, { "commit": "cb284914e749388eef402938bdb3115fe1f6d337", "tree": "6d85e2ab8ffc68d4f22df92a622ff15efb29a7d4", "parents": [ "0a0257228be902ff09608bcaf19ae7c6d58b028f" ], "author": { "name": "Thomas Fourier", "email": "fourier.thomas@gmail.com", "time": "Thu Oct 29 09:20:55 2026 +0100" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 19:04:37 2026 -0700" }, "message": "net: ipa: Fix double free of the interrupt structure on config error\n\nSince ipa_interrupt_init() allocates struct ipa_interrupt in ipa_probe(),\nthe structure is owned by ipa_probe() and released with\nipa_interrupt_exit() on its error paths and in ipa_remove(). The error\npath of ipa_interrupt_config() still frees it with kfree(). If\nipa_interrupt_config() fails (called from ipa_config() via ipa_setup()),\nipa_probe() unwinds through err_interrupt_exit, which frees the same\nstructure again.\n\nDrop the kfree() from ipa_interrupt_config(); it should only undo what it\nset up itself. Drop the leftover initialization and cleanup of\nipa-\u003einterrupt now managed in ipa_proble() and ipa_remove() of ipa_main.c.\n\nFixes: ad1be80d7582 (\"net: ipa: introduce ipa_interrupt_init()\")\nSigned-off-by: Thomas Fourier \u003cfourier.thomas@gmail.com\u003e\nReviewed-by: Alex Elder \u003celder@riscstar.com\u003e\nLink: https://patch.msgid.link/20261029082100.17722-2-fourier.thomas@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "0a0257228be902ff09608bcaf19ae7c6d58b028f", "tree": "b841f3fdebf9dd19bfaf2f99db70cbfa852aeedd", "parents": [ "162cf592b577cccf04515100563e819d9eba5c4a" ], "author": { "name": "Tung Nguyen", "email": "tung.quang.nguyen@est.tech", "time": "Thu Oct 29 10:04:48 2026 +0700" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 19:03:37 2026 -0700" }, "message": "tipc: reject attaching bearer of different media to the same occupied device\n\nCurrently, two bearers of different media types can be added to the\nsame device (e.g., \"eth:eth0\" and \"ib:eth0\") via tipc command:\n\ntipc bearer enable media eth dev eth0\ntipc bearer enable media ib dev eth0\n\nFor each command execution, tipc_enable_l2_media() is called:\n\ntipc_enable_l2_media()\n dev_get_by_name()\n dev_hold()\n\nAs a result, device-\u003edev_refcnt is incremented twice, but the second\nbearer replaces the first one. This causes a leak in device-\u003edev_refcnt.\n\nFix this by rejecting a bearer with a different media type when the\ndevice is already occupied.\n\nFixes: cb30a63384bc (\"tipc: refactor function tipc_enable_bearer()\")\nReported-by: Jiakai Xu \u003cxujiakai24@mails.ucas.ac.cn\u003e\nCloses: http://lore.kernel.org/netdev/20260918013509.1853952-1-xujiakai24@mails.ucas.ac.cn/\nSigned-off-by: Tung Nguyen \u003ctung.quang.nguyen@est.tech\u003e\nLink: https://patch.msgid.link/20261029030522.8306-1-tung.quang.nguyen@est.tech\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "162cf592b577cccf04515100563e819d9eba5c4a", "tree": "e34d2fbe4f38641ae762f866eb2f914592f3cf73", "parents": [ "7b29287b182fc50518e9e65c41f86d24a05b7205" ], "author": { "name": "Fernando Fernandez Mancera", "email": "fmancera@suse.de", "time": "Wed Oct 28 23:53:50 2026 +0100" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:25:14 2026 -0700" }, "message": "net/smc: fix limit_smc_hs sysctl on big-endian architecture\n\nnet-\u003esmc.limit_smc_hs is a bool, but its sysctl entry uses\nproc_dointvec_minmax() with .maxlen \u003d sizeof(int), so the handler\naccesses four bytes at the address of a one-byte field.\n\nOn little-endian this works with the extra bytes being written in struct\npadding. On big-endian (tested on s390x) the bool sits at the most\nsignificant byte of the int therefore the bool stays false and the \"1\"\ngoes into padding. The sysctl reads back 1 but SMC sockets created\nafterwards see limit_smc_hs as disabled.\n\nFix this by using proc_dobool() handler and adjust the maxlen to the\nright value.\n\nFixes: f8406a2fd279 (\"net/smc: add sysctl for smc_limit_hs\")\nSigned-off-by: Fernando Fernandez Mancera \u003cfmancera@suse.de\u003e\nLink: https://patch.msgid.link/20261028225350.3753-1-fmancera@suse.de\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "7b29287b182fc50518e9e65c41f86d24a05b7205", "tree": "0c56baa092fc6626518856bc318f214be84bba68", "parents": [ "603a0c40d414ea12509fc45f2b930449a8d4aad2", "63787dfd1b5ae720cc30dab5e66c8e4d81ff7391" ], "author": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:16:00 2026 -0700" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:16:00 2026 -0700" }, "message": "Merge branch \u0027ptp-make-virtual-clock-sampling-and-teardown-failure-safe\u0027\n\nJames Hilliard says:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nptp: make virtual clock sampling and teardown failure-safe\n\nFix virtual-clock sampling errors, registration rollback and parent\nteardown in separate patches. Keep failed PHC reads out of the timecounter\nand serialize extended samples with virtual-clock adjustments. Also\npreserve the zero sentinel for packets without hardware timestamps.\n\nRetain the existing cyclecounter mask, scaling and conversion windows.\nRetry the first failed refresh promptly, then back off consecutive failures\nwhile preserving regular two-second refresh attempts. Queue the first\nrefresh immediately after registration. Prolonged sampling gaps remain\nsubject to the existing half-wrap conversion window and full-wrap sampling\nlimit.\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nLink: https://patch.msgid.link/20261026-ptp-vclock-sampling-v6-0-e705612541f1@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "63787dfd1b5ae720cc30dab5e66c8e4d81ff7391", "tree": "0c56baa092fc6626518856bc318f214be84bba68", "parents": [ "d3fcce5afe3bb62e8f7a2efb29e43da4fe4ae1f3" ], "author": { "name": "James Hilliard", "email": "james.hilliard1@gmail.com", "time": "Mon Oct 26 12:11:31 2026 -0600" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:15:58 2026 -0700" }, "message": "ptp: vclock: preserve missing hardware timestamps\n\nSocket timestamp delivery converts hardware timestamps to a bound\nvirtual clock before checking whether a hardware timestamp is present.\nA zero timestamp means that the packet has no hardware timestamp, but\ntimecounter_cyc2time() can turn that zero into a nonzero virtual time.\nThe socket then reports a hardware timestamp which was never supplied.\n\nReturn zero without conversion when the input timestamp is absent.\nThis also covers skb_get_tx_timestamp(), which checks for an absent\ntimestamp after the same conversion.\n\nThis was identified during review of virtual clock sampling changes.\n\nFixes: d7c088265588 (\"net: socket: support hardware timestamp conversion to PHC bound\")\nReviewed-by: Vadim Fedorenko \u003cvadim.fedorenko@linux.dev\u003e\nSigned-off-by: James Hilliard \u003cjames.hilliard1@gmail.com\u003e\nLink: https://patch.msgid.link/20261026-ptp-vclock-sampling-v6-5-e705612541f1@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "d3fcce5afe3bb62e8f7a2efb29e43da4fe4ae1f3", "tree": "39c056788279dca0954d0228ccfecb95bd411995", "parents": [ "d1bdfdafd663dd00b01d43eb3391f87718f2a09d" ], "author": { "name": "James Hilliard", "email": "james.hilliard1@gmail.com", "time": "Mon Oct 26 12:11:30 2026 -0600" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:15:58 2026 -0700" }, "message": "ptp: vclock: serialize extended samples with counter updates\n\nThe extended and cross-timestamp callbacks sample the physical clock\nbefore taking the virtual clock mutex. A concurrent frequency adjustment\ncan advance the timecounter and change its multiplier in between, so the\nolder sample is converted using a different frequency than the one in\neffect when it was taken.\n\nTake the mutex before sampling and keep it held through the conversion.\nRetain timecounter_cyc2time() and its existing conversion window. A PHC\nsample need not advance the counter: for example, e1000e explicitly\nallows non-monotonic SYSTIM readings. Treating a slightly older sample\nas a forward delta would instead advance virtual time by nearly a full\ncounter wrap.\n\nThis race was found by code inspection of the virtual clock sampling\npaths.\n\nFixes: f0067ebfc42b (\"ptp: add gettimex64() to virtual clocks.\")\nFixes: 21fad63084c2 (\"ptp: add getcrosststamp() to virtual clocks.\")\nSigned-off-by: James Hilliard \u003cjames.hilliard1@gmail.com\u003e\nLink: https://patch.msgid.link/20261026-ptp-vclock-sampling-v6-4-e705612541f1@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "d1bdfdafd663dd00b01d43eb3391f87718f2a09d", "tree": "85ce3c8c81c1b758e2e431631b615383ed7f6bbd", "parents": [ "3dea778260e3dddf30651a6913d87a42861346a2" ], "author": { "name": "James Hilliard", "email": "james.hilliard1@gmail.com", "time": "Mon Oct 26 12:11:29 2026 -0600" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:15:58 2026 -0700" }, "message": "ptp: vclock: propagate physical clock sampling errors\n\nThe cyclecounter read callback cannot report errors. ptp_vclock_read()\nignores the return from the physical clock and consumes its output even\nif the read failed. A zero sample followed by the real counter can add\nan extra 32-bit wrap to virtual time. This was found by code inspection\nof reset-time PHC access and the virtual clock callers.\n\nSample the parent before calling timecounter_read() or timecounter_init()\nand have the cyclecounter callback return the cached successful sample.\nOn failure, leave the counter and frequency adjustment unchanged and\nreturn the PHC error to the caller.\n\nRetry the first failed refresh after 10 ms instead of waiting another two\nseconds. With the existing 32-bit nanosecond mask, timecounter_cyc2time()\ncan interpret a fresh timestamp as being in the past once the last\nsuccessful refresh is about 2.147 seconds old. An isolated read failure\nshould not deliberately defer the next attempt until that sample is four\nseconds old.\n\nDouble the retry delay after consecutive failures, up to the normal\ntwo-second refresh interval, and reset it after a successful refresh.\nEach virtual clock has its own worker, and a failed parent read can involve\nbus traffic and error logging. Backoff limits that repeated work during a\npersistent failure while retaining a prompt first retry.\n\nLimit each retry delay to the next regular refresh deadline. Otherwise,\nbackoff can skip the next two-second refresh opportunity and lose a full\ncounter wrap even when the parent has recovered before that refresh was\ndue. Advance the deadline when an attempt reaches it without resetting the\nbackoff, so sustained failures still settle at the normal refresh interval.\nKeep the retry state private to each clock\u0027s auxiliary worker.\n\nTake the initial sample and initialize the counter before publishing the\nclock. Return an error pointer from registration and propagate its errno\nthrough n_vclocks, including when the initial sample fails. Queue the first\nrefresh immediately after registration so registration latency is not\nfollowed by another full refresh interval.\n\nKeep the existing cyclecounter mask and scaling. These scheduling changes\ndo not guarantee timely samples: prolonged read failures or worker delays\ncan still exceed the half-wrap conversion window, and a gap of about\n4.295 seconds between successful samples can lose a full counter wrap.\nDo not assume that getcycles64() exposes a full-width nanosecond counter.\n\nFixes: 5d43f951b1ac (\"ptp: add ptp virtual clock driver framework\")\nSigned-off-by: James Hilliard \u003cjames.hilliard1@gmail.com\u003e\nLink: https://patch.msgid.link/20261026-ptp-vclock-sampling-v6-3-e705612541f1@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "3dea778260e3dddf30651a6913d87a42861346a2", "tree": "b82f919fd6a96dade1c9be581b6a43d68abe1dc8", "parents": [ "0e4a135aebc7686286d87e286499ce55e5bd5aad" ], "author": { "name": "James Hilliard", "email": "james.hilliard1@gmail.com", "time": "Mon Oct 26 12:11:28 2026 -0600" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:15:58 2026 -0700" }, "message": "ptp: unwind partially completed virtual clock creation\n\nn_vclocks_store() publishes the new clock count only after every child\nhas been registered. If a later registration fails, it returns without\nunregistering the children already created by that request. Those clocks\nare left out of n_vclocks, and a subsequent request can overwrite their\nindex entries without removing them.\n\nUnregister the newly created children in reverse order and clear their\nindex entries on failure. Leave the previously installed clocks and\ntheir count unchanged. The n_vclocks mutex serializes this rollback with\nother sysfs changes, and parent removal drains the store before walking\nthe children.\n\nThis was found by code inspection while adding initial PHC sample error\nhandling to virtual clock registration.\n\nFixes: 73f37068d540 (\"ptp: support ptp physical/virtual clocks conversion\")\nSigned-off-by: James Hilliard \u003cjames.hilliard1@gmail.com\u003e\nLink: https://patch.msgid.link/20261026-ptp-vclock-sampling-v6-2-e705612541f1@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "0e4a135aebc7686286d87e286499ce55e5bd5aad", "tree": "6c3acb14c24e6302f1ee8bd3e57497fd7aa5f643", "parents": [ "603a0c40d414ea12509fc45f2b930449a8d4aad2" ], "author": { "name": "James Hilliard", "email": "james.hilliard1@gmail.com", "time": "Mon Oct 26 12:11:27 2026 -0600" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:15:57 2026 -0700" }, "message": "ptp: drain virtual clock sysfs operations before unregistering children\n\nParent clock removal walks its virtual clocks before removing the\nn_vclocks sysfs attribute. The mutex taken by ptp_vclock_in_use() is\nreleased before that walk, so a concurrent sysfs deletion can pick the\nsame child and unregister and free its ptp_vclock a second time. A\nreference held by the device iterator does not protect that separately\nallocated virtual clock.\n\nRemove n_vclocks before walking the children. Removing the attribute\nprevents new stores and drains stores already running, without holding\nn_vclocks_mux across a callback that needs that mutex. Skip virtual\nclocks, which do not have this attribute.\n\nThis race was found by code inspection of virtual-clock registration\nfailure cleanup and parent removal.\n\nFixes: bfcbb76b0f59 (\"ptp: unregister virtual clocks when unregistering physical clock.\")\nReviewed-by: Vadim Fedorenko \u003cvadim.fedorenko@linux.dev\u003e\nSigned-off-by: James Hilliard \u003cjames.hilliard1@gmail.com\u003e\nLink: https://patch.msgid.link/20261026-ptp-vclock-sampling-v6-1-e705612541f1@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "603a0c40d414ea12509fc45f2b930449a8d4aad2", "tree": "b13460a9a1656293e3195ad841bf3b1e9b9f9423", "parents": [ "cd74322d83d88c8407f751cb09dbc51d0ebc5a41" ], "author": { "name": "Yu Zhang", "email": "yuz08559@gmail.com", "time": "Mon Oct 26 20:05:35 2026 +1000" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:04:08 2026 -0700" }, "message": "ptp: fix use-after-free in extts_fifo_show() reading tsevqs unlocked\n\nextts_fifo_show() walks ptp-\u003etsevqs with list_count_nodes() and then\nlist_first_entry() without holding ptp-\u003etsevqs_lock, the spinlock that\n\"protects tsevqs from concurrent access\". Every other accessor of the\nlist honours it: ptp_open() (list_add_tail), ptp_release() (list_del\nfollowed by kfree of the per-fd queue), ptp_clock_release() and\nptp_clock_event() all take tsevqs_lock. extts_fifo_show() is the only\none that does not.\n\nA per-fd timestamp queue is appended to tsevqs on open(\"/dev/ptpN\") and\nremoved and freed on close(), both under tsevqs_lock:\n\n\tscoped_guard(spinlock_irq, \u0026ptp-\u003etsevqs_lock)\n\t\tlist_del(\u0026queue-\u003eqlist);\n\tbitmap_free(queue-\u003emask);\n\tkfree(queue);\n\nSo a read of /sys/class/ptp/ptpN/fifo running concurrently with a\nclose() of a /dev/ptpN fd can have list_count_nodes() walk into the\nqueue that close() is removing and freeing, dereferencing freed memory\n(use-after-free) or a poisoned list pointer.\n\nTake tsevqs_lock around the list walk. The fifo only ever draws from the\nfirst queue, which is the registration-time queue created in\nptp_clock_register() and freed only in ptp_clock_release(); that cannot\nrun while the sysfs attribute is being read, so the dequeue from\nqueue-\u003ebuf under queue-\u003elock may stay outside tsevqs_lock and the lock\norder is unchanged.\n\nFixes: d26ab5a35ad9 (\"ptp: Replace timestamp event queue with linked list\")\nCc: stable@vger.kernel.org\nSigned-off-by: Yu Zhang \u003cyuz08559@gmail.com\u003e\nLink: https://patch.msgid.link/20261026100535.68114-1-yuz08559@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "cd74322d83d88c8407f751cb09dbc51d0ebc5a41", "tree": "969b1243b5d57be2cf514b7d4eba42da3e240fdf", "parents": [ "8dc87fc5d6a0eb337744737008177342a708bf36", "dd6efae5529107cc8db277eaeaff5c5f15e6bc15" ], "author": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:03:41 2026 -0700" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:03:41 2026 -0700" }, "message": "Merge branch \u0027net-ethernet-mtk_wed-misc-fixes\u0027\n\nZhi-Jun You says:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nnet: ethernet: mtk_wed: misc fixes\n\nThs patch series includes some fixes for issues that were discovered\nby Sashiko and one original patch fixing issue I encountered.\n\nPatch 1,2,3 fix issues that were found by Sashiko.\nPatch 1 was compiled test only.\nPatch 2,3,4 were tested on a mt7986.\n\nPatch 1 fixes tx wdma ring reset for WED v3.\nPatch 2 fixes the reset condition for rx wdma.\nPatch 3 fixes rx ring and tx wdma ring not being freed up\nPatch 4 fixes WED on non-DBDC mt7986.\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nLink: https://patch.msgid.link/20261026-wedfix-v6-0-a52f6b15d2fc@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "dd6efae5529107cc8db277eaeaff5c5f15e6bc15", "tree": "969b1243b5d57be2cf514b7d4eba42da3e240fdf", "parents": [ "5b8d12512cbd3495dbd8c38e8047bb5d716f0f3f" ], "author": { "name": "Zhi-Jun You", "email": "hujy652@gmail.com", "time": "Mon Oct 26 17:57:31 2026 +0800" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:03:39 2026 -0700" }, "message": "net: ethernet: mtk_wed: setup WDMA_RING_TX(0) for non-DBDC MT7986\n\nWDMA_RING_TX(0) is required to set MTK_WED_WDMA_RING_TX for WED RX\nbut on a non-DBDC MT7986 it is never setup because idx is 1.\n\nSetting MTK_WED_WDMA_RING_TX with WDMA_RING_TX(1) is not feasible because\nWED still tries to send through WDMA_RING_TX(0). This is verified with\nregister dump.\n\nFix this by calling mtk_wed_wdma_tx_ring_setup if wed is v2 and\nrx_ring[0] is not allocated and reset tx_wdma[0] if it\u0027s already\nallocated also add error messages and bail when mtk_wed_start fails.\n\nFixes: 4c5de09eb0d0 (\"net: ethernet: mtk_wed: add configure wed wo support\")\nSigned-off-by: Zhi-Jun You \u003chujy652@gmail.com\u003e\nLink: https://patch.msgid.link/20261026-wedfix-v6-4-a52f6b15d2fc@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "5b8d12512cbd3495dbd8c38e8047bb5d716f0f3f", "tree": "f4082b6fda785646e59e04c2e0775271fd1721c8", "parents": [ "7180a42d8e616f919dcff4b90a13b9a5ecea665b" ], "author": { "name": "Zhi-Jun You", "email": "hujy652@gmail.com", "time": "Mon Oct 26 17:57:30 2026 +0800" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:03:39 2026 -0700" }, "message": "net: ethernet: mtk_wed: free up rings during detach\n\nDuring __mtk_wed_detach, rx_ring and tx_wdma aren\u0027t freed up.\n\nFix this by add them to mtk_wed_free_rx_rings.\n\nThis patch is pulled from mtk-openwrt-feeds to address Sashiko\u0027s review\nand edit to rely on ring-\u003edesc instead of an extra flag.\n\nLink: https://github.com/mediatek/mtk-openwrt-feeds/blob/main/25.12/files/target/linux/mediatek/patches-6.12/999-wed-04-Fix-reinsert-wifi-module-cause-memory-leak-issue.patch\nFixes: 4c5de09eb0d0 (\"net: ethernet: mtk_wed: add configure wed wo support\")\nReported-by: Sashiko \u003csashiko-bot@kernel.org\u003e\nLink: https://sashiko.dev/#/message/179000700034.2160803.10594281691384015089%40kernel.org\nSigned-off-by: Zhi-Jun You \u003chujy652@gmail.com\u003e\nLink: https://patch.msgid.link/20261026-wedfix-v6-3-a52f6b15d2fc@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "7180a42d8e616f919dcff4b90a13b9a5ecea665b", "tree": "ec329224ec9a0023605bf7241bb2c8daf182316b", "parents": [ "cb50f16f37fc3429085c454ee5978e05732d10ba" ], "author": { "name": "Zhi-Jun You", "email": "hujy652@gmail.com", "time": "Mon Oct 26 17:57:29 2026 +0800" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:03:39 2026 -0700" }, "message": "net: ethernet: mtk_wed: fix reset condition for rx wdma\n\nIn mtk_wdma_rx_reset, currently only resets the CPU index of the rings\nthat doesn\u0027t have a descriptor. This is wrong because no descriptor\nmeans the ring is not configured.\n\nAlso mtk_wed_start makes sure that all rx_wdma rings are set up this\nwould lead to no ring getting their CPU index reset.\n\nFix this by inverting the reset condition so allocated rings will be\nreset.\n\nFixes: 4c5de09eb0d0 (\"net: ethernet: mtk_wed: add configure wed wo support\")\nReported-by: Sashiko \u003csashiko-bot@kernel.org\u003e\nLink: https://sashiko.dev/#/patchset/20260724172040.1653-1-hujy652%40gmail.com\nSigned-off-by: Zhi-Jun You \u003chujy652@gmail.com\u003e\nLink: https://patch.msgid.link/20261026-wedfix-v6-2-a52f6b15d2fc@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "cb50f16f37fc3429085c454ee5978e05732d10ba", "tree": "b7f93ec33b99a573287646ffb22a6463643d80ba", "parents": [ "8dc87fc5d6a0eb337744737008177342a708bf36" ], "author": { "name": "Zhi-Jun You", "email": "hujy652@gmail.com", "time": "Mon Oct 26 17:57:28 2026 +0800" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 16:03:39 2026 -0700" }, "message": "net: ethernet: mtk_wed: skip ring reset in wdma_tx_ring_setup for WED v3\n\nCurrently WED v3 tx wdma ring, ring reset happens in a separate code\nblock unconditionally.\n\nMoreover, v3 has double the size of wdma_desc and has different init\nvalues. mtk_wed_ring_reset doens\u0027t deal with that and would corrupt the\nwdma_desc.\n\nFix this by skipping mtk_wed_ring_reset in mtk_wdma_tx_ring_setup for\nWED v3.\n\nFixes: e2f64db13aa1 (\"net: ethernet: mtk_wed: introduce WED support for MT7988\")\nReported-by: Sashiko \u003csashiko-bot@kernel.org\u003e\nLink: https://sashiko.dev/#/patchset/20260711112128.971-1-hujy652@gmail.com?part\u003d1\nSigned-off-by: Zhi-Jun You \u003chujy652@gmail.com\u003e\nLink: https://patch.msgid.link/20261026-wedfix-v6-1-a52f6b15d2fc@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "8dc87fc5d6a0eb337744737008177342a708bf36", "tree": "1f136e04c365b7c456d44fd034cc8c96f1ea0202", "parents": [ "ed6c53b27be492643da2017c6f8e2732be5edf1a" ], "author": { "name": "Maxime Chevallier", "email": "maxime.chevallier@bootlin.com", "time": "Thu Oct 29 16:31:29 2026 +0100" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 15:47:58 2026 -0700" }, "message": "net: Use a dedicated flag to track disabled napi instances\n\nTrying to disable the napi threaded state while the napi instance is\ndisabled will hang forever in napi_stop_kthread(), as it waits for\nNAPIF_STATE_SCHED_THREADED to clear.\n\nThis won\u0027t happen until the next ____napi_schedule() call, which won\u0027t\nhappen as it\u0027s disabled.\n\nThis happens in 2 instances :\n\n - Drivers that create but don\u0027t use napi instances (stmmac\u0027s rxtx napi\n for AF_XDP for example), here it\u0027s a driver bug\n\n - Drivers that create their napi instances in .probe(). Here, setting\n threaded off while the interface is down will hang :\n\n ip link set eth0 down\n echo 1 \u003e /sys/class/net/eth0/threaded\n echo 0 \u003e /sys/class/net/eth0/threaded\n -\u003e hang\n\nChecking on netif_running() isn\u0027t enough, as napi instances may be\ntransiently disabled when changing the MTU for example, let\u0027s use a\ndedicated flag to track if the instance is disabled.\n\nThis allows immediately disabling the kthread when the instance is\ndisabled.\n\nThis was tested on mvpp2 (probe-time napi_add) and stmmac.\n\nFixes: 689883de94dd (\"net: stop napi kthreads when THREADED napi is disabled\")\nTested-by: Daniel Machon \u003cdaniel.machon@microchip.com\u003e\nSigned-off-by: Maxime Chevallier \u003cmaxime.chevallier@bootlin.com\u003e\nLink: https://patch.msgid.link/20261029153130.121204-1-maxime.chevallier@bootlin.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "ed6c53b27be492643da2017c6f8e2732be5edf1a", "tree": "e812c0f07e4fc4d2afc4e926368df435d64d051d", "parents": [ "84574c7e46386255465bc518b5b8cd780063f3ef" ], "author": { "name": "Masafumi Suzuki", "email": "shengshilingmu97@gmail.com", "time": "Tue Oct 27 17:24:05 2026 +0900" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 15:08:42 2026 -0700" }, "message": "sctp: account for chunk padding in sctp_init_cause()\n\nsctp_init_cause() accepts a chunk when skb_tailroom() can hold the\ncause header and the payload. sctp_addto_chunk() then writes 0-3\nbytes of padding before that header so the chunk stays 4-byte\naligned. The check does not include the padding, and the following\nskb_put() calls skb_over_panic() from softirq.\n\nCount the padding sctp_addto_chunk() is about to write. The cause\nlength on the wire stays the header plus the payload.\n\nFound by LLM inspection, triggered and tested the fix.\n\nFixes: 8914f4bace3f (\"sctp: add sctp_make_op_error_limited and reuse inner functions\")\nCc: stable@vger.kernel.org\nSigned-off-by: Masafumi Suzuki \u003cshengshilingmu97@gmail.com\u003e\nAcked-by: Xin Long \u003clucien.xin@gmail.com\u003e\nLink: https://patch.msgid.link/20261027082405.1297-1-shengshilingmu97@gmail.com\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "84574c7e46386255465bc518b5b8cd780063f3ef", "tree": "235a829f4840deb5f924f2a37b100aebfdf1d958", "parents": [ "d8a4f4c59da52b7c31ae337243b8473a19a3f819", "a137095419b4be0b204a11af4f1cea872ea262e9" ], "author": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 14:54:00 2026 -0700" }, "committer": { "name": "Jakub Kicinski", "email": "kuba@kernel.org", "time": "Fri Oct 30 14:54:01 2026 -0700" }, "message": "Merge tag \u0027batadv-net-pullrequest-20261030\u0027 of https://git.open-mesh.org/batadv\n\nSimon Wunderlich says:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nHere are a few batman-adv bugfixes:\n\n- avoid WARN_ON for orig_ifinfo allocation failure, by Deepanshu Kartikey\n\n- close OGM aggregation before transmission, by Chengfeng Ye\n\n- mcast: validate tracker padding before forwarding, by Kyle Zeng\n\nThe remaining bugfixes are authored by Sven Eckelmann:\n\n- tpmeter: fix u32 truncation of reported bytes\n\n- dat: initialize orig_node of unfilled candidate slots\n\n- fix skb leak when hard_iface is being released\n\n- stop originator purge worker before freeing tt\n\n- tt: fix flag and event handling (6 patches)\n\n- tt: limit local table to single TVLV response size\n\n* tag \u0027batadv-net-pullrequest-20261030\u0027 of https://git.open-mesh.org/batadv:\n batman-adv: tt: limit local table to single TVLV response size\n batman-adv: tt: don\u0027t drop local events queued during TVLV update\n batman-adv: tt: only update flags for TT events\n batman-adv: tt: ignore ROAM flag of received ADD changes\n batman-adv: tt: send ROAM_ADV on each roamed back client\n batman-adv: tt: clear ROAM flag when re-adding a pending local client\n batman-adv: tt: only transmit local ROAM flag together with DEL\n batman-adv: stop originator purge worker before freeing TT\n batman-adv: fix skb leak when hard_iface is being released\n batman-adv: dat: initialize orig_node of unfilled candidate slots\n batman-adv: tpmeter: fix u32 truncation of reported bytes\n batman-adv: mcast: validate tracker padding before forwarding\n batman-adv: Close OGM aggregation before transmission\n batman-adv: avoid WARN_ON for orig_ifinfo allocation failure\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nLink: https://patch.msgid.link/20261030135105.2555887-1-sw@simonwunderlich.de\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n" }, { "commit": "d8a4f4c59da52b7c31ae337243b8473a19a3f819", "tree": "319710e988e30a920502bdbae847a364c0e8ef80", "parents": [ "66dfb2cacda7faae614d688943d85e75abf7f586" ], "author": { "name": "Prasad Koya", "email": "prasad@arista.com", "time": "Mon Oct 26 19:46:35 2026 -0700" }, "committer": { "name": "Dave Miller", "email": "davem@davem-thinkpadp1gen8.ibmlond.csb", "time": "Fri Oct 30 10:06:40 2026 +0000" }, "message": "macvlan: fix allmulti reference counting in passthru mode\n\nEnabling allmulticast on a down passthru macvlan, bringing it up,\nthen toggling allmulticast off and on can underflow the lower device\u0027s\nallmulti reference count.\n\nmacvlan_change_rx_flags() only propagates IFF_ALLMULTI changes while\nthe macvlan is up. However, the passthru path in macvlan_open() skips\ntaking an allmulti reference when IFF_ALLMULTI is already set.\nClearing allmulticast after opening the device therefore decrements\na reference that was never taken. With no other allmulti users, the\nunsigned counter wraps from zero to UINT_MAX. The next increment\nfails with -EOVERFLOW and reports \"allmulti touches roof\".\n\nThe issue was observed during development testing with 5.10 and 6.12\nkernels. It was reproduced on Linux 6.12.68 by enabling allmulticast\non a down passthru macvlan, bringing it up, and toggling allmulticast\noff and on. This triggered the “allmulti touches roof” warning.\n\nSigned-off-by: Prasad Koya \u003cprasad@arista.com\u003e\nSigned-off-by: Dave Miller \u003cdavem@davem-thinkpadp1gen8.ibmlond.csb\u003e\n" }, { "commit": "66dfb2cacda7faae614d688943d85e75abf7f586", "tree": "cc3e124ee9b7befc90b54fdfc2b33281cff4efdb", "parents": [ "ed9179fc7228315fb745dc3b111bae446e6894d2" ], "author": { "name": "Zhou Qiuyue", "email": "n0ps1edzz@gmail.com", "time": "Mon Oct 26 12:48:08 2026 +0800" }, "committer": { "name": "Dave Miller", "email": "davem@davem-thinkpadp1gen8.ibmlond.csb", "time": "Fri Oct 30 09:32:15 2026 +0000" }, "message": "ipv6: raw: fix use-after-free in rawv6_send_hdrinc()\n\nrawv6_send_hdrinc() caches the route before handing the skb to\nl3mdev_ip6_out(). The VRF output path may replace skb-\u003edst and release\nthe original route, leaving the cached pointer stale.\n\nThe function later dereferences that pointer for statistics accounting\nand as the output device passed to NF_HOOK(). Its RCU read-side critical\nsection starts after l3mdev_ip6_out(), so it cannot prevent the old route\nfrom being reclaimed in between.\n\nReload the route from the current skb destination after\nl3mdev_ip6_out() returns.\n\nKASAN reports a slab-use-after-free in rawv6_sendmsg(), with the route\nallocated by ip6_dst_alloc(), freed by dst_destroy() from rcu_core(), and\nthe related RCU callback queued from vrf_l3_out().\n\nFixes: 4c1feac58e06 (\"net: vrf: Flip IPv6 output path from FIB lookup hook to out hook\")\nCc: stable@vger.kernel.org\nSigned-off-by: Zhou Qiuyue \u003cn0ps1edzz@gmail.com\u003e\nReviewed-by: Hangbin Liu \u003cliuhangbin@kylinos.cn\u003e\nSigned-off-by: Dave Miller \u003cdavem@davem-thinkpadp1gen8.ibmlond.csb\u003e\n" }, { "commit": "ed9179fc7228315fb745dc3b111bae446e6894d2", "tree": "ffe95e792eb10552ecd698a38c65eca640fc0ae5", "parents": [ "5838f10563d58afca6711edb5e4eda968ca181d9" ], "author": { "name": "Franck Baur", "email": "franck.baur.67@gmail.com", "time": "Sat Oct 24 14:40:44 2026 +0200" }, "committer": { "name": "Dave Miller", "email": "davem@davem-thinkpadp1gen8.ibmlond.csb", "time": "Fri Oct 30 09:18:33 2026 +0000" }, "message": "net: jme: keep RX MAC clock enabled for WoL\n\nOn the JMicron JMC250 revision 03, the MAC reset performed during\nsuspend leaves GPREG1_RXCLKOFF set. Although the driver enables Magic\nPacket detection, the gated RX MAC clock prevents wake-up from ACPI S3.\n\nKeep the RX MAC clock enabled while WoL is armed. Restore the gated\nclock state immediately after disabling WoL during resume, preserving\nthe RX engine initialization ordering.\n\nPrevent concurrent link-change work from gating the clock again after\nWoL has been armed. Quiesce interrupt-driven link-change scheduling,\nsynchronize pending interrupts, and cancel outstanding link-change\nwork before programming WoL in suspend and shutdown paths.\n\nRestore the deferred processing state before requesting link\nreinitialization on resume.\n\nTested on an ASUS K42JE with JMC250 [197b:0250] rev 03 using a\nDebian 6.12.111 kernel and an externally built module. ACPI S3 wake\nwith a Magic Packet completed in 19 seconds, while a control without\na Magic Packet resumed through the RTC alarm after 123 seconds.\nEthernet and SSH recovered after resume.\n\nS4 and S5 wake behaviour has not been validated with this revision.\n\nFixes: 854a2e7c331a (\"jme: Safer MAC processor reset sequence\")\nCc: stable@vger.kernel.org\nAssisted-by: LLM\nSigned-off-by: Franck Baur \u003cfranck.baur.67@gmail.com\u003e\nSigned-off-by: Dave Miller \u003cdavem@davem-thinkpadp1gen8.ibmlond.csb\u003e\n" }, { "commit": "a137095419b4be0b204a11af4f1cea872ea262e9", "tree": "8284fe7d33f34e43755a9414be15c30abc483c51", "parents": [ "ed7a0dfdd370acb48be7a281df732c1bebcc7f1d" ], "author": { "name": "Sven Eckelmann", "email": "sven@narfation.org", "time": "Sat Oct 03 00:00:51 2026 +0200" }, "committer": { "name": "Sven Eckelmann", "email": "sven@narfation.org", "time": "Fri Oct 30 10:11:27 2026 +0100" }, "message": "batman-adv: tt: limit local table to single TVLV response size\n\nThe reservation of local TT entries and VLANs only limits the local table\nby (int) packet_size_max. But the full table response is sent as a single\nunicast TVLV packet whose tvlv_len (covering the TVLV header and the TT\nTVLV) is only 16 bit wide. The reservation must therefore be capped at the\nminimum of both the packet_size_max and the maximum theoretic table\nresponse.\n\nThe size limit was already missing the 16 bit tvlv_len cap since the\noriginal packet_size_max check was introduced. But this check was only\nreachable with fragmentation disabled and a hard interface MTU larger than\nthe maximum unicast TVLV packet. In this case,\nbatadv_tt_prepare_tvlv_local_data() refuses to build the full table\nresponse and no oversized packet is created. It is therefore mostly\naffecting the commit 85fb027f611b (\"batman-adv: tt: reject VLAN/TT entries\nbefore reaching size limit\"), which should prevent this kind of\noverallocation.\n\nReported-by: Sashiko \u003csashiko-bot@kernel.org\u003e\nCloses: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260930094558.3723766-2-sw%40simonwunderlich.de?part\u003d8\nFixes: a19d3d85e1b8 (\"batman-adv: limit local translation table max size\")\nCc: \u003cstable+noautosel@kernel.org\u003e # requires 85fb027f611b, old behavior only affects MTU \u003e 64KiB without fragmentation\nSigned-off-by: Sven Eckelmann \u003csven@narfation.org\u003e\n" }, { "commit": "ed7a0dfdd370acb48be7a281df732c1bebcc7f1d", "tree": "826af2ca1fe549722ddd4ccb799232f9fd6049f0", "parents": [ "ad1fd828aa3944efc393b84b0d7c02483f1b5638" ], "author": { "name": "Sven Eckelmann", "email": "sven@narfation.org", "time": "Thu Oct 08 17:41:24 2026 +0200" }, "committer": { "name": "Sven Eckelmann", "email": "sven@narfation.org", "time": "Fri Oct 30 10:11:27 2026 +0100" }, "message": "batman-adv: tt: don\u0027t drop local events queued during TVLV update\n\nbatadv_tt_tvlv_container_update() read the number of local changes without\nholding changes_list_lock. batadv_tt_local_event() is not serialized by\nthe commit_lock and can queue new events before the changes_list is\nflushed:\n\n CPU0 CPU1\n batadv_tt_tvlv_container_update()\n num \u003d ...local_changes;\n batadv_tt_local_event()\n list_add_tail(...);\n ...local_changes++;\n spin_lock_bh(\u0026...changes_list_lock);\n /* only num events copied but all freed */\n\nThe additional events were freed without ever being sent. Other nodes will\nonly notice this via a CRC mismatch and must request the full table.\n\nThe number of changes and the changes_list must therefore be taken\natomically. Events queued afterwards then stay in the tt.changes_list for\nthe next TT round.\n\nThe changes can no longer be kept for the next round when the TVLV buffer\nallocation fails. But they would be sent with a skipped TTVN anyway, so the\nother nodes have to request the full table in this case either way. The\nlast changeset is only dropped in this case when the TTVN was incremented.\nWithout new changes, it still describes the current TTVN.\n\nPreviously, the unconsumed changes caused a retry of the TVLV container\nupdate in the next commit round. Since the changes are now consumed, the\nnext round would only take the path without changes and wait for\nBATADV_TT_OGM_APPEND_MAX rounds before updating the container again. Until\nthen, the outdated container with the previous TTVN would still be\nannounced. The ogm_append_cnt is therefore reset on failure to retry the\nupdate in the next OGM interval.\n\nThis doesn\u0027t make the CRC consistent with the announced changeset. The\nlocal table modifications are still not serialized with the commit and\nbatadv_tt_local_transition_new() can still make a client part of the CRC\nfor which the event is only part of the next TT round. Such an\ninconsistency is detected by the CRC check of the other nodes and solved\nvia a full table request.\n\nCc: stable@vger.kernel.org\nReported-by: Sashiko \u003csashiko-bot@kernel.org\u003e\nCloses: https://sashiko.dev/#/bug/linux-fc286ddd-5bed-4683-b842-ee7a307eeb19\nFixes: a73105b8d4c7 (\"batman-adv: improved client announcement mechanism\")\nSigned-off-by: Sven Eckelmann \u003csven@narfation.org\u003e\n" }, { "commit": "ad1fd828aa3944efc393b84b0d7c02483f1b5638", "tree": "bff3039b9fd1d2eccb1524fa107506b07f3f87b7", "parents": [ "c5d68abe6e7f1dbd132a602cb696fe1fff0389eb" ], "author": { "name": "Sven Eckelmann", "email": "sven@narfation.org", "time": "Thu Oct 08 16:30:10 2026 +0200" }, "committer": { "name": "Sven Eckelmann", "email": "sven@narfation.org", "time": "Fri Oct 30 10:11:27 2026 +0100" }, "message": "batman-adv: tt: only update flags for TT events\n\nIn the first implementation of the translation table events, it was only\npossible to announce:\n\n* ADD: new locally detected client\n* DEL: disappeared local client\n\nIf an ADD event was queued and then a DEL event was queued in the same\ntimeslot, it is valid to destroy both events because nothing actually\nchanged for remode nodes\n\nBut with commit 3c4f7ab60cc2 (\"batman-adv: improve the TT component to\nsupport runtime flag changes\") and subsequent changes, it could also happen\nthat there are extra ADD events:\n\n* ADD: _NEW_ locally detected client\n* ADD: already existing client with new flags\n* DEL: disappeared local client\n\nThe first and the last type of event could in theory still be removed\ntogether from the (to be announced) events queue. But if the \"update flags\"\nADD is dropped together with the DEL, it would still leave global\ntranslation table of a remote node in the incorrect state - believing that\nthe client didn\u0027t disappear.\n\nIf a detected client was previously announced, a DEL event must only\noverwrite the \"update flags\" ADD but the DEL itself must still continue to\nexist in the (to be anounced) events queue. For now, adjustment of the\nannounced flags is used for everything instead of dropping already queued\nup events completely.\n\nSimilarly, a DEL followed by an ADD caused both entries to be deleted. But\nthe new ADD could announce flags changes which were not yet present for the\nclient before it was marked for DELetion. The new ADD must therefore only\noverwrite the DEL - but still be kept.\n\nCc: stable@vger.kernel.org\nFixes: 3c4f7ab60cc2 (\"batman-adv: improve the TT component to support runtime flag changes\")\nSigned-off-by: Sven Eckelmann \u003csven@narfation.org\u003e\n" } ], "next": "c5d68abe6e7f1dbd132a602cb696fe1fff0389eb" }