[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

bluez / CVE-2020-0556

I am a bit puzzled by the following comment from dla-needed.txtfor bluez:

  NOTE: 20200503: Looking at the four patches included in the stretch update it looks like it
  NOTE: 20200503: can be applied as is. What will fail is hog.c but that file do not seem to
  NOTE: 20200503: need an update. (Ola)

As far as i can tell, the first commit fixes the security flaw, and the
only file it touches in hog.c. If true that hog.c does not need an
update, does this means the package is not vulnerable? I suspect not.

- fix vulnerability.

- make security posture configurable to support newer devices.

- fix potential regressions.

The patch patches the hog_accept function, which is a callback set as
part of the hog_profile:

static struct btd_profile hog_profile = {
        .name           = "input-hog",
        .remote_uuid    = HOG_UUID,
        .device_probe   = hog_probe,
        .device_remove  = hog_remove,
        .accept         = hog_accept,
        .disconnect     = hog_disconnect,
        .auto_connect   = true,

Unfortunately the version in Jessie doesn't even have an accept entry:

static struct btd_profile hog_profile = {
        .name           = "input-hog",
        .remote_uuid    = HOG_UUID,
        .device_probe   = hog_probe,
        .device_remove  = hog_remove,

Looking at commit
it looks like maybe we should be patching the attio_connected_cb()
function instead. But this function doesn't appear to have any way to
return an error indicating it failed, which seems to be required by the
patch. It might be sufficient just to ignore the error and return
without immediately if device is not bonded. Not sure how much I can
trust this however.

My gut feeling to fix this we should backport version 5.43-2+deb9u2 from
stretch to Jessie. Yes, this might break stuff, but I suspect just the
very basic idea of this security fix - rejecting unbonded connections -
could break stuff also.
Brian May <brian@linuxpenguins.xyz>

Reply to: