Debian Patches

Status for bluez/5.87-4

Patch Description Author Forwarded Bugs Origin Last update
work-around-Logitech-diNovo-Edge-keyboard-firmware-i.patch work around Logitech diNovo Edge keyboard firmware issue Nobuhiro Iwamatsu <iwamatsu@debian.org> no debian 2024-04-10
obex-Use-GLib-helper-function-to-manipulate-paths.patch [PATCH 1/5] obex: Use GLib helper function to manipulate paths
Instead of trying to do it by hand. This also makes sure that
relative paths aren't used by the agent.		 Bastien Nocera <hadess@hadess.net> no 2013-11-09
agent-Assert-possible-infinite-loop.patch [PATCH 4/5] agent: Assert possible infinite loop Bastien Nocera <hadess@hadess.net> no 2013-12-09
org.bluez.obex.service.in.patch Don't link to symlinked systemd user service Nobuhiro Iwamatsu <iwamatsu@debian.org> not-needed debian 2017-03-17
main.conf-Add-more-details-Closes-904212.patch main.conf: Add more datails (Closes: #904212) Nobuhiro Iwamatsu <iwamatsu@nigauri.org> no 2018-07-29
Add-HCI_TO_STR-macro-for-FIRMWARE_DIR.patch Add HCI_TO_STR macro for FIRMWARE_DIR
If the macro specified with -D is string, it cannot be expanded and an error
will occur. This adds HCI_TO_STR macro that expands as string and wraps it
when expanding FIRMWARE_DIR.

```
tools/hciattach_bcm43xx.c: In function ‘bcm43xx_init’:
<command-line>: error: expected expression before ‘/’ token
tools/hciattach_bcm43xx.c:352:34: note: in expansion of macro ‘FIRMWARE_DIR’
352 | if (bcm43xx_locate_patch(FIRMWARE_DIR, chip_name, fw_path)) {
| ^~~~~~~~~~~~
```		 Nobuhiro Iwamatsu <iwamatsu@debian.org> no 2023-08-06
0002-hostname-handle-chassis-type-handset.patch [PATCH 2/4] hostname: handle chassis type handset
This also corrects the link to the definition of the base class of
device field.		 Simon Fels <simon.fels@canonical.com> no 2015-10-12
lp1759836.patch hid2hci: Fix udev rules for linux-4.14+
Since commit 1455cf8dbfd0 ("driver core: emit uevents when
device is bound to a driver") the kernel started emitting
"bind" and "unbind" uevents which confuse the hid2hci
udev rules.

The symptoms on an affected machine (Dell E5400 in my case)
include bluetooth devices not appearing and udev hogging
the cpu as it's busy processing a constant stream of these
"bind"+"unbind" uevents.

Change the udev rules not do anything except for "add" and
"change" events. This seems to cure my machine at least.

v2: Don't mess up "change" (Zbyszek)
Fix up the commit message a bit		 Ville Syrjälä <ville.syrjala@linux.intel.com> no debian upstream, https://lore.kernel.org/patchwork/patch/1021109/ 2018-12-04
raspi-bcm43xx-load-firmware.patch Patches for loading the bcm43xx firmware

Disables setting the UART interface speed *before* loading the firmware
(a later call sets the speed of the interface as requested).		 Simon Long <simon@raspberrypi.org> yes 2022-12-06
raspi-bcm43xx-3wire.patch Patches to add BCM43xx 3-wire variant

This patch adds the bcm43xx-3wire variant to the hciattach tool; this is
for use when the mini-UART (which lacks flow-control) is used instead of the
PL011 UART to drive the bluetooth module		 Simon Long <simon@raspberrypi.org> yes 2017-04-05
ubuntu_error_restart.patch restart the service on errors Sebastien Bacher <seb128@ubuntu.com> no 2020-04-03
CVE-2026-75032-part1.patch avrcp: Fix Out-of-Bounds Read in AVRCP GetFolderItems parsing
If the "Displayable Name Length" is much longer than the size of the PDU
packet we receive, then we might try to memcpy() past the end of the PDU
packet.

Be careful about clamping the name copying to the smallest of:
- length specified in the PDU
- left-over packet after the length field
- size of the string we'll copy it into

(cherry picked from commit bd8989620ed6e80755f06cfdb18f5b4a3913493c)		 Bastien Nocera <hadess@hadess.net> no 2026-08-14
CVE-2026-75032-part2.patch avrcp: Fix media/folder name not being set
*namelen was used before being set.

(cherry picked from commit 58088149872d014684a582fdb7ad01a5180c9bc5)		 Bastien Nocera <hadess@hadess.net> no 2026-08-17
CVE-2026-80185.patch sdp-xml: Fix crash caused by type confusion when parsing crafted SDP XML

When element_end() processes </attribute>, it frees ctx_data->stack_head
and clears the stack even if parsing is still nested inside a parent
container.

If a crafted ServiceRecord places a nested <attribute> inside <sequence>,
a later sibling scalar element such as <uint64> can become the new stack
head. When the closing </sequence> is then processed, compute_seq_size()
is reached without first validating that the current node is actually
a sequence.

sdp_data_t.val stores both scalar members such as uint64 and the
dataseq pointer in the same union. As a result, attacker-controlled
scalar data can be reinterpreted as a linked-list pointer and traversed
until bluetoothd crashes.

See https://github.com/bluez/bluez/security/advisories/GHSA-7mmr-gwqx-vc34		 Bastien Nocera <hadess@hadess.net> no 2026-08-12
CVE-2026-80186.patch eir: Fix stack buffer overflow when parsing the remote name
name2utf8() copies len bytes into a HCI_MAX_NAME_LENGTH + 2, so 250,
byte stack buffer without clamping len first.

eir_parse() only rejects a field once it runs past the end of the EIR
data, and that data is up to 255 bytes, so field_len can be 254 and the
data_len passed to name2utf8() can reach 253. strncpy() then writes 253
bytes into the 250 byte buffer and leaves it unterminated, so the
following g_strstrip() and g_strdup() also read past the end.

The EIR data comes from a remote device, either in an extended inquiry
response or in an advertising report, so the length is attacker
controlled.

Clamp len to HCI_MAX_NAME_LENGTH, which is what the local name is
limited to anyway, and what ad_replace_name() already clamps to.		 Luiz Augusto von Dentz <luiz.von.dentz@intel.com> no 2026-08-19
all-Fix-typo-in-AVRCP_ATTRIBUTE_ILEGAL.patch all: Fix typo in AVRCP_ATTRIBUTE_ILEGAL
It's "illegal" not "ilegal".

(cherry picked from commit 73ccf6d83e6a1c65bd4971c6e35da16520f7d74e)		 Bastien Nocera <hadess@hadess.net> no upstream, after 5.87 2026-08-27
CVE-2026-85218.patch avrcp: Fix out-of-bounds parsing of ListPlayerAttributes response
In profiles/audio/avrcp.c, avrcp_list_player_attributes_rsp() parsed the
response using hand-computed offsets into the operands buffer, without
accounting for the fact that operand_count spans the 7 byte AVRCP header
as well as the parameters:

- attrs is a 4 byte array which could be written out-of-bounds if a
length greater than 4 was declared in the first parameter byte.

- The attribute bytes were read with a bound derived from operand_count,
so a truncated response could be read past its end. As the receive
buffer is reused across packets, those stale bytes could be echoed
back to the peer in the following GetCurrentPlayerValue request.

- params_len was compared against count, which was only ever 0 at that
point, so the length of the PDU was in practice never validated.

Parse the response through a struct iovec using the util_iov_pull_*
helpers instead, so that the header and each subsequent field are bounds
checked as they are consumed and the remaining length is tracked for us.
This lets params_len be validated against the actual number of parameter
bytes received. The attribute count is still clamped to
AVRCP_ATTRIBUTE_LAST, which is what bounds the write into attrs.

(cherry picked from commit b21c216d580cf303681bfe9eab60a5414d8b6cc0)		 Bastien Nocera <hadess@hadess.net> no upstream, after 5.87 2026-09-01
avrcp-Fix-out-of-bounds-read-parsing-attribute-lists.patch avrcp: Fix out-of-bounds read parsing attribute lists
avrcp_parse_attribute_list() received only a pointer and an attribute
count, with no indication of how many bytes were actually available. For
each attribute it read an 8 byte header followed by a 16 bit length and
that many bytes of value, none of which was bounds checked.

The callers only validated the fixed portion of each entry:

if (be16_to_cpu(pdu->params_len) - 1 < count * 8)

which says nothing about the variable length values that follow, so a
response declaring a single attribute with a value length of 0xFFFF
would read far past the end of the receive buffer and pass the result to
media_player_set_metadata().

These are response callbacks, so they do not go through
handle_vendordep_pdu() and params_len had itself never been checked
against the number of bytes received. avrcp_get_element_attributes_rsp()
also cast the operands to an AVRCP header without checking that a full
header was present.

parse_media_element() had a related off-by-one, reading the attribute
count at operands[13 + namesize] when parse_media_name() only
guaranteed that 13 + namesize bytes were present.

Parse all of this through a struct iovec using the util_iov_pull_*
helpers so the remaining length is tracked as each field is consumed,
and validate params_len against the bytes actually received.

(cherry picked from commit f0ddbc7aaaf60f12871eacf05ad132e98e058a83)		 Luiz Augusto von Dentz <luiz.von.dentz@intel.com> no upstream, after 5.87 2026-09-01

All known versions for source package 'bluez'

Links