- 07 Dec, 2022 6 commits
-
-
Zhengchao Shao authored
When dsa_devlink_region_create failed in sja1105_setup_devlink_regions(), priv->regions is not released. Fixes: bf425b82 ("net: dsa: sja1105: expose static config as devlink region") Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20221205012132.2110979-1-shaozhengchao@huawei.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Ido Schimmel says: ==================== ipv4: Two small fixes for bugs in IPv4 routing code. A variation of the second bug was reported by an FRR 5.0 (released 06/18) user as this version was setting a table ID of 0 for the default VRF, unlike iproute2 and newer FRR versions. The first bug was discovered while fixing the second. Both bugs are not regressions (never worked) and are not critical in my opinion, so the fixes can be applied to net-next, if desired. No regressions in other tests: # ./fib_tests.sh ... Tests passed: 191 Tests failed: 0 ==================== Link: https://lore.kernel.org/r/20221204075045.3780097-1-idosch@nvidia.comSigned-off-by:
-
Ido Schimmel authored
Cited commit added the table ID to the FIB info structure, but did not properly initialize it when table ID 0 is used. This can lead to a route in the default VRF with a preferred source address not being flushed when the address is deleted. Consider the following example: # ip address add dev dummy1 192.0.2.1/28 # ip address add dev dummy1 192.0.2.17/28 # ip route add 198.51.100.0/24 via 192.0.2.2 src 192.0.2.17 metric 100 # ip route add table 0 198.51.100.0/24 via 192.0.2.2 src 192.0.2.17 metric 200 # ip route show 198.51.100.0/24 198.51.100.0/24 via 192.0.2.2 dev dummy1 src 192.0.2.17 metric 100 198.51.100.0/24 via 192.0.2.2 dev dummy1 src 192.0.2.17 metric 200 Both routes are installed in the default VRF, but they are using two different FIB info structures. One with a metric of 100 and table ID of 254 (main) and one with a metric of 200 and table ID of 0. Therefore, when the preferred source address is deleted from the default VRF, the second route is not flushed: # ip address del dev dummy1 192.0.2.17/28 # ip route show 198.51.100.0/24 198.51.100.0/24 via 192.0.2.2 dev dummy1 src 192.0.2.17 metric 200 Fix by storing a table ID of 254 instead of 0 in the route configuration structure. Add a test case that fails before the fix: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Table ID 0 TEST: Route removed in default VRF when source address deleted [FAIL] Tests passed: 8 Tests failed: 1 And passes after: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Table ID 0 TEST: Route removed in default VRF when source address deleted [ OK ] Tests passed: 9 Tests failed: 0 Fixes: 5a56a0b3 ("net: Don't delete routes in different VRFs") Reported-by:Donald Sharp <sharpd@nvidia.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
-
Ido Schimmel authored
Cited commit added the table ID to the FIB info structure, but did not prevent structures with different table IDs from being consolidated. This can lead to routes being flushed from a VRF when an address is deleted from a different VRF. Fix by taking the table ID into account when looking for a matching FIB info. This is already done for FIB info structures backed by a nexthop object in fib_find_info_nh(). Add test cases that fail before the fix: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [FAIL] TEST: Route in default VRF not removed [ OK ] RTNETLINK answers: File exists TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [FAIL] Tests passed: 6 Tests failed: 2 And pass after: # ./fib_tests.sh -t ipv4_del_addr IPv4 delete address route tests Regular FIB info TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Identical FIB info with different table ID TEST: Route removed from VRF when source address deleted [ OK ] TEST: Route in default VRF not removed [ OK ] TEST: Route removed in default VRF when source address deleted [ OK ] TEST: Route in VRF is not removed by address delete [ OK ] Tests passed: 8 Tests failed: 0 Fixes: 5a56a0b3 ("net: Don't delete routes in different VRFs") Signed-off-by: -
Rasmus Villemoes authored
Prior to the Fixes: commit, the initialization code went through the same fec_enet_set_coalesce() function as used by ethtool, and that function correctly checks whether the current variant has support for irq coalescing. Now that the initialization code instead calls fec_enet_itr_coal_set() directly, that call needs to be guarded by a check for the FEC_QUIRK_HAS_COALESCE bit. Fixes: df727d45 (net: fec: don't reset irq coalesce settings to defaults on "ip link up") Reported-by:
Greg Ungerer <gregungerer@westnet.com.au> Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by:
-
Hangbin Liu authored
In commit 4d633d1b ("bonding: fix ICMPv6 header handling when receiving IPv6 messages"), there is a copy/paste issue for NA daddr. I found that in my testing and fixed it in my local branch. But I forgot to re-format the patch and sent the wrong mail. Fix it by reading the correct dest address. Fixes: 4d633d1b ("bonding: fix ICMPv6 header handling when receiving IPv6 messages") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Acked-by:
Jonathan Toppins <jtoppins@redhat.com> Link: https://lore.kernel.org/r/20221206032055.7517-1-liuhangbin@gmail.comSigned-off-by:
-
- 06 Dec, 2022 12 commits
-
-
YueHaibing authored
Fix the potential risk of OOB if skb_linearize() fails in tipc_link_proto_rcv(). Fixes: 5cbb28a4 ("tipc: linearize arriving NAME_DISTR and LINK_PROTO buffers") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20221203094635.29024-1-yuehaibing@huawei.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Liu Jian authored
The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free. Fixes: 57c5bc9a ("net: hisilicon: add hix5hd2 mac driver") Signed-off-by:
Liu Jian <liujian56@huawei.com> Link: https://lore.kernel.org/r/20221203094240.1240211-2-liujian56@huawei.comSigned-off-by:
-
Zeng Heng authored
There is warning report about of_node refcount leak while probing mdio device: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4 In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly. After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced. Fixes: a9049e0c ("mdio: Add support for mdio drivers.") Signed-off-by:
Zeng Heng <zengheng4@huawei.com> Reviewed-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20221203073441.3885317-1-zengheng4@huawei.comSigned-off-by:
-
Liu Jian authored
The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free. Fixes: 542ae60a ("net: hisilicon: Add Fast Ethernet MAC driver") Signed-off-by:
-
Yongqiang Liu authored
The nicvf_probe() won't destroy workqueue when register_netdev() failed. Add destroy_workqueue err handle case to fix this issue. Fixes: 2ecbe4f4 ("net: thunderx: replace global nicvf_rx_mode_wq work queue for all VFs to private for each of them.") Signed-off-by:
Yongqiang Liu <liuyongqiang13@huawei.com> Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://lore.kernel.org/r/20221203094125.602812-1-liuyongqiang13@huawei.comSigned-off-by:
-
YueHaibing authored
The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free. Fixes: 1c59eb67 ("ravb: Fillup ravb_rx_gbeth() stub") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20221203092941.10880-1-yuehaibing@huawei.comSigned-off-by:
-
Qiheng Lin authored
The mchp_sparx5_probe() won't destroy workqueue created by create_singlethread_workqueue() in sparx5_start() when later inits failed. Add destroy_workqueue in the cleanup_ports case, also add it in mchp_sparx5_remove() Fixes: b37a1bae ("net: sparx5: add mactable support") Signed-off-by:
Qiheng Lin <linqiheng@huawei.com> Link: https://lore.kernel.org/r/20221203070259.19560-1-linqiheng@huawei.comSigned-off-by:
-
Hangbin Liu authored
Although the type I ERSPAN is based on the barebones IP + GRE encapsulation and no extra ERSPAN header. Report erspan version on GRE interface looks unreasonable. Fix this by separating the erspan and gre fill info. IPv6 GRE does not have this info as IPv6 only supports erspan version 1 and 2. Reported-by:
Jianlin Shi <jishi@redhat.com> Fixes: f989d546 ("erspan: Add type I version 0 support.") Signed-off-by:
William Tu <u9012063@gmail.com> Link: https://lore.kernel.org/r/20221203032858.3130339-1-liuhangbin@gmail.comSigned-off-by:
-
Zhengchao Shao authored
When failed to alloc ipc_mux->ul_adb.pp_qlt in ipc_mux_init(), ipc_mux is not released. Fixes: 1f52d7b6 ("net: wwan: iosm: Enable M.2 7360 WWAN card support") Signed-off-by:
M Chetan Kumar <m.chetan.kumar@intel.com> Link: https://lore.kernel.org/r/20221203020903.383235-1-shaozhengchao@huawei.comSigned-off-by:
-
Haiyang Zhang authored
After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be cleared, and another CPU can start napi thread and access per-CQ variable, cq->work_done. If the other thread (for example, from busy_poll) sets it to a value >= budget, this thread will continue to run when it should stop, and cause memory corruption and panic. To fix this issue, save the per-CQ work_done variable in a local variable before napi_complete_done(), so it won't be corrupted by a possible concurrent thread after napi_complete_done(). Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done variable race is fixed, so the driver is able to reliably support features like busy_poll. Cc: stable@vger.kernel.org Fixes: e1b5683f ("net: mana: Move NAPI from EQ to CQ") Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Link: https://lore.kernel.org/r/1670010190-28595-1-git-send-email-haiyangz@microsoft.comSigned-off-by:
-
Jisheng Zhang authored
In dt-binding snps,dwmac.yaml, some properties under "snps,axi-config" node are named without "axi_" prefix, but the driver expects the prefix. Since the dt-binding has been there for a long time, we'd better make driver match the binding for compatibility. Fixes: afea0365 ("stmmac: rework DMA bus setting and introduce new platform AXI structure") Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Link: https://lore.kernel.org/r/20221202161739.2203-1-jszhang@kernel.orgSigned-off-by:
-
Kees Cook authored
While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks. Reported-by: syzbot+210e196cef4711b65139@syzkaller.appspotmail.com Link: https://lore.kernel.org/lkml/0000000000001c590f05ee7b3ff4@google.com Fixes: 019c4fba ("NFC: Add NCI multiple targets support") Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20221202214410.never.693-kees@kernel.orgSigned-off-by:
-
- 05 Dec, 2022 7 commits
-
-
Dan Carpenter authored
The pp->indir[0] value comes from the user. It is passed to: if (cpu_online(pp->rxq_def)) inside the mvneta_percpu_elect() function. It needs bounds checkeding to ensure that it is not beyond the end of the cpu bitmap. Fixes: cad5d847 ("net: mvneta: Fix the CPU choice in mvneta_percpu_elect") Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Lin Liu authored
A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]--- xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time Signed-off-by:
Lin Liu <lin.liu@citrix.com> Fixes: 4ec24119 ([NET]: Do not check netif_running() and carrier state in ->poll()) Signed-off-by:
-
Casper Andersson authored
consume_skb on transmitted, kfree_skb on dropped, do not free on TX_BUSY. Previously the xmit function could return -EBUSY without freeing, which supposedly is interpreted as a drop. And was using kfree on successfully transmitted packets. sparx5_fdma_xmit and sparx5_inject returns error code, where -EBUSY indicates TX_BUSY and any other error code indicates dropped. Fixes: f3cad261 ("net: sparx5: add hostmode with phylink support") Signed-off-by:
Casper Andersson <casper.casan@gmail.com> Reviewed-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Ziyang Xuan authored
In otx2_init_tc(), if rhashtable_init() failed, it does not free tc->tc_entries_bitmap which is allocated in otx2_tc_alloc_ent_bitmap(). Fixes: 2e2a8126 ("octeontx2-pf: Unify flow management variables") Signed-off-by:
Ziyang Xuan <william.xuanziyang@huawei.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
Yang Yingliang authored
If phy_device_register() or fwnode_mdiobus_phy_device_register() fail, phy_device_free() is called, the device refcount is decreased to 0, then fwnode_handle_put() will be called in phy_device_release(), but in the error path, fwnode_handle_put() has already been called, so set fwnode to NULL after fwnode_handle_put() in the error path to avoid double put. Fixes: cdde1560 ("net: mdiobus: fix unbalanced node reference count") Reported-by:
-
Valentina Goncharenko authored
A loop for reading MISTAT register continues while regmap_read() fails and (mistat & BUSY), but if regmap_read() fails a value of mistat is undefined. The patch proposes to check for BUSY flag only when regmap_read() succeed. Compile test only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d70e5326 ("net: Microchip encx24j600 driver") Signed-off-by:
Valentina Goncharenko <goncharenko.vp@ispras.ru> Reviewed-by:
-
Valentina Goncharenko authored
In functions regmap_encx24j600_phy_reg_read() and regmap_encx24j600_phy_reg_write() in the conditions of the waiting cycles for filling the variable 'ret' it is necessary to add parentheses to prevent wrong assignment due to logical operations precedence. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d70e5326 ("net: Microchip encx24j600 driver") Signed-off-by:
-
- 04 Dec, 2022 1 commit
-
-
Yinjun Zhang authored
When there's only one buffer to dma and its length is 4096, then only one data descriptor is needed to carry it according to current descriptor definition. So the descriptor type should be `simple` instead of `gather`, the latter requires more than one descriptor, otherwise it'll be dropped by application firmware. Fixes: c10d12e3 ("nfp: add support for NFDK data path") Fixes: d9d95049 ("nfp: nfdk: implement xdp tx path for NFDK") Signed-off-by:
Yinjun Zhang <yinjun.zhang@corigine.com> Reviewed-by:
Richard Donkin <richard.donkin@corigine.com> Reviewed-by:
Niklas Söderlund <niklas.soderlund@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
-
- 03 Dec, 2022 7 commits
-
-
Tiezhu Yang authored
The latest version of grep claims the egrep is now obsolete so the build now contains warnings that look like: egrep: warning: egrep is obsolescent; using grep -E fix this using "grep -E" instead. sed -i "s/egrep/grep -E/g" `grep egrep -rwl tools/testing/selftests/net` Here are the steps to install the latest grep: wget http://ftp.gnu.org/gnu/grep/grep-3.8.tar.gz tar xf grep-3.8.tar.gz cd grep-3.8 && ./configure && make sudo make install export PATH=/usr/local/bin:$PATH Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Link: https://lore.kernel.org/r/1669864248-829-1-git-send-email-yangtiezhu@loongson.cnSigned-off-by:
-
Zhengchao Shao authored
When testing in kci_test_ipsec_offload, srcip is configured as $dstip, it should add xfrm policy rule in instead of out. The test result of this patch is as follows: PASS: ipsec_offload Fixes: 2766a111 ("selftests: rtnetlink: add ipsec offload API test") Signed-off-by:
-
Tianjia Zhang authored
Commit d2825fa9 ("crypto: sm3,sm4 - move into crypto directory") moves SM3 and SM4 algorithm implementations from stand-alone library to crypto API. The corresponding configuration options for the API version (generic) are CONFIG_CRYPTO_SM3_GENERIC and CONFIG_CRYPTO_SM4_GENERIC, respectively. Replace option selected in selftests configuration from the library version to the API version. Fixes: d2825fa9 ("crypto: sm3,sm4 - move into crypto directory") Reported-by:
Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Link: https://lore.kernel.org/r/20221201131852.38501-1-tianjia.zhang@linux.alibaba.comSigned-off-by:
-
Artem Chernyshev authored
Return NULL if we got unexpected value from skb_trim_rcsum() in sja1110_rcv_inband_control_extension() Fixes: 4913b8eb ("net: dsa: add support for the SJA1110 native tagging protocol") Signed-off-by:
Artem Chernyshev <artem.chernyshev@red-soft.ru> Reviewed-by:
-
Artem Chernyshev authored
Return NULL if we got unexpected value from skb_trim_rcsum() in hellcreek_rcv() Fixes: 01ef09ca ("net: dsa: Add tag handling for Hirschmann Hellcreek switches") Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Link: https://lore.kernel.org/r/20221201140032.26746-2-artem.chernyshev@red-soft.ruSigned-off-by:
-
Artem Chernyshev authored
Return NULL if we got unexpected value from skb_trim_rcsum() in ksz_common_rcv() Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bafe9ba7 ("net: dsa: ksz: Factor out common tag code") Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetoothJakub Kicinski authored
Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - Fix regressions with CSR controller clones - Fix support for Read Local Supported Codecs V2 - Fix overflow on L2CAP code - Fix missing hci_dev_put on ISO and L2CAP code * tag 'for-net-2022-12-02' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: Fix crash when replugging CSR fake controllers Bluetooth: Fix not cleanup led when bt_init fails Bluetooth: Fix support for Read Local Supported Codecs V2 Bluetooth: Remove codec id field in vendor codec definition Bluetooth: L2CAP: Fix u8 overflow Bluetooth: silence a dmesg error message in hci_request.c Bluetooth: hci_conn: add missing hci_dev_put() in iso_listen_bis() Bluetooth: 6LoWPAN: add missing hci_dev_put() in get_l2cap_conn() Bluetooth: btusb: Add debug message for CSR controllers Bluetooth: btusb: Fix CSR clones again by re-adding ERR_DATA_REPORTING quirk ==================== Link: https://lore.kernel.org/r/20221202213726.2801581-1-luiz.dentz@gmail.comSigned-off-by:
-
- 02 Dec, 2022 7 commits
-
-
Luiz Augusto von Dentz authored
It seems fake CSR 5.0 clones can cause the suspend notifier to be registered twice causing the following kernel panic: [ 71.986122] Call Trace: [ 71.986124] <TASK> [ 71.986125] blocking_notifier_chain_register+0x33/0x60 [ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da] [ 71.986154] btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477] [ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300 [ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90 [ 71.986167] usb_probe_interface+0xe3/0x2b0 [ 71.986171] really_probe+0xdb/0x380 [ 71.986174] ? pm_runtime_barrier+0x54/0x90 [ 71.986177] __driver_probe_device+0x78/0x170 [ 71.986180] driver_probe_device+0x1f/0x90 [ 71.986183] __device_attach_driver+0x89/0x110 [ 71.986186] ? driver_allows_async_probing+0x70/0x70 [ 71.986189] bus_for_each_drv+0x8c/0xe0 [ 71.986192] __device_attach+0xb2/0x1e0 [ 71.986195] bus_probe_device+0x92/0xb0 [ 71.986198] device_add+0x422/0x9a0 [ 71.986201] ? sysfs_merge_group+0xd4/0x110 [ 71.986205] usb_set_configuration+0x57a/0x820 [ 71.986208] usb_generic_driver_probe+0x4f/0x70 [ 71.986211] usb_probe_device+0x3a/0x110 [ 71.986213] really_probe+0xdb/0x380 [ 71.986216] ? pm_runtime_barrier+0x54/0x90 [ 71.986219] __driver_probe_device+0x78/0x170 [ 71.986221] driver_probe_device+0x1f/0x90 [ 71.986224] __device_attach_driver+0x89/0x110 [ 71.986227] ? driver_allows_async_probing+0x70/0x70 [ 71.986230] bus_for_each_drv+0x8c/0xe0 [ 71.986232] __device_attach+0xb2/0x1e0 [ 71.986235] bus_probe_device+0x92/0xb0 [ 71.986237] device_add+0x422/0x9a0 [ 71.986239] ? _dev_info+0x7d/0x98 [ 71.986242] ? blake2s_update+0x4c/0xc0 [ 71.986246] usb_new_device.cold+0x148/0x36d [ 71.986250] hub_event+0xa8a/0x1910 [ 71.986255] process_one_work+0x1c4/0x380 [ 71.986259] worker_thread+0x51/0x390 [ 71.986262] ? rescuer_thread+0x3b0/0x3b0 [ 71.986264] kthread+0xdb/0x110 [ 71.986266] ? kthread_complete_and_exit+0x20/0x20 [ 71.986268] ret_from_fork+0x1f/0x30 [ 71.986273] </TASK> [ 71.986274] ---[ end trace 0000000000000000 ]--- [ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216683 Cc: stable@vger.kernel.org Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Tested-by:
Leonardo Eugênio <lelgenio@disroot.org>
-
Chen Zhongjin authored
bt_init() calls bt_leds_init() to register led, but if it fails later, bt_leds_cleanup() is not called to unregister it. This can cause panic if the argument "bluetooth-power" in text is freed and then another led_trigger_register() tries to access it: BUG: unable to handle page fault for address: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30 Call Trace: <TASK> led_trigger_register+0x10d/0x4f0 led_trigger_register_simple+0x7d/0x100 bt_init+0x39/0xf7 [bluetooth] do_one_initcall+0xd0/0x4e0 Fixes: e64c97b5 ("Bluetooth: Add combined LED trigger for controller power") Signed-off-by:Chen Zhongjin <chenzhongjin@huawei.com> Signed-off-by:
-
Chethan T N authored
Handling of Read Local Supported Codecs was broken during the HCI serialization design change patches. Fixes: d0b13706 ("Bluetooth: hci_sync: Rework init stages") Signed-off-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by:
Kiran K <kiran.k@intel.com> Signed-off-by:
-
Chethan T N authored
As per the specfication vendor codec id is defined. BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E page 2127 Fixes: 9ae66402 ("Bluetooth: Add support for Read Local Supported Codecs V2") Signed-off-by:
-
Sungwoo Kim authored
By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@... Signed-off-by:Sungwoo Kim <iam@sung-woo.kim> Signed-off-by:
-
Mateusz Jończyk authored
On kernel 6.1-rcX, I have been getting the following dmesg error message on every boot, resume from suspend and rfkill unblock of the Bluetooth device: Bluetooth: hci0: HCI_REQ-0xfcf0 After some investigation, it turned out to be caused by commit dd50a864 ("Bluetooth: Delete unreferenced hci_request code") which modified hci_req_add() in net/bluetooth/hci_request.c to always print an error message when it is executed. In my case, the function was executed by msft_set_filter_enable() in net/bluetooth/msft.c, which provides support for Microsoft vendor opcodes. As explained by Brian Gix, "the error gets logged because it is using a deprecated (but still working) mechanism to issue HCI opcodes" [1]. So this is just a debugging tool to show that a deprecated function is executed. As such, it should not be included in the mainline kernel. See for example commit 771c0353 ("deprecate the '__deprecated' attribute warnings entirely and for good") Additionally, this error message is cryptic and the user is not able to do anything about it. [1] Link: https://lore.kernel.org/lkml/beb8dcdc3aee4c5c833aa382f35995f17e7961a1.camel@intel.com/ Fixes: dd50a864 ("Bluetooth: Delete unreferenced hci_request code") Signed-off-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: Brian Gix <brian.gix@intel.com> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Signed-off-by:
-
Wang ShaoBo authored
hci_get_route() takes reference, we should use hci_dev_put() to release it when not need anymore. Fixes: f764a6c2 ("Bluetooth: ISO: Add broadcast support") Signed-off-by:
Wang ShaoBo <bobo.shaobowang@huawei.com> Signed-off-by:
-
