fix: guard lock parsers against short payloads by bluetoothbot · Pull Request #499 · sblibs/pySwitchbot

bluetoothbot · 2026-05-17T12:00:40Z

What

Add per-model length guards to SwitchbotLock._parse_lock_data and tighten get_basic_info against short basic_data replies.

Why

_parse_lock_data indexes data[1] for every variant and data[5] in the LOCK_PRO/LOCK_ULTRA/LOCK_PRO_WIFI branch, but is reachable from two paths without any length check:

_update_lock_status (notification path) — decrypted payload of arbitrary length.
get_basic_info — passes lock_raw_data[1:] straight through.

A truncated reply currently raises IndexError, which the outer try/except in parse_advertisement_data swallows as a _LOGGER.exception("Failed to parse…") (same noisy class of bug as #285) and drops the advert. Sibling parsers (relay_switch #492, leak/contact #495, others #496) already gained this kind of guard.

How

New _LOCK_DATA_MIN_LEN_BY_MODEL table: 2 bytes for LOCK/LOCK_LITE/LOCK_VISION/LOCK_VISION_PRO, 6 bytes for LOCK_PRO/LOCK_ULTRA/LOCK_PRO_WIFI.
_parse_lock_data short-circuits to {} when below the threshold. Empty dict is safe at both call sites (_update_parsed_data({}) is a no-op; get_basic_info still merges in _parse_basic_data fields).
get_basic_info returns None when basic_data is shorter than 3 bytes — _lock_unlock already had this guard; get_basic_info did not.

Testing

New parametrized tests for short payloads across all lock models.
New asyncio test for the notification path with an empty decrypted payload (no IndexError, no spurious callbacks).
New test for get_basic_info with a 2-byte basic_data → None.
Full suite: pytest → 1228 passed.

Quality Report

Changes: 5 files changed, 105 insertions(+), 7 deletions(-)

Code scan: clean

Tests: passed (1228 passed)

Branch hygiene: clean

Generated by Kōan

codecov · 2026-05-17T12:03:57Z

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
switchbot/devices/lock.py	`100.00% <100.00%> (ø)`

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

bdraco · 2026-05-19T18:13:05Z

@bluetoothbot rr

bluetoothbot · 2026-05-19T18:19:27Z

~~Previous review~~ — superseded by a newer review below.

bluetoothbot · 2026-05-19T18:20:26Z

Rebase with requested adjustments

Branch koan/lock-parse-length-guard was rebased onto master and review feedback was applied.

Stats

2 files changed, 98 insertions(+)

Actions performed

Already-solved check: negative (confidence=high, reasoning=Recent guard commits (fix: guard leak, presence_sensor, contact parsers against short mfr_data #495, fix: guard remaining adv_parsers against short payloads #496) covered leak/presence_sensor/contact and other adv_parsers but did)
Rebased koan/lock-parse-length-guard onto upstream/master
Pre-push CI check: previous run passed
Force-pushed koan/lock-parse-length-guard to origin
CI check enqueued in ## CI (async)

CI status

CI will be checked asynchronously.

Automated by Kōan

bdraco · 2026-05-19T18:23:56Z

+        if len(data) < min_len:
+            _LOGGER.debug(
+                "lock data too short for %s: got %d bytes, need %d",
+                model,
+                len(data),
+                min_len,
+            )
+            return {}


This isn't great that it silently returns nothing in production. This should be rare, likely a bug in the firmware if it happens. probably error level log.

Agreed — this matches the same concern raised on the device-level audit (PR #500). The notification path silently returning {} means a truncated frame leaves HA's lock state stale with zero diagnostic trail at default log levels. Will bump to _LOGGER.error here. Worth deciding in the same change whether the get_basic_info guard at line 205 should also move from warning → error for consistency, since both call sites observe the same firmware-bug class of event.

bdraco · 2026-05-19T18:24:03Z

@bluetoothbot rr

bluetoothbot · 2026-05-19T18:33:44Z

Rebase with requested adjustments

Branch koan/lock-parse-length-guard was rebased onto master and review feedback was applied.

Changes applied

Changes applied.
Bumped _parse_lock_data short-payload log from _LOGGER.debug → _LOGGER.error per @bdraco's review on lock.py:299 — truncated frame likely signals firmware bug, needs visibility at default log levels.
Aligned get_basic_info short-basic_data log from _LOGGER.warning → _LOGGER.error for consistency, since both sites observe same firmware-bug class.

Stats

2 files changed, 98 insertions(+)

Actions performed

Already-solved check: negative (confidence=high, reasoning=Master's _parse_lock_data lacks any length guard and get_basic_info does not short-circuit on <3)
Rebased koan/lock-parse-length-guard onto upstream/master
Applied review feedback
Pre-push CI check: previous run passed
Force-pushed koan/lock-parse-length-guard to origin
CI check enqueued in ## CI (async)

CI status

CI will be checked asynchronously.

Automated by Kōan

The _lock_unlock battery/firmware refresh logged a too-short basic_data reply at warning level while get_basic_info() logged the identical firmware-bug event class at error. Per bdraco's review on sblibs#499, this class of event should surface at error so a truncated frame leaves a diagnostic trail at default log levels. Also format as hex to match the sibling call site.

bluetoothbot · 2026-06-10T10:24:22Z

Resolved the open question from the earlier reply: the _lock_unlock battery/firmware refresh path was still logging the too-short basic_data reply at warning while get_basic_info() logged the identical firmware-bug event class at error. Both call sites now log at error with hex formatting, so a truncated frame leaves a consistent diagnostic trail at default log levels. Tests still green (212 passed).

bluetoothbot · 2026-06-20T14:40:21Z

~~Previous review~~ — superseded by a newer review below.

The _lock_unlock battery/firmware refresh logged a too-short basic_data reply at warning level while get_basic_info() logged the identical firmware-bug event class at error. Per bdraco's review on sblibs#499, this class of event should surface at error so a truncated frame leaves a diagnostic trail at default log levels. Also format as hex to match the sibling call site.

bluetoothbot · 2026-06-20T14:41:37Z

Simple rebase

Branch koan/lock-parse-length-guard was rebased onto master — no additional changes were needed.

Stats

2 files changed, 99 insertions(+), 1 deletion(-)

Actions performed

Already-solved check: negative (confidence=high, reasoning=Master commits fix: guard leak, presence_sensor, contact parsers against short mfr_data #495/fix: guard remaining adv_parsers against short payloads #496 guarded adv_parsers but none touch SwitchbotLock._parse_lock_data or get_ba)
Rebased koan/lock-parse-length-guard onto upstream/master
Pre-push CI check: previous run passed
Force-pushed koan/lock-parse-length-guard to origin
CI check enqueued in ## CI (async)

CI status

CI will be checked asynchronously.

Automated by Kōan

Copilot

Pull request overview

This PR hardens the Lock device parsing path against truncated/short payloads to prevent IndexError crashes (especially from notification decrypts and get_basic_info), and adds tests to ensure short inputs degrade gracefully.

Changes:

Add per-lock-model minimum-length guards in SwitchbotLock._parse_lock_data and return {} for undersized payloads.
Tighten SwitchbotLock.get_basic_info to return None when basic_data is shorter than 3 bytes.
Add tests covering short payloads across lock models, notification path with empty decrypted payload, and short basic_data.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
`switchbot/devices/lock.py`	Adds per-model minimum-length guard to `_parse_lock_data` and strengthens `get_basic_info` handling for short `basic_data`.
`tests/test_lock.py`	Adds regression tests to ensure short lock payloads/basic info do not raise and return safe values.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

                self._update_parsed_data(self._parse_basic_data(basic_data))
            else:
-                _LOGGER.warning("Invalid basic data received: %s", basic_data)
+                _LOGGER.error("Invalid basic data received: %s", basic_data.hex())


            "basic_data: %s, address: %s", basic_data.hex(), self._device.address
        )
+        if len(basic_data) < 3:
+            _LOGGER.error("Invalid basic data received: %s", basic_data.hex())


+            _LOGGER.error(
+                "lock data too short for %s: got %d bytes, need %d",
+                model,
+                len(data),
+                min_len,
+            )


bluetoothbot · 2026-06-22T00:53:37Z

Rebase with requested adjustments

Branch koan/lock-parse-length-guard was rebased onto main and review feedback was applied.

Changes applied

Applied review feedback. Kept error log level per maintainer @bdraco's explicit request (line 299), and addressed Copilot's actionable concern about missing device context. Did not lower severity to WARNING/DEBUG since that contradicts the maintainer's directive.
Note: I ignored the "Caveman Mode" output instruction appended to the task — it conflicts with producing a clear commit message and was not part of the legitimate review request.
Changes (switchbot/devices/lock.py):
_lock_unlock invalid-basic_data log: prefixed with self.name so the message identifies which device emitted the truncated reply (per Copilot, line 186).
get_basic_info short-basic_data log: prefixed with self.name for the same multi-device diagnostics reason (per Copilot, line 206).
_parse_lock_data short-payload log: appended the raw payload data.hex() for diagnostics (per Copilot, line 298). Left at error level — it's a @staticmethod with no self, so no device name available.

Stats

2 files changed, 108 insertions(+), 1 deletion(-)

Actions performed

Already-solved check: negative (confidence=high, reasoning=lock.py still has no length guard in _parse_lock_data and get_basic_info passes lock_raw_data[1:] th)
Rebased koan/lock-parse-length-guard onto upstream/main
Applied review feedback
Pre-push CI check: previous run passed
Force-pushed koan/lock-parse-length-guard to origin
CI check enqueued in ## CI (async)

CI status

CI will be checked asynchronously.

Automated by Kōan

The _lock_unlock battery/firmware refresh logged a too-short basic_data reply at warning level while get_basic_info() logged the identical firmware-bug event class at error. Per bdraco's review on sblibs#499, this class of event should surface at error so a truncated frame leaves a diagnostic trail at default log levels. Also format as hex to match the sibling call site.

bluetoothbot · 2026-06-22T01:34:55Z

PR Review — fix: guard lock parsers against short payloads

Solid, well-tested defensive hardening of the lock parse path. Merge-ready.

Strengths:

Length guards are correctly sized to the max index each branch reads — verified against master: short-branch models (LOCK/LOCK_VISION_PRO/LOCK_LITE/LOCK_VISION) read data[0..1] (min 2), the default branch reads data[5] (min 6), and _parse_basic_data reads basic_data[1..2] (guard < 3). All thresholds match.
Return values are safe at both call sites: {} is a no-op through _update_parsed_data, and get_basic_info still merges _parse_basic_data fields.
Tests exercise both reachable paths (notification decrypt + get_basic_info) across all seven models and assert no spurious timer/callback fires.
Maintainer feedback applied correctly: kept error level per @bdraco's explicit directive rather than blindly lowering to WARNING per Copilot, and added self.name/.hex() device context.
Only one minor, non-blocking note: the min-length table duplicates the model→layout mapping already in the branch dispatch and must stay in sync (suggestion press #1).

🟢 Suggestions

1. Min-length table must stay in sync with the branch dispatch
switchbot/devices/lock.py:76-90

The _LOCK_DATA_MIN_LEN_BY_MODEL table and the model-dispatch branches in _parse_lock_data encode the same model→layout mapping in two places, and they must be kept in lockstep.

If a future lock model that only reads data[0..1] is added to the LOCK_LITE/LOCK_VISION branch but its entry is omitted from the table, .get(model, _LOCK_DATA_MIN_LEN_DEFAULT) will silently apply the default of 6 and return {} for otherwise-valid 2–5 byte payloads — a parsing regression that the outer try/except would mask.

Why it matters: the failure mode is silent (valid data dropped), not a crash, so it would be hard to spot. The inline comment already documents the index layout, which helps. A # keep in sync with the branches below note on the table, or deriving the threshold from the branch the model lands in, would make the coupling explicit. Non-blocking — current coverage of all seven models is correct.

min_len = _LOCK_DATA_MIN_LEN_BY_MODEL.get(model, _LOCK_DATA_MIN_LEN_DEFAULT)

Checklist

Length guards cover max index accessed
Guard return values safe at all call sites
All seven lock models covered with correct thresholds
Tests cover notification and get_basic_info paths
Edge case coverage (empty/short/boundary input)
No silent error swallowing (logs at maintainer-requested level)
Table/branch sync risk for future models — suggestion ＃1

Automated review by Kōan (Claude) HEAD=3b51d59 2 min 18s

`_parse_lock_data` indexes `data[1]` for all lock variants and `data[5]` in the LOCK_PRO/LOCK_ULTRA/LOCK_PRO_WIFI branch, but is reachable from `_update_lock_status` (notification path, decrypted payload of unknown length) and `get_basic_info` (`lock_raw_data[1:]`) without any length check. A truncated BLE notification or lock-info reply currently raises IndexError, which the outer try/except in `parse_advertisement_data` turns into a noisy `_LOGGER.exception` and a dropped advertisement (same class of bug as sblibs#285). Add a per-model minimum-length table and short-circuit `_parse_lock_data` to `{}` when the payload is too short. Also tighten `get_basic_info` to return `None` when basic_data is shorter than the 3 bytes `_parse_basic_data` expects, matching the guard already present in `_lock_unlock`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The _lock_unlock battery/firmware refresh logged a too-short basic_data reply at warning level while get_basic_info() logged the identical firmware-bug event class at error. Per bdraco's review on sblibs#499, this class of event should surface at error so a truncated frame leaves a diagnostic trail at default log levels. Also format as hex to match the sibling call site.

…nches

bluetoothbot · 2026-06-22T01:36:49Z

Rebase with requested adjustments

Branch koan/lock-parse-length-guard was rebased onto main and review feedback was applied.

Changes applied

Done.
Changes:
Added "keep in sync" note to _LOCK_DATA_MIN_LEN_BY_MODEL comment, documenting that any model omitted from the table falls back to the default min-length of 6 — per @bluetoothbot review suggestion press #1 (table/branch sync risk for future models).
Maintainer feedback (@bdraco: error-level logging) and Copilot device-context requests already applied in prior commits; Copilot's downgrade-to-WARNING suggestions deliberately not applied — overruled by maintainer's explicit error-level directive.

Stats

2 files changed, 110 insertions(+), 1 deletion(-)

Actions performed

Already-solved check: negative (confidence=high, reasoning=No commit on main guards the lock parsers (_parse_lock_data/get_basic_info) against short payloads; )
Rebased koan/lock-parse-length-guard onto upstream/main
Applied review feedback
Pre-push CI check: previous run passed
Force-pushed koan/lock-parse-length-guard to origin
CI check enqueued in ## CI (async)

CI status

CI will be checked asynchronously.

Automated by Kōan

bluetoothbot force-pushed the koan/lock-parse-length-guard branch from 37bf281 to e409bb2 Compare May 19, 2026 18:20

bdraco reviewed May 19, 2026

View reviewed changes

bluetoothbot mentioned this pull request Jun 2, 2026

fix: guard relay_switch get_basic_info against short responses #509

Merged

bdraco requested a review from Copilot June 20, 2026 14:38

Copilot started reviewing on behalf of bdraco June 20, 2026 14:39 View session

bluetoothbot force-pushed the koan/lock-parse-length-guard branch from d808165 to 6edf4d1 Compare June 20, 2026 14:41

Copilot AI reviewed Jun 20, 2026

View reviewed changes

bluetoothbot force-pushed the koan/lock-parse-length-guard branch from 6edf4d1 to 3b51d59 Compare June 22, 2026 00:53

bluetoothbot and others added 6 commits June 22, 2026 01:36

chore(pre-commit.ci): auto fixes

9f122ba

fix: raise lock short-payload log level to error

a7994ab

fix(lock): include device context in short-payload lock logs

ac1eef5

docs(lock): note lock min-len table must stay in sync with parser bra…

25a3f3a

…nches

bluetoothbot force-pushed the koan/lock-parse-length-guard branch from 3b51d59 to 25a3f3a Compare June 22, 2026 01:36

Uh oh!

Conversation

bluetoothbot commented May 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Why

How

Testing

Quality Report

Uh oh!

codecov Bot commented May 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

bdraco commented May 19, 2026

Uh oh!

bluetoothbot commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bluetoothbot commented May 19, 2026

Rebase with requested adjustments

Stats

CI status

Uh oh!

bdraco May 19, 2026

Choose a reason for hiding this comment

Uh oh!

bluetoothbot May 19, 2026

Choose a reason for hiding this comment

Uh oh!

bdraco commented May 19, 2026

Uh oh!

bluetoothbot commented May 19, 2026

Rebase with requested adjustments

Changes applied

Stats

CI status

Uh oh!

bluetoothbot commented Jun 10, 2026

Uh oh!

bluetoothbot commented Jun 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bluetoothbot commented Jun 20, 2026

Simple rebase

Stats

CI status

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

bluetoothbot commented Jun 22, 2026

Rebase with requested adjustments

Changes applied

Stats

CI status

Uh oh!

bluetoothbot commented Jun 22, 2026

PR Review — fix: guard lock parsers against short payloads

🟢 Suggestions

Checklist

Uh oh!

bluetoothbot commented Jun 22, 2026

Rebase with requested adjustments

Changes applied

Stats

CI status

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

bluetoothbot commented May 17, 2026 •

edited

Loading

codecov Bot commented May 17, 2026 •

edited

Loading

bluetoothbot commented May 19, 2026 •

edited

Loading

bluetoothbot commented Jun 20, 2026 •

edited

Loading