summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Don't specify a conflicting type for setField callsVolker Hilsheimer2025-12-015-6/+6
| | | | | | | | | | | | | | | | | | On 32bit builds, jlong is `long long`, so passing in a long and claiming that it's a jlong is wrong. This causes a build failure after the addition of optional exception handling for QJniObject calls in qtbase:d045e2d2b604152450a45846fc87cb53d89bf50a. Fix that by not specifying the field type explicitly, and instead consistently cast to jlong (using reinterpret_cast if we have a pointer, otherwise construct the jlong in place). This is not a problem for calls that specify e.g. jboolean and then pass a bool, as those are the same types on all platforms. Fixes: QTBUG-142334 Change-Id: Icbcab1b20157b2e9d002d2de8efd9fe4acef291d Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Doc: Fix QDoc warnings for internal classes and functionsJerome Pasion2025-11-204-4/+22
| | | | | | | | -Internal classes should have internal class documentation. Task-number: QTBUG-141665 Change-Id: If6837530f96c2c729726cc7d987bf5c394da609c Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Fix QBluetoothDeviceInfo::isCached() on WindowsIvan Solovev2025-10-091-6/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Windows backend was unconditionally marking each discovered device as cached. However, a correct thing to do it to only mark those devices that come from the OS cache. For Windows these are always the paired devices. However, there's one caveat here as well. If the device is cached, but at the same time actually available, Windows will first report it with rssi == 0 (at least in case of BTLE devices), and only then deliver an update with the correct RSSI value. This patch implements the following logic: * All newly-discovered paired devices are marked as cached first * Once there's an update, the device is not considered as cached anymore. This works fine for BTLE devices, because they regularly report at least the RSSI updates. For Classic Bluetooth we don't have any device updates during the discovery, so simply rely on the pairing status at the time of initial discovery. Fixes: QTBUG-140825 Pick-to: 6.10 6.8 Change-Id: Ifd9ca57fe837522be01555984637cea65094900c Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* nfc: fix typo in configure summaryIlya Katsnelson2025-10-081-1/+1
| | | | | | Pick-to: 6.10 6.8 Change-Id: Ie57aedc8e3fc03733207316779e26748f168636c Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* BlueZ: avoid registering the same UUID twiceIvan Solovev2025-10-081-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Certain applications, like the btchat example, need to act as both a server and a client, using the same service-UUID. In the server role, they need to advertise the service. To achieve that, QBluetoothServiceInfo BlueZ implementation is registering a profile for the UUID. In the client role, the application needs to connect to a service with the same service-UUID, as advertised by the server. In order to do it, the QBluetoothSocketPrivateBluezDBus::connectToServiceHelper() method was trying to register another profile for the same service-UUID. Starting from some BlueZ version, this is causing an error: Client profile registration failed: "UUID already registered" However, reading the BlueZ docs, I noticed that the RegisterProfile() method has a "Service" option, whose description tells: string Service: The primary service class UUID (if different from the actual profile UUID). This option was already used in the code, but it was a no-op, because it had the same service-UUID, as the one that we were trying to register. This patch tries to register a client profile with a random UUID, but pass the correct UUID in the "Service" option (as before). My tests show that this approach works. With this patch I was able to start two btchat applications in my Ubuntu VM, and use one of them as a server (with a macOS client), and the other one - as a client connected to an Android server. Task-number: QTBUG-123197 Pick-to: 6.10 6.8 6.5 Change-Id: I71bc231d49929ad54498e9a391d4668e51e6bc3b Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Expect user-defined QT_NO_INT128 in removed_api.cppMarc Mutz2025-09-091-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | We currently don't support building Qt with GCC and -ansi (or -std=c++NN as opposed to -std=gnu++NN), because in that mode, the language still recognizes __int128_t, but the C++ standard library does not, leading to bloopers such as std::is_integral_v<__int128_t> == false or std::is_signed_v<__int128_t> == false, or simply std::numerical_limits<__int128_t> not being properly specialized. But we do have QT_NO_INT128, which, when defined, disables all the Qt extended integer support. A user requested to allow compiling with -ansi again, to which I responded that they should define QT_NO_INT128 then, too, but, of course, the unconditional #define in bluetooth/removed_api.cpp would cause a redefinition warning. So fix the code to use a conditional #define. Amends 5d90296f312f72ffa6a5322df7b565c3e5521684. Pick-to: 6.10 6.9 6.8 Task-number: QTBUG-139280 Change-Id: I0e453270bea883e995b0cb058bf15111b6f3adc8 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Doc: Fix incorrect usage of \generatelistTopi Reinio2025-08-061-1/+1
| | | | | | | | | | | | | | | | | | | | | The \generatelist command takes an optional argument that affect how the members are listed, for example, `classesbymodule` which creates an annotated list of the classes in a named C++ module. `groupsbymodule` is not recognized or documented. QDoc falls back to generating a list of all members of a group in this case. While the end result is correct, this relies on an undocumented feature that is likely to change and break. Replace these instances with an explicit \annotatedlist command that produces the same output. Pick-to: 6.10 Task-number: QTBUG-138901 Change-Id: Ia1122395191d3cad75c7fa6058f52122d3045da4 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Bluetooth: add missing namespace macrosTim Blechmann2025-07-212-8/+13
| | | | | | | | | When buiding namespaced Qt, we need to hide all qt classes inside qt's namespace. Pick-to: 6.10 Change-Id: I06ba954772384c9d45c0c20050561338af9c4cc8 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Remove year from Qt Copyright in REUSE.tomlLucie Gérard2025-07-142-2/+2
| | | | | Change-Id: I2c514b2f839a480d3bc2006f8698c753b11ca8cb Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Doc: Add textual descriptions for QtBluetooth documentation imagesDheerendra Purohit2025-07-041-1/+1
| | | | | | | | | | Added textual descriptions to images in the QtBluetooth documentation to ensure QDoc generates alt text. Pick-to: 6.10 6.9 Fixes: QTBUG-136156 Change-Id: I94ffbb6cb713ac3141f229c9c18e9bc2bd94185c Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Move Unity build exclusions to the correct locationFriedemann Kleint2025-06-181-3/+2
| | | | | | | | | Amends c0957ca534130076d0152b52397c9e42595fa291. Pick-to: 6.10 6.9 Task-number: QTBUG-109394 Change-Id: I118b037f7a6d0ffd2b01d34145f18327d403eecc Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Fix Unity build on WindowsFriedemann Kleint2025-06-181-0/+3
| | | | | | | | | Exclude WinRT sources. Pick-to: 6.10 6.9 Task-number: QTBUG-109394 Change-Id: I94c84744dc5cb37a9079773bee126dce06dba58b Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Report error and targetLost if system call failsJan Moeller2025-06-101-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | The call to getMaxTransceiveLength() and isConnected() might fail if the card was lost in the meantime. Especially Samsung smartphones seem to not communicate the loss right away. Consequently a Java exception is thrown: java.lang.SecurityException: Permission Denial: Tag ( ID: 08 B1 F8 BA ) is out of date at android.nfc.Tag.getTagService(Tag.java:382) at android.nfc.tech.BasicTagTechnology.getMaxTransceiveLengthInternal(BasicTagTechnology.java:138) at android.nfc.tech.IsoDep.getMaxTransceiveLength(IsoDep.java:183) Permission Denial: Tag ( ID: 08 B1 F8 BA ) is out of date at android.nfc.Tag.getTagService(Tag.java:382) at android.nfc.tech.BasicTagTechnology.isConnected(BasicTagTechnology.java:63) at android.nfc.tech.IsoDep.isConnected(IsoDep.java:40) If this occurs, it seems safe to assume that the card is gone and the corresponding error and targetLost should be reported. Fixes: QTBUG-136506 Pick-to: 6.10 6.9 Change-Id: Ie6432aa9a1e4136f96463311312a1a065484111e Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Android: Increase NFC transceive timeoutLars Schmertmann2025-06-081-1/+1
| | | | | | | | | | | | | | | | | With Qt 6 a NFC transceive timeout of 2000ms was introduced with the note, that "2000ms should be enough for most applications.". See d15693d4ea2e06216f55facd504273c990b3814b for details. In our application we noted that this is not enough for some cryptographic operations especially when a password is checked. In case of a wrong password some cards slow down the speed to make brute force attacks more difficult. On July 2, 2024, we released a new version for Android, where we increased the timeout to 3000ms with a Qt patch. Since this we did not note any problems so it is time to change this in the official Qt code too. Pick-to: 6.9 6.10 Change-Id: I0f0d977081cca01dcd9d0e54814fa92046107505 Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Normalize signal/slot signatures 2025Marc Mutz2025-06-041-4/+4
| | | | | | | | | | | This is the result of running util/normalize on the code base. The following manual edits were needed: (none) Pick-to: 6.10 6.9 6.8 6.5 Change-Id: Ifc9a85bbe2d7fd77312e380b5e495e545b51f3dd Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* CMake: Add PURL and CPE info to 3rd party attribution filesAlexandru Croitor2025-06-041-0/+1
| | | | | | | | | | | [ChangeLog][Third-Party Code] Added PURL and CPE information to the attribution files of 3rd party sources. Pick-to: 6.5 6.8 6.9 6.10 Fixes: QTBUG-137186 Task-number: QTBUG-129602 Change-Id: Iba0a8fe8fbd3c265504468c3816d66e63e01a8ea Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Document iOS BLE device discovery cache behaviorJuha Vuolle2025-06-041-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On iOS the BLE device discovery results seem to be limited to just actively advertising devices. QBluetoothDeviceDiscoveryAgent uses scanForPeripheralsWithServices API (with nil services), but this API only returns actively advertising devices. CoreBluetooth does provide an additional API for querying the already connected devices (retrieveConnectedPeripheralsWithServices). However this API only returns peripherals that are connected to the current central manager instance, making it unfeasible to use in a general purpose bluetooth discovery (which has its own central manager instance). The original bug report mentions iOS 18 but it's hard to confirm whether or not something has changed in that iOS version. The CoreBluetooth documentation hasn't changed and I couldn't find relevant entries in change logs. In summary it would seem that on iOS we can only return BLE devices that are advertising. It is therefore advisable to store the device UUID when it is first discovered; with this UUID it's then possible later quickly connect to the device (advertising or not). If the use case allows it, this can result in a better user experience too as the discovery phase can be omitted. Note: this issue was reproduced with few different smart watches. These watches force a pairing when services and characteristics are read, and after that they always automatically connect to the phone. Task-number: QTBUG-136692 Pick-to: 6.10 6.9 6.8 6.5 Change-Id: If9554a60299734da05461c3009cbd543b0dded88 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Doc: Enable automatic linking to sources on code.qt.ioTopi Reinio2025-05-272-0/+6
| | | | | | | | | | | | Since 6.10, QDoc is capable of generating links to the declaration in the source code for each documented C++ API entity in their `Detailed description`. Add the required configuration to enable this feature for modules in qtconnectivity. Change-Id: I033eab3a15047ab8c8c1e26763e3e573f0a7a84a Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* QLowEnergyControllerPrivateAndroid: use jsize when allocating buffersIvan Solovev2025-05-231-10/+15
| | | | | | | | | | | | | | | | | | | QByteArray uses qsizetype to represent its length, which is 64-bit on most of the supported platforms. JNI interface, however, uses jsize (which is same as jint - 32-bit) to represent its dynamically allocated buffers. This commit makes sure that we avoid signed integer overflows when allocating Java buffers using JNI, by properly truncating qsizetype to jsize. Note that the pre-existing behavior shouldn't be a problem in practice, as it's impossible to have 2GB characteristic or descriptor value. Pick-to: 6.9 6.8 6.5 Change-Id: I4e8ed56b3d3cafe81302d150aed048694c3f036d Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* QBluetoothSocketPrivateWinRT: remove unused variablesIvan Solovev2025-05-232-8/+0
| | | | | | | | | | | | | | | | | | | | The m_pendingData variable was simply accumulating the incoming data, but nothing was ever read from it. The m_readMutex variable was supposed to guard access to m_pendingData. Consequently, it was only used in one place when the data was added to m_pendingData. It was also guarding the access to the rxBuffer, but reading from the buffer is not protected by the mutex. Both variables were added in 8a0d14f4933bcd933e1258731472479ec33ade6a that introduced the Windows socket backend, and they were meaningless even back then. It looks like a leftover from various design choices, because the helper SocketWorker class has similar variables which are actually used. Pick-to: 6.9 6.8 6.5 Change-Id: I9fd5711f4e86929778b2a77bfa526b1390c8255a Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Mark qprivatelinearbuffer_p.h as security-criticalIvan Solovev2025-05-231-0/+1
| | | | | | | | | | | | The header contains an implementation of a private buffer that dynamically allocates and deallocates memory. It is used in all QBluetoothSocket backend implementations to store the received (and sometimes buffer the to-be-written) data. Task-number: QTBUG-135467 Pick-to: 6.9 6.8 Change-Id: Iaba7fb885025b536dbf62d6fb57677b6fd677726 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* QLeAdvertiserBluez::handleCommandCompleted(): check data sizeIvan Solovev2025-05-221-1/+4
| | | | | | | | | | | | | When reading the reply for the OcfLeReadTxPowerLevel command, check that the data is not empty before accessing the first byte. In practice the reply should always contain this byte, because this command tries to read the power level from the local adapter, not from some remote untrusted device. Pick-to: 6.9 6.8 6.5 Change-Id: Iaa504f00a260b438e323e4e0f81ab84a31cd85b5 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Mark qleadvertiser_bluez.cpp as security-significantIvan Solovev2025-05-221-0/+1
| | | | | | | | | | | | | | | | | The QLeAdvertiserBluez::handleCommandCompleted() method parses the answers to the commands that we send. The answers are received from the HciManager, which is considered to be security-critical. However, the commands are only related to setting up the local advertising. So, they are processed by the kernel part of the Bluetooth stack and shouldn't have any data from remote devices. As a result, we can trust that the data in the replies conforms to the HCI protocol. Task-number: QTBUG-135467 Pick-to: 6.9 6.8 Change-Id: Iad4978ef06286df102ccc0e563d4adf5d23b5bc6 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* QBluetoothSocketPrivateAndroid::writeData(): return correct number of bytes ↵Ivan Solovev2025-05-221-5/+7
| | | | | | | | | | | | | | | | | written The Java APIs take size as a qint32. The code was doing the conversion, but the return value and the bytesWritten() signal were still using the unmodified qint64 value. This could provide incorrect results if the users try to write more than INT_MAX bytes. Amends 52142177d765544b66a564c7e0fe235bc9a28f52 that introduced the Android backend. Pick-to: 6.9 6.8 6.5 Change-Id: Id02c93fb794cdc3b72298e2b83d9fe300f9365e8 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Fix size inconsistencies in QBluetoothSocketPrivateDarwin::readChannelData()Ivan Solovev2025-05-221-2/+7
| | | | | | | | | | | | | | | | | | | The function takes the size as std::size_t, but later casts it to int in the rxBuffer.reserve() call. However, later on it uses unmodified size to copy the data into the allocated space. This can lead to write past the end of the buffer if the input data size exceeds INT_MAX. However, I do not think that it's possible in practice, because the data is sent over bluetooth in chunks of MTU size, where the MTU cannot exceed 512 bytes. Amends c1286c3a344593c79feced5c782ff85bca80bfff that added the case in the reserve() call. Pick-to: 6.9 6.8 6.5 Change-Id: I7fe3f19f343f5b80bb939c5ef8c6c1bb1c0068fc Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Fix size inconsistencies in QBluetoothSocketPrivateDarwin::writeData()Ivan Solovev2025-05-221-3/+5
| | | | | | | | | | | | | | | | | | | | The reserve() call truncated the passed qint64 to int, but later std::copy() was passing the unmodified qint64 value to determine the end of the data to copy. That could lead to writing past the end of the allocated buffer if the user tried to write more than INT_MAX bytes to the socket. Fix by introducing a temporary variable that truncates the qint64 value to int, and use it consistently (and also as a return value). Not using qsizetype, because all other code here truncates to int. Changing to qsizetype should be done consistently in a separate commit. Amends c1286c3a344593c79feced5c782ff85bca80bfff. Pick-to: 6.9 6.8 6.5 Change-Id: I38a6dee1707b124d662b815938f33a39e1badb00 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* QBluetoothServiceInfo: extend the QT_NO_DEBUG_STREAM guardIvan Solovev2025-05-221-2/+2
| | | | | | | | | | | The dumpAttributeVariant() static function also uses QDebug, so should be guarded by this #ifndef as well. Amends e2e01feeaa124f3d1557278538a8f8cc7ae60216. Pick-to: 6.9 6.8 6.5 Change-Id: I85f7baf19f60656a63d83f023181b3bd2f4440ff Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Mark qbluetoothservicediscoveryagent_bluez.cpp as security-criticalIvan Solovev2025-05-221-0/+1
| | | | | | | | | | | | | | | | The QBluetoothServiceDiscoveryAgentPrivate::runExternalSdpScan() method uses QProcess to execute an external binary (sdpscanner). The binary itself is trusted, but we need to make sure that the path to the binary is correct -> security-critical. There are also methods in this file that parse the XML data received from sdpscanner, but that data should be considered trusted (because the sdpscanner tool is a part of Qt). Task-number: QTBUG-135467 Pick-to: 6.9 6.8 Change-Id: Ia2ec436ad653c902e138813bb288c7a92e608d86 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Mark qbluetoothservicediscoveryagent_winrt.cpp as security-criticalIvan Solovev2025-05-211-0/+1
| | | | | | | | | | | | | The QWinRTBluetoothServiceDiscoveryWorker::processServiceSearchResult() method parses the result of GetSdpRawAttributesAsync() call. This call returns raw data buffers that should be parsed according to a specific protocol. Task-number: QTBUG-135467 Pick-to: 6.9 6.8 Change-Id: I9a15482f56ecd95d8fcc5be51f3f03261d9156ef Reviewed-by: Juha Vuolle <juha.vuolle@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Mark lecmaccalculator.cpp as security-criticalIvan Solovev2025-05-211-0/+1
| | | | | | | | | | The code in this file uses Linux Crypto API to calculate or verify CMAC for the signed write commands used in the BlueZ kernel backend. Task-number: QTBUG-135467 Pick-to: 6.9 6.8 Change-Id: I6b3e24e1605e5d92cf5463e152b33773626d2f1e Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* HciManager::handleHciAclPacket(): swap the order of the checksIvan Solovev2025-05-211-2/+2
| | | | | | | | | Check size before dereferencing the data. That way, we guarantee that the byte does not contain garbage. Pick-to: 6.9 6.8 6.5 Change-Id: Id90e66cf9eafb24206490ffb080ae56ff7d25d42 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* HciManager::handleLeMetaEvent(): check size before accessing the dataIvan Solovev2025-05-212-3/+22
| | | | | | | | | | | | | | | | | | The function was only taking a pointer to the data buffer and accesing it without actually making sure that it has enough meaningful bytes. Pass the actual buffer size as a second parameter to the function. Print a warning and exit early if there is not enough bytes to parse the data. As in other commits, this cannot be considered a security issue, because the provided buffer is pre-allocated on the stack, and it has enough bytes to avoid reading past the end of the buffer. In worst case we could get garbage data from the buffer. Pick-to: 6.9 6.8 6.5 Change-Id: I67cd40e4644beac19ccf2a5fd531469ae951a49e Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* HciManager::handleHciEventPacket(): check size before accessing the dataIvan Solovev2025-05-201-3/+12
| | | | | | | | | | | | | | | | | | | The code was unconditionally reinterpter_cast'ing the data to certain structs without verifying that the read size is large enough. The EVT_CMD_COMPLETE case had a Q_ASSERT(), but prefer a proper if() check instead. This cannot be considered a security issue, because the code is accessing a buffer that was previously allocated on a stack. The buffer size is equal to HCI_MAX_EVENT_SIZE, which is large enough to make sure that the code does not read past the end of the buffer. We could only get garbage if we actually read less bytes than expected. The new code generates a warning and returns early in such case. Pick-to: 6.9 6.8 6.5 Change-Id: I7d67b2ed0a69753cda95cf7ba827accc132ac593 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* HciManagerhandleHciEventPacket(): call sizeof() only onceIvan Solovev2025-05-201-4/+6
| | | | | | | | | | The code was calling sizeof(*event) too many times. Clean it up by calculating the size as a constexpr and reusing it in all other places. Pick-to: 6.9 6.8 6.5 Change-Id: Ief2634d2606ec60a865b4f8e65cbe41a4442e606 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* HciManager::_q_readNotify(): return early when no data is readIvan Solovev2025-05-201-0/+5
| | | | | | | | | | | | | | | | | | | | The code only handled read result < 0 for an error condition, but theoretically ::read() could also return 0. That is very unlikely to happen in practice, because q_readNotify() is called when QSocketNotifier reports that some data is available. This also cannot be considered a security issue on its own, because in this case we'd read garbage from the buffer[0] that was previously allocated on the stack, and simply end up in the `default:` case of the code. If the garbage data is equal to HCI_EVENT_PKT or HCI_ACL_PKT, then the relevant methods should make sure to sanitize the input. However, let's handle the size == 0 case explicitly and return early in such case. Pick-to: 6.9 6.8 6.5 Change-Id: Ic4faedebf50a6d9b9b12d1251a91b4317fd34946 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Mark bluez/hcimanager.cpp as security-criticalIvan Solovev2025-05-201-0/+1
| | | | | | | | | | | | | | | | | The handleHciEventPacket(), handleHciAclPacket(), and handleLeMetaEvent() methods parse the data that is received as HCI events. The HCI and L2CAP protocols are implemented at the Linux kernel level, so we can trust that the protocol-specific parts of the data are valid. However, we cannot be sure that the BT payload is anyhow verified, so let's still play safe and consider these parsers security-critical. Task-number: QTBUG-135467 Pick-to: 6.9 6.8 Change-Id: I3c7e67ca7f9314ee6883829dfd9ed05fd3d9967d Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Mark blurz/bluez5_helper.cpp as security-criticalIvan Solovev2025-05-201-0/+1
| | | | | | | | | | | | | | | The bluetoothdVersion() method executes remote binaries via QProcess, so consider it as security-critical. For now, the binary names are taken from /proc/<pid>/exe or /proc/<pid>/cmdline, and the <pid> value is taken from the D-Bus APIs. Both the D-Bus and /proc can be considered as trusted sources, so the current code is fine. Task-number: QTBUG-135467 Pick-to: 6.9 6.8 Change-Id: Ia8c1f47152df25ae527ee6e11d26cf15f074a21b Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Mark bluez/bluetoothmanagement.cpp as security-significantIvan Solovev2025-05-201-0/+1
| | | | | | | | | | | | | | The BluetoothManagement::_q_readNotifier() method parses the data from a bluetooth socket, but this data is received from the Linux kernel, so can be considered trusted. Explicitly mark the file as significant, to highlight that it was reviewed. Task-number: QTBUG-135467 Pick-to: 6.9 6.8 Change-Id: Ia45fbc3ee9350ea642bf62901e0df755e48484f7 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Mark android/devicediscoverybroadcastreceiver.cpp as security-criticalIvan Solovev2025-05-201-0/+1
| | | | | | | | | | | | | | | The DeviceDiscoveryBroadcastReceiver::retrieveDeviceInfo() method parses the incoming scan data. The data is received from the underlying Android OS APIs. However, I do not consider it to be trusted, because we use the ScanRecord.getBytes() Android API, which seems to return the raw data, as received from the BT device. Task-number: QTBUG-135467 Pick-to: 6.9 6.8 Change-Id: I01f176f4ab41da9dbf0b38793ad001c2f4b79168 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Fix memory leak in QNdefNfcSmartPosterRecordIvan Solovev2025-05-062-9/+21
| | | | | | | | | | | | | | | | The pointers in QNdefNfcSmartPosterRecordPrivate were only deleted in the QNdefNfcSmartPosterRecord::cleanup() method, but it was not called at destruction. Rewrite the code to make sure that the destructor of Private always cleans up the memory. A more modern approach would be to use std::optional, but I leave it for a follow-up patch, because I want this change to be picked down to 5.15. Fixes: QTBUG-136576 Pick-to: 6.9 6.8 6.5 5.15 Change-Id: I5ca3ae24d638e4b28bc4f5f92604ec0c1564b489 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* iOS: report an error when trying to write more than one NDEF messageIvan Solovev2025-05-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The pre-existing code was returning a valid request id, but never reported requestCompleted() or error(). As a result, there was no way to figure out that nothing has been written. We have three options here: 1. return an invalid request id; 2. remove an early return and actually write the first message from the list; 3. report an error. Options 1 does not match with what the other methods of the iOS backend do. Option 2 is a behavior change, so might be unexpected. That's why this patch implements option 3. Amends 8fd383214b710a610edd18e9db5b029dbe030edc. Pick-to: 6.9 6.8 6.5 Change-Id: Ib588a8b0183f87b23829b9b31a4c74b7ba5c290b Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Docs: fix typos in QNearFieldTarget documentationIvan Solovev2025-05-061-2/+2
| | | | | | | | | Amends 29ba8297443cf76d4f647bde329d62c2a567c709 which is the beginning of the public history of the module. Pick-to: 6.9 6.8 6.5 5.15 Change-Id: I9e61c4b0c33221896b25d9d1b4eead1c07a72e9a Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* QNdefNfcSmartPosterRecord: optimize setTitles() and setIcons()Ivan Solovev2025-05-061-10/+2
| | | | | | | | | | | Do not use QList::clear() + a loop of QList::append(), simply use operator=() instead. Amends bbb3268d26f91e7c99cced11fa94af810a07c42a. Pick-to: 6.9 6.8 6.5 Change-Id: I407a36666efb7310be09adb3592c7d4360fcd332 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* QPcscCard::onReadNdefMessagesRequest: remove unused variableIvan Solovev2025-05-061-2/+0
| | | | | | | | | | | The messages variable was never used. Amends 44d474a0fc1a2b6352c5cb83d389aa129e9f09c4 which introduced this backend. Pick-to: 6.9 6.8 6.5 Change-Id: I5c72d3b0a316c28f48a3a18f6f1da1f0a14c6a8b Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Mark qndefmessage.cpp as security-criticalIvan Solovev2025-05-061-0/+1
| | | | | | | | | | | The QNdefMessage::fromByteArray() method parses a provided QByteArray according to the NDEF message spec. The data can be provided directly from the device. Task-number: QTBUG-135466 Pick-to: 6.9 6.8 Change-Id: I0aff32e2ee8581eaf06184fed57a15440cd50a42 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Mark qapduutils.cpp as security-criticalIvan Solovev2025-05-061-0/+1
| | | | | | | | | | | | | The file contains code that constructs QResponseApdu from a QByteArray that is received directly from an NFC device. The related header is not markes as security-critical, because the inline methods are trivial. Task-number: QTBUG-135466 Pick-to: 6.9 6.8 Change-Id: I48c00566d82afa6cf88c9780e20e09960a4b0017 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* PCSC: mark security-critical codeIvan Solovev2025-05-062-0/+2
| | | | | | | | | | | | | | The QPcscCard::sendCommand() method in qpcsccard.cpp receives a response from a device/tag and needs to make sure that it fits into the preallocated buffer. Later, the response is actually parsed according to NFC Type 4 Tag spec in qnfctagtype4ndeffsm.cpp by various QNfcTagType4NdefFsm::handle*Response() methods. Task-number: QTBUG-135466 Pick-to: 6.9 6.8 Change-Id: I4359ae2ccb84d42d46ab0f3631469adcf90c2f5a Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Add NFC tag UID support with neardAndreas Hartmetz2025-04-172-3/+7
| | | | | | | | | | | | | | A UID patch for neard has been floating around since 2021 - it was finally merged in August 2023 and it is included in neard v0.19! neard commit message: "Implement readout of tag UID via DBus interface" [ChangeLog][QtNFC][Linux] The neard backend on Linux now returns the correct UID from QNearFieldTarget::uid() with neard v0.19 or newer. It previously returned an empty QByteArray. Change-Id: Icffbbca31f9d5a3d213f32926cf4c302269066c2 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Document that macOS bluetooth runmode association is fixed in macOS 15Juha Vuolle2025-03-311-2/+2
| | | | | | | Pick-to: 6.9 6.8 6.5 Fixes: QTBUG-99410 Change-Id: I8565012b3592f2e7eb36c4cdb9a05e7043bc81d4 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* NFC: use qdbusxml2cpp namespace property for the NearD backendIvan Solovev2025-03-297-5/+14
| | | | | | | | | | The NearD backend uses the same objectmanager and properties D-Bus interfaces, like some other Qt modules. Wrap the generated classes into a custom namespace to avoid bugs like QTBUG-133553. Task-number: QTBUG-134305 Change-Id: Ice9c6c78ebb0f02c03063e8d5bf531dc5cb598c3 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-17 01:34:07 +0000