Joey, could you state if our software is affected and all and which?

Base on bluez.spec file in openSUSE:Factory/bluez and 15-SP5/bluez, looks that the DBus interface of bluetooth-mesh be disabled since long time ago because bsc#1151518:

# boo#1151518
mv %{buildroot}%{_datadir}/dbus-1/system.d/bluetooth-mesh.conf %{buildroot}%{_defaultdocdir}/%{name}
mv %{buildroot}%{_datadir}/dbus-1/system-services/org.bluez.mesh.service %{buildroot}%{_defaultdocdir}/%{name}
cat > %{buildroot}%{_defaultdocdir}/%{name}/README-mesh.SUSE << EOF
The bluetooth-mesh dbus system config has been disabled due to security
concerns. See https://bugzilla.opensuse.org/show_bug.cgi?id=1151518 for
details.

If you want to use this feature anyway, copy
bluetooth-mesh.conf to %{_sysconfdir}/dbus-1/systemd.d/ and
org.bluez.mesh.service to %{_sysconfdir}/dbus-1/system-services/,
then reboot.
EOF
touch -r %{SOURCE0} %{buildroot}%{_defaultdocdir}/%{name}/README-mesh.SUSE
%endif

I am looking at if SUSE bluz is not really affected by this issue.

(In reply to Joey Lee from comment #2)
[...]
> I am looking at if SUSE bluz is not really affected by this issue.

Do we have any conclusion? Should we close as not-affected?

Sorry for my delay. I set the bsc#1215239 (CVE-2020-26556) and bsc#1215242 (CVE-2020-26559) to WONFIX. Both of them are M-A3 attack in IEEE paper. The reason is:

After read the IEEE paper "BlueMirror: Reflections on Bluetooth Pairing and Provisioning Protocols" and "Mesh Profile Bluetooth ® Specification Revision: v1.0". I set this issue to WONFIX because the M-A3 attack is against Link Manager layer in chip. And the weakness is in crypto in the Provisioning protocol. 

Kernel is NOT aware the M-A3 attack in LM layer. So I didn't see any solution or workaround can be implemented in bluez.

For remission, the mesh service already be disabled by default because boo#1151518. And bluez package has a warning document :

/usr/share/doc/packages/bluez/README-mesh.SUSE

I am looking at bsc#1215243 (CVE-2020-26560). It's M-A1 attack in the IEEE paper which is also against Mesh Provisioning protocol in Link Manager layer. Like M-A3 attack, I do not think that kernel/userland bluez can do anything for block such attacks. 

After confirmation, I will put comment here.

After read the IEEE paper "BlueMirror: Reflections on Bluetooth Pairing and Provisioning Protocols" and "Mesh Profile Bluetooth ® Specification Revision: v1.0". In the IEEE paper, this CVE-2020-26560 is M-A1 attack. 

I set this issue to WONFIX because the M-A1 attack is against Link Manager layer in chip, likes M-A3 attack (bsc#1215239/CVE-2020-26556 and bsc#1215242/CVE-2020-26559). 

The difference between M-A3 is that the weakness of M-A1 is Reflection (M-R2) in the Provisioning protocol. The attacker runs MitM (Man-in-the-middle attack) between Provisioner and Device. Finally the attacker will take ProvisioningData and can register to mesh network through Provisioner because Provisioner used attacker's random number Na0, not the random number Nd from device. Attacker will get NetKey finally.

So, M-A1 presents a symptom that a legal device can not register to mesh network success. But, this behavior can not be used to workaround M-A1 because provisioner does NOT aware that the attacker is a illegal device. And the authentication stage of provisioning process is success. So provisioner does NOT have chance to reset NetKey.

The only possibility is that a careful user (human) notice that a legal device's registration failed. But a device registration failed may has other reasons. And unconditionally reset NetKey does not make sense.

Kernel is also NOT aware the M-A1 attack which is in LM layer in chip. So I didn't see any solution or workaround can be implemented in bluez.

For remission, the mesh service already be disabled by default because boo#1151518. And bluez package has a warning document :

/usr/share/doc/packages/bluez/README-mesh.SUSE

The bluetooth-mesh dbus system config has been disabled due to security
concerns. See https://bugzilla.opensuse.org/show_bug.cgi?id=1151518 for
details.

If you want to use this feature anyway, copy
bluetooth-mesh.conf to /etc/dbus-1/systemd.d/ and
org.bluez.mesh.service to /etc/dbus-1/system-services/,
then reboot.

If anyone has better idea, just reopen and put suggestion on bug.

Thanks!