Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

fix(can): close the race between the identity check and the read-only store

Closed
  • Is something wrong?
#57 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

A pull request for this has already been merged.

  • #60 by @Tichael — merged

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
embedded-iot

Research direction

Start by reading the implementations of set_can_read_only(), is_can_read_only(), and the identity confirmation and revocation functions mentioned in the issue. Then inspect the existing CAN tests and add the described interleaving test: confirm identity, unlock, clear only the identity flag, and assert the bus reads as read-only. Done when the test passes and an unconfirmed identity always reads as read-only.

Written by the indexing model from the issue text.

Description

bug

Follow-up to #49.

Problem

set_can_read_only(false) checks the identity flag and then stores the read-only flag in two separate steps:

let enabled = enabled || crate::can_log::is_can_logging() || !is_car_identity_confirmed();
CAN_READ_ONLY.store(enabled, Ordering::Relaxed);

If revoke_car_identity() runs between those two steps, the order is:

  1. set_can_read_only(false) reads identity = confirmed, so enabled = false.
  2. revoke_car_identity() clears the identity and stores CAN_READ_ONLY = true.
  3. set_can_read_only(false) stores CAN_READ_ONLY = false.

The bus ends up unlocked with no confirmed identity, which is what the gate is meant to prevent.

Is it reachable today?

No. Nothing calls set_can_read_only(false) yet, and embassy tasks on one executor only switch at await points. It becomes possible if these functions are ever called from an interrupt, a second executor (e.g. an interrupt-priority executor on ESP) or another thread on PC.

The CAN logging check doesn't have this gap: is_can_read_only() already ORs in is_can_logging(), so it's enforced when the flag is read.

Suggested fix

Treat the identity like logging: OR !is_car_identity_confirmed() into is_can_read_only(), so an unconfirmed identity always reads as read-only, whatever CAN_READ_ONLY holds. Alternatively, wrap the check and the store in critical_section::with (core-interface already depends on critical-section).

Add a test that confirms, unlocks, and then clears only the identity flag (simulating the interleaving) and asserts that is_can_read_only() returns true.

Dominant language
Rust
Stars
1
Forks
0
Avg merge
10h 56m
Merged PRs (30d)
15

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenCarControls/firmware

All issues in OpenCarControls/firmware

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.