Evidence-first verification for systems code

Find what breaks before it merges

Agentic SQA investigates every pull request in your C codebase and reports likely defects with evidence: the suspected failure mode, the exact scope and the next step. When there is nothing real, it stays silent.

Get started See how it works

No card required · 100 reviews a month · You choose the repositories

Security and data handling

A finding, not a hunch

This is what lands on a pull request. Not "consider reviewing this file." A specific risk, the suspected failure mode, the exact scope and what to do next.

drivers/accel/rocket/rocket_sysfs.c

static int rocket_power_profile_apply(struct rocket_device *rdev,
				       unsigned int profile)
{
	const struct rocket_power_profile *cfg;
	unsigned int core;

	
		return -EINVAL;

	cfg = &rocket_power_profiles[profile];

terminal

$ 
Enumerating objects: 12, done.
Writing objects: 100% (7/7), 2.14 KiB | 2.14 MiB/s, done.
To github.com:kestrel-embedded/linux.git
 * [new branch]      rocket-power -> rocket-power

ir-labs-foundry-verify Bot left a comment

Caution

This change likely introduces a bug. If it does, the bug would be reachable now.

Summary

The change adds power_profile as a sysfs profile index for rocket_power_profiles, but the range check accepts ARRAY_SIZE as an index. Writing 3 to power_profile can pass through rocket_power_profile_apply, select rocket_power_profiles[3], and read cfg->autosuspend_delay_ms for pm_runtime_set_autosuspend_delay. The path is reachable after rocket_probe calls rocket_device_init and registers the attribute group containing power_profile.

What would trigger it

Rocket device probes successfully
User writes "3" to the device power_profile sysfs attribute

Evidence and checks

Claim	Evidence	Source
Three profiles allow indices 0 through 2.	lines `15-28` define the three-entry `rocket_power_profiles` array, while the check `profile > ARRAY_SIZE` accepts `profile == 3` before indexing one element past the array	`rocket_sysfs.c:15-28`
The array size is not a valid index.	lines `97-110` show `available_power_profiles` iterating `i < ARRAY_SIZE` and `apply` and `get` dereferencing `profile` as a direct subscript, so `ARRAY_SIZE` itself is not a valid `profile` index	`rocket_sysfs.c:97-110`
The sysfs write reaches the unchecked index.	lines `70-87` show `power_profile_store` returning errors from `kstrtouint` but otherwise calling `rocket_power_profile_apply(rdev, profile)`, where `profile == 3` sets `cfg` to `rocket_power_profiles[3]` and reads `cfg->autosuspend_delay_ms` in `pm_runtime_set_autosuspend_delay`	`rocket_sysfs.c:70-87`
The attribute is registered during probe.	lines `160-183` show `rocket_probe` calling `rocket_device_init` on first core probe, and `rocket_device_init` calling `rocket_power_profile_init`, which adds the attribute group containing `power_profile`	`rocket_drv.c:160-183`

Why we think it's a bug: A direct subscript into rocket_power_profiles must use profile < ARRAY_SIZE(rocket_power_profiles); profile == ARRAY_SIZE is out of bounds.

Have feedback? Put it in a reply.

drivers/accel/rocket/rocket_sysfs.c L15-L28

15static const struct rocket_power_profile rocket_power_profiles[] = {16	{17		.name = "low-power",18		.autosuspend_delay_ms = 10,19	},20	{21		.name = "balanced",22		.autosuspend_delay_ms = 50,23	},24	{25		.name = "throughput",26		.autosuspend_delay_ms = 200,27	},28};

Three entries, valid indices 0 through 2. The new check lets 3 through.

AI solved writing code. Trusting it is the hard part.

AI multiplied the volume of code changes. It is multiplying opinions about them too: every tool can now leave a plausible remark on a pull request. Plausible is not the bar in systems code.

The scarce layer is verification. Knowing which risks are real before they merge. That is the product. Findings name the suspected failure mode, scope the affected code and carry the reasoning, so maintainers judge on evidence, not vibes.

And when nothing clears the bar, you hear nothing. Noise is a tax. We do not charge it.

From install to evidence

Install the app.

Connect your repositories through the IR Labs GitHub App, Foundry Verify. You choose exactly which repositories it can see.

Open a pull request.

Reviews trigger automatically on the repositories you enable. No pipeline changes and no config files.

The agent investigates.

It analyzes the change in the context of your codebase, not just the diff.

When a risk clears the bar, a finding lands in the PR.

Risk, suspected failure mode, scope and next steps, posted as a comment with a check-run status.

Control what gets reviewed

Every workspace includes a management console. See usage at a glance, turn repositories on and off without touching GitHub, manage billing through Stripe and reach support in one click.

The workspace console showing the current plan and review usage

The workspace console repositories card showing a connected private repository with reviews enabled

Made for the hard layer

Kernel modules, device drivers, firmware, embedded targets and the C libraries everything else stands on. The code where a bad merge costs weeks, not minutes. If your world has hardware targets, real-time constraints or a kernel tree in it, this was built for you. Any team can connect a repository in minutes.

Start free

100 reviews a month, free. Basic raises the limits for $20 a month. Enterprise conversations welcome.

Get started See pricing