Skip to content

L
linux
Switch branch/tag
  1. 09 Oct, 2024 9 commits
  3. 08 Oct, 2024 18 commits
  5. 07 Oct, 2024 4 commits
  7. 04 Oct, 2024 9 commits
    • Christophe JAILLET's avatar
      net: phy: bcm84881: Fix some error handling paths · 9234a254
      Christophe JAILLET authored 
      If phy_read_mmd() fails, the error code stored in 'bmsr' should be returned
instead of 'val' which is likely to be 0.

Fixes: 75f4d8d1 ("net: phy: add Broadcom BCM84881 PHY driver")
Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/3e1755b0c40340d00e089d6adae5bca2f8c79e53.1727982168.git.christophe.jaillet@wanadoo.frSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9234a254
    • Anastasia Kovaleva's avatar
      net: Fix an unsafe loop on the list · 1dae9f11
      Anastasia Kovaleva authored 
      The kernel may crash when deleting a genetlink family if there are still
listeners for that family:

Oops: Kernel access of bad area, sig: 11 [#1]
  ...
  NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0
  LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0
  Call Trace:
__netlink_clear_multicast_users+0x74/0xc0
genl_unregister_family+0xd4/0x2d0

Change the unsafe loop on the list to a safe one, because inside the
loop there is an element removal from this list.

Fixes: b8273570 ("genetlink: fix netns vs. netlink table locking (2)")
Cc: stable@vger.kernel.org
Signed-off-by: default avatarAnastasia Kovaleva <a.kovaleva@yadro.com>
Reviewed-by: default avatarDmitry Bogdanov <d.bogdanov@yadro.com>
Reviewed-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
Link: https://patch.msgid.link/20241003104431.12391-1-a.kovaleva@yadro.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1dae9f11
    • Luiz Augusto von Dentz's avatar
      Bluetooth: btusb: Don't fail external suspend requests · 61071229
      Luiz Augusto von Dentz authored 
      Commit 4e0a1d8b
("Bluetooth: btusb: Don't suspend when there are connections")
introduces a check for connections to prevent auto-suspend but that
actually ignored the fact the .suspend callback can be called for
external suspend requests which
Documentation/driver-api/usb/power-management.rst states the following:

 'External suspend calls should never be allowed to fail in this way,
 only autosuspend calls.  The driver can tell them apart by applying
 the :c:func:`PMSG_IS_AUTO` macro to the message argument to the
 ``suspend`` method; it will return True for internal PM events
 (autosuspend) and False for external PM events.'

In addition to that align system suspend with USB suspend by using
hci_suspend_dev since otherwise the stack would be expecting events
such as advertising reports which may not be delivered while the
transport is suspended.

Fixes: 4e0a1d8b ("Bluetooth: btusb: Don't suspend when there are connections")
Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: default avatarKiran K <kiran.k@intel.com>
      61071229
    • Luiz Augusto von Dentz's avatar
      Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync · 18fd04ad
      Luiz Augusto von Dentz authored 
      This checks if the ACL connection remains valid as it could be destroyed
while hci_enhanced_setup_sync is pending on cmd_sync leading to the
following trace:

BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60
Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37

CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
 <TASK>
 dump_stack_lvl+0x5d/0x80
 ? hci_enhanced_setup_sync+0x91b/0xa60
 print_report+0x152/0x4c0
 ? hci_enhanced_setup_sync+0x91b/0xa60
 ? __virt_addr_valid+0x1fa/0x420
 ? hci_enhanced_setup_sync+0x91b/0xa60
 kasan_report+0xda/0x1b0
 ? hci_enhanced_setup_sync+0x91b/0xa60
 hci_enhanced_setup_sync+0x91b/0xa60
 ? __pfx_hci_enhanced_setup_sync+0x10/0x10
 ? __pfx___mutex_lock+0x10/0x10
 hci_cmd_sync_work+0x1c2/0x330
 process_one_work+0x7d9/0x1360
 ? __pfx_lock_acquire+0x10/0x10
 ? __pfx_process_one_work+0x10/0x10
 ? assign_work+0x167/0x240
 worker_thread+0x5b7/0xf60
 ? __kthread_parkme+0xac/0x1c0
 ? __pfx_worker_thread+0x10/0x10
 ? __pfx_worker_thread+0x10/0x10
 kthread+0x293/0x360
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2f/0x70
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 </TASK>

Allocated by task 34:
 kasan_save_stack+0x30/0x50
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x8f/0xa0
 __hci_conn_add+0x187/0x17d0
 hci_connect_sco+0x2e1/0xb90
 sco_sock_connect+0x2a2/0xb80
 __sys_connect+0x227/0x2a0
 __x64_sys_connect+0x6d/0xb0
 do_syscall_64+0x71/0x140
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 37:
 kasan_save_stack+0x30/0x50
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 __kasan_slab_free+0x101/0x160
 kfree+0xd0/0x250
 device_release+0x9a/0x210
 kobject_put+0x151/0x280
 hci_conn_del+0x448/0xbf0
 hci_abort_conn_sync+0x46f/0x980
 hci_cmd_sync_work+0x1c2/0x330
 process_one_work+0x7d9/0x1360
 worker_thread+0x5b7/0xf60
 kthread+0x293/0x360
 ret_from_fork+0x2f/0x70
 ret_from_fork_asm+0x1a/0x30

Cc: stable@vger.kernel.org
Fixes: e07a06b4 ("Bluetooth: Convert SCO configure_datapath to hci_sync")
Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      18fd04ad
    • Luiz Augusto von Dentz's avatar
      Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change · 08d19142
      Luiz Augusto von Dentz authored 
      rfcomm_sk_state_change attempts to use sock_lock so it must never be
called with it locked but rfcomm_sock_ioctl always attempt to lock it
causing the following trace:

======================================================
WARNING: possible circular locking dependency detected
6.8.0-syzkaller-08951-gfe46a7dd #0 Not tainted
------------------------------------------------------
syz-executor386/5093 is trying to acquire lock:
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73

but task is already holding lock:
ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491

Reported-by: syzbot+d7ce59b06b3eb14fd218@syzkaller.appspotmail.com
Tested-by: syzbot+d7ce59b06b3eb14fd218@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d7ce59b06b3eb14fd218
Fixes: 3241ad82 ("[Bluetooth] Add timestamp support to L2CAP, RFCOMM and SCO")
Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      08d19142
    • Kory Maincent's avatar
      net: pse-pd: Fix enabled status mismatch · dda3529d
      Kory Maincent authored 
      PSE controllers like the TPS23881 can forcefully turn off their
configuration state. In such cases, the is_enabled() and get_status()
callbacks will report the PSE as disabled, while admin_state_enabled
will show it as enabled. This mismatch can lead the user to attempt
to enable it, but no action is taken as admin_state_enabled remains set.

The solution is to disable the PSE before enabling it, ensuring the
actual status matches admin_state_enabled.

Fixes: d83e1376 ("net: pse-pd: Use regulator framework within PSE framework")
Signed-off-by: default avatarKory Maincent <kory.maincent@bootlin.com>
Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20241002121706.246143-1-kory.maincent@bootlin.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      dda3529d
    • Kacper Ludwinski's avatar
      selftests: net: no_forwarding: fix VID for $swp2 in one_bridge_two_pvids() test · 9f49d14e
      Kacper Ludwinski authored 
      Currently, the second bridge command overwrites the first one.
Fix this by adding this VID to the interface behind $swp2.

The one_bridge_two_pvids() test intends to check that there is no
leakage of traffic between bridge ports which have a single VLAN - the
PVID VLAN.

Because of a typo, port $swp1 is configured with a PVID twice (second
command overwrites first), and $swp2 isn't configured at all (and since
the bridge vlan_default_pvid property is set to 0, this port will not
have a PVID at all, so it will drop all untagged and priority-tagged
traffic).

So, instead of testing the configuration that was intended, we are
testing a different one, where one port has PVID 2 and the other has
no PVID. This incorrect version of the test should also pass, but is
ineffective for its purpose, so fix the typo.

This typo has an impact on results of the test,
potentially leading to wrong conclusions regarding
the functionality of a network device.

The tests results:

TEST: Switch ports in VLAN-aware bridge with different PVIDs:
	Unicast non-IP untagged   [ OK ]
	Multicast non-IP untagged   [ OK ]
	Broadcast non-IP untagged   [ OK ]
	Unicast IPv4 untagged   [ OK ]
	Multicast IPv4 untagged   [ OK ]
	Unicast IPv6 untagged   [ OK ]
	Multicast IPv6 untagged   [ OK ]
	Unicast non-IP VID 1   [ OK ]
	Multicast non-IP VID 1   [ OK ]
	Broadcast non-IP VID 1   [ OK ]
	Unicast IPv4 VID 1   [ OK ]
	Multicast IPv4 VID 1   [ OK ]
	Unicast IPv6 VID 1   [ OK ]
	Multicast IPv6 VID 1   [ OK ]
	Unicast non-IP VID 4094   [ OK ]
	Multicast non-IP VID 4094   [ OK ]
	Broadcast non-IP VID 4094   [ OK ]
	Unicast IPv4 VID 4094   [ OK ]
	Multicast IPv4 VID 4094   [ OK ]
	Unicast IPv6 VID 4094   [ OK ]
	Multicast IPv6 VID 4094   [ OK ]

Fixes: 476a4f05 ("selftests: forwarding: add a no_forwarding.sh test")
Reviewed-by: default avatarHangbin Liu <liuhangbin@gmail.com>
Reviewed-by: default avatarShuah Khan <skhan@linuxfoundation.org>
Signed-off-by: default avatarKacper Ludwinski <kac.ludwinski@icloud.com>
Link: https://patch.msgid.link/20241002051016.849-1-kac.ludwinski@icloud.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9f49d14e
    • Jakub Kicinski's avatar
      Merge branch 'ibmvnic-fix-for-send-scrq-direct' · 500257db
      Jakub Kicinski authored 
      Nick Child says:

====================
ibmvnic: Fix for send scrq direct

This is a v2 of a patchset (now just patch) which addresses a
bug in a new feature which is causing major link UP issues with
certain physical cards.

For a full summary of the issue:
  1. During vnic initialization we get the following values from vnic
     server regarding "Transmit / Receive Descriptor Requirement" (see
      PAPR Table 584. CAPABILITIES Commands):
    - LSO Tx frame = 0x0F , header offsets + L2, L3, L4 headers required
    - CSO Tx frame = 0x0C , header offsets + L2 header required
    - standard frame = 0x0C , header offsets + L2 header required
  2. Assume we are dealing with only "standard frames" from now on (no
     CSO, no LSO)
  3. When using 100G backing device, we don't hand vnic server any header
     information and TX is successful
  4. When using 25G backing device, we don't hand vnic server any header
    information and TX fails and we get "Adapter Error" transport events.
The obvious issue here is that vnic client should be respecting the 0X0C
header requirement for standard frames.  But 100G cards will also give
0x0C despite the fact that we know TX works if we ignore it. That being
said, we still must respect values given from the managing server. Will
need to work with them going forward to hopefully get 100G cards to
return 0x00 for this bitstring so the performance gains of using
send_subcrq_direct can be continued.
====================

Link: https://patch.msgid.link/20241001163200.1802522-1-nnac123@linux.ibm.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      500257db
    • Nick Child's avatar
      ibmvnic: Inspect header requirements before using scrq direct · de390657
      Nick Child authored 
      Previously, the TX header requirement for standard frames was ignored.
This requirement is a bitstring sent from the VIOS which maps to the
type of header information needed during TX. If no header information,
is needed then send subcrq direct can be used (which can be more
performant).

This bitstring was previously ignored for standard packets (AKA non LSO,
non CSO) due to the belief that the bitstring was over-cautionary. It
turns out that there are some configurations where the backing device
does need header information for transmission of standard packets. If
the information is not supplied then this causes continuous "Adapter
error" transport events. Therefore, this bitstring should be respected
and observed before considering the use of send subcrq direct.

Fixes: 74839f7a ("ibmvnic: Introduce send sub-crq direct")
Signed-off-by: default avatarNick Child <nnac123@linux.ibm.com>
Reviewed-by: default avatarSimon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20241001163200.1802522-2-nnac123@linux.ibm.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      de390657
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7