L2CAP/LE/CPU/BI-02-C should be corrected as L2CAP/LE/CPU/BV-02-C. The
former one is not included in the test scope.

** Summary changed:

- Fix L2CAP/LE/CPU/BI-02-C bluetooth certification failure 
+ Fix L2CAP/LE/CPU/BV-02-C bluetooth certification failure

** Description changed:

  SRU Jusitification for Kernel
  
  [Impact]
  
- Noble failed the L2CAP/LE/CPU/BI-02-C test in the Porfile Tuning Suite
+ Noble failed the L2CAP/LE/CPU/BV-02-C test in the Porfile Tuning Suite
  (PTS), which Jammy previously could pass.
  
  This is due to new behavior introduced in
  e4b019515f950b4e6e5b74b2e1bb03a90cb33039 (Bluetooth: Enforce validation
  on max value of connection interval). The kernel only accept Connection
  Parameter Update Requests whose incoming conn_max_interval are lower
  than the current conn_max_interval, and adjust the newer
  conn_max_interval to that received max value.
  
  However, this behavior means that conn_max_interval can only decrease,
  but never increase. This could potentially make the conditions for
  connection parameters narrower over time, causing subsequent connections
  failed on some devices. See the issue 847 in bluez upstream[1]. The
  patch 806a5198c05987b748b50f3d0c0cfb3d417381a4 (Bluetooth: L2CAP: Fix
  rejecting L2CAP_CONN_PARAM_UPDATE_REQ) in the linux-next fixed this by
  accepting connection parameter unconditionally. The relavent test
  procedure is also on the mailing list[2].
  
  [1] https://github.com/bluez/bluez/issues/847
  [2] 
https://linuxlists.cc/l/15/linux-bluetooth/t/5350289/(patch_v3)_bluetooth:_l2cap:_fix_rejecting_l2cap_conn_param_update_req#post5352326
  
  [Fix]
  Backport the from commit 806a5198c05987b748b50f3d0c0cfb3d417381a4 (Bluetooth: 
L2CAP: Fix rejecting L2CAP_CONN_PARAM_UPDATE_REQ), which currently is in the 
linux-next.
  
  [1]
  
https://patchwork.kernel.org/project/bluetooth/patch/20240521143521.1568672-1-luiz.de...@gmail.com/
  
  [Test Case]
  1. Install the kernel with the backported patch
  2. Run the following test case in the PTS:
-  L2CAP/LE/CPU/BI-02-C
+  L2CAP/LE/CPU/BV-02-C
   GAP/CONN/CPUP/BV-05-C
  
  [Where problems could occur]
  This essentially revert the behavior of accepting L2CAP connection parameters 
back to its original state before e4b019515f950b4e6e5b74b2e1bb03a90cb33039 
(Bluetooth: Enforce validation on max value of connection interval).
  
  Note that implementing restriction to the conenction parameters may take
  greater effort than just adding a few checks in the kernel. The user
  space, notably the bluetoothd may also need adjustments[1]. So in this
  case, removing the half-done boundary checks in kernel may still do
  greater good if there's no plan to make those additional changes.
  
  [1] https://github.com/bluez/bluez/issues/717#issuecomment-1885719058

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2072858

Title:
  Fix L2CAP/LE/CPU/BV-02-C bluetooth certification failure

Status in OEM Priority Project:
  New
Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Jammy:
  Fix Committed
Status in linux source package in Noble:
  Fix Committed

Bug description:
  SRU Jusitification for Kernel

  [Impact]

  Noble failed the L2CAP/LE/CPU/BV-02-C test in the Porfile Tuning Suite
  (PTS), which Jammy previously could pass.

  This is due to new behavior introduced in
  e4b019515f950b4e6e5b74b2e1bb03a90cb33039 (Bluetooth: Enforce
  validation on max value of connection interval). The kernel only
  accept Connection Parameter Update Requests whose incoming
  conn_max_interval are lower than the current conn_max_interval, and
  adjust the newer conn_max_interval to that received max value.

  However, this behavior means that conn_max_interval can only decrease,
  but never increase. This could potentially make the conditions for
  connection parameters narrower over time, causing subsequent
  connections failed on some devices. See the issue 847 in bluez
  upstream[1]. The patch 806a5198c05987b748b50f3d0c0cfb3d417381a4
  (Bluetooth: L2CAP: Fix rejecting L2CAP_CONN_PARAM_UPDATE_REQ) in the
  linux-next fixed this by accepting connection parameter
  unconditionally. The relavent test procedure is also on the mailing
  list[2].

  [1] https://github.com/bluez/bluez/issues/847
  [2] 
https://linuxlists.cc/l/15/linux-bluetooth/t/5350289/(patch_v3)_bluetooth:_l2cap:_fix_rejecting_l2cap_conn_param_update_req#post5352326

  [Fix]
  Backport the from commit 806a5198c05987b748b50f3d0c0cfb3d417381a4 (Bluetooth: 
L2CAP: Fix rejecting L2CAP_CONN_PARAM_UPDATE_REQ), which currently is in the 
linux-next.

  [1]
  
https://patchwork.kernel.org/project/bluetooth/patch/20240521143521.1568672-1-luiz.de...@gmail.com/

  [Test Case]
  1. Install the kernel with the backported patch
  2. Run the following test case in the PTS:
   L2CAP/LE/CPU/BV-02-C
   GAP/CONN/CPUP/BV-05-C

  [Where problems could occur]
  This essentially revert the behavior of accepting L2CAP connection parameters 
back to its original state before e4b019515f950b4e6e5b74b2e1bb03a90cb33039 
(Bluetooth: Enforce validation on max value of connection interval).

  Note that implementing restriction to the conenction parameters may
  take greater effort than just adding a few checks in the kernel. The
  user space, notably the bluetoothd may also need adjustments[1]. So in
  this case, removing the half-done boundary checks in kernel may still
  do greater good if there's no plan to make those additional changes.

  [1] https://github.com/bluez/bluez/issues/717#issuecomment-1885719058

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/2072858/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to