syzbot

reproducer did not crash

map[KernelSrc:/app/workdir/cache/src/7997a7eaa0f2881dc89b8c06d7a0da3e794d61ea]

map[KernelObj:/app/workdir/cache/build/425cf9f5747b994349fd8956f75fecbcbf4c7c98]

map[Index:codesearch-index]

gemini-3.1-pro-preview

map[CandidateReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2)
ioctl$EVIOCSFF(r1, 0x0, &(0x7f0000000300)={0x50, 0xffff, 0x0, {0x0, 0x0}, {0x0, 0x0}, @rumble={0xffff, 0xffff}})
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
syz_usb_disconnect(r0) ReproOpts:{"procs": 1, "sandbox": "none", "fault_call": -1, "fault_nth": 0}]

You are an expert in the Linux kernel fuzzing. Your goal is to write a syzkaller program to trigger a specific bug.

Don't make assumptions about the kernel source code, use the provided codesearch tools
to examine the kernel code instead.

Document about syzkaller program syntax:
===
# Program syntax

Syzkaller uses a compact domain-specific language (DSL) for programs
to log executed programs, test its code, and persist programs in the
corpus. This page provides a brief description of the corresponding
syntax. Some useful information can also be found in the
[existing examples](/sys/linux/test) and in the program
[deserialization code](/prog/encoding.go).

Together with execution options, the DSL provides everything that
syz-executor needs to run a program.

For example, consider the program:
```
r0 = syz_open_dev$loop(&(0x7f00000011c0), 0x0, 0x0)
r1 = openat$6lowpan_control(0xffffffffffffff9c, &(0x7f00000000c0), 0x2, 0x0)
ioctl$LOOP_SET_FD(r0, 0x4c00, r1)
```

Each line in this program describes a particular syscall invocation,
with the first two calls saving the result in temporary variables `r0`
and `r1`, which are passed to the third call.

```
line = assignment | call
assignment = variable " = " call
call = syscall-name "(" [arg ["," arg]*] ")"  ["(" [call-prop ["," call-prop*] ")"]
arg = "nil" | "AUTO" | const-arg | resource-arg | result-arg | pointer-arg | string-arg | struct-arg | array-arg | union-arg
const-arg = integer
resource-arg = variable ["/" hex-integer] ["+" hex-integer]
result-arg = "<" variable "=>" arg
pointer-arg = "&" pointer-arg-addr ["=ANY"] "=" arg
pointer-arg-addr = "AUTO" | "(" pointer-addr ["/" region-size] ")"
string-arg = "'" escaped-string "'" | "\"" escaped-string "\"" | "\"$" escaped-string "\""
struct-arg =  "{" [arg ["," arg]*] "}"
array-arg = "[" [arg ["," arg]*] "]"
union-arg = "@" field-name ["=" arg]
call-prop = prop-name ": " prop-value
variable = "r" dec-integer
pointer-addr = integer
region-size = integer
integer = dec-integer | oct-integer | "0x" hex-integer
```

Programs may also contain blank lines and comments.
```
# Obtain a file handle
r0 = openat(0xffffffffffffff9c, &AUTO='./file1\x00', 0x42, 0x1ff)

# Perform a write operation
write(r0, &AUTO="01010101", 0x4)
```

### Memory management

Memory management is performed by syzkaller itself. It will allocate
virtual memory regions of the necessary size and set the final values
of pointer arguments.

By using the `AUTO` keyword, programs can give syzkaller the full
control over storing the data. This may be convenient e.g. when a
parameter must be passed by reference, but the exact location of its
value is not of particular importance.

```
r1 = syz_genetlink_get_family_id$nl80211(&AUTO='nl80211\x00', 0xffffffffffffffff)
ioctl$sock_SIOCGIFINDEX_80211(r0, 0x8933, &AUTO={'wlan0\x00', <r2=>0x0})
```

Alternatively, some data can be "anchored" to specific addresses. It
may be especially important when a memory region must be shared
between multiple calls.  In this case, pointer addresses must be given
at the 0x7f0000000000 offset. Before the actual execution, syzkaller
will adjust pointers to the start of the actual mmap'ed region.

### Call properties

Call properties specify extra information about how a specific call
must be executed. Each call within a program has its own set of call
properties. If no properties are provided, syzkaller takes the default
ones.

Currently, syzkaller supports the following call properties.

#### Fault injection
Syntax: `fail_nth: N`.

It takes an integer (base 10) argument `N`. If the argument is
non-negative, a fault will be injected into the `N`-th occasion.

```
r0 = openat$6lowpan_control(0xffffffffffffff9c, &(0x7f00000000c0), 0x2, 0x0)
ioctl$LOOP_SET_FD(r0, 0x4c00, r0) (fail_nth: 5)
```

#### Async
Syntax: `async`.

Instructs `syz-executor` not to wait until the call completes and
to proceed immediately to the next call.

```
r0 = openat(0xffffffffffffff9c, &AUTO='./file1\x00', 0x42, 0x1ff)
write(r0, &AUTO="01010101", 0x4) (async)
read(r0, &AUTO=""/4, 0x4)
close(r0)
```

When setting `async` flags be aware of the following considerations:
* Such programs should only be executed in threaded mode (i.e. `-threaded`
flag must be passed to `syz-executor`.
* Each `async` call is executed in a separate thread and there's a
limited number of available threads (`kMaxThreads = 16`).
* If an `async` call produces a resource, keep in mind that some other call
might take it as input and `syz-executor` will just pass 0 if the resource-
producing call has not finished by that time.

===

Document about syzlang system call descriptions syntax:
===
# Syscall description language

aka `syzlang` (`[siːzˈlæŋg]`)

Pseudo-formal grammar of syscall description:

```
syscallname "(" [arg ["," arg]*] ")" [type] ["(" attribute* ")"]
arg = argname type
argname = identifier
type = typename [ "[" type-options "]" ]
typename = "const" | "intN" | "intptr" | "flags" | "array" | "ptr" |
	   "string" | "filename" | "glob" | "len" |
	   "bytesize" | "bytesizeN" | "bitsize" | "vma" | "proc" |
	   "compressed_image"
type-options = [type-opt ["," type-opt]]
```

common type-options include:

```
"opt" - the argument is optional (like mmap fd argument, or accept peer argument)
```

rest of the type-options are type-specific:

```
"const": integer constant, type-options:
	value, underlying type (one of "intN", "intptr")
"intN"/"intptr": an integer without a particular meaning, type-options:
	either an optional range of values (e.g. "5:10", or "100:200")
	or a reference to flags description (see below),
	or a single value
	optionally followed by an alignment parameter if using a range
"flags": a set of values, type-options:
	reference to flags description (see below), underlying int type (e.g. "int32")
"array": a variable/fixed-length array, type-options:
	type of elements, optional size (fixed "5", or ranged "5:10", boundaries inclusive)
"ptr"/"ptr64": a pointer to an object, type-options:
	direction (in/out/inout); type of the object
	ptr64 has size of 8 bytes regardless of target pointer size
"string": a zero-terminated memory buffer (no pointer indirection implied), type-options:
	either a string value in quotes for constant strings (e.g. "foo" or `deadbeef` for hex literal),
	or a reference to string flags (special value `filename` produces file names),
	optionally followed by a buffer size (string values will be padded with \x00 to that size)
"stringnoz": a non-zero-terminated memory buffer (no pointer indirection implied), type-options:
	either a string value in quotes for constant strings (e.g. "foo" or `deadbeef` for hex literal),
	or a reference to string flags,
"glob": glob pattern to match on the target files, type-options:
	a pattern string in quotes (syntax: https://golang.org/pkg/path/filepath/#Match)
	(e.g. "/sys/" or "/sys/**/*"),
	or include exclude glob too (e.g. "/sys/**/*:-/sys/power/state")
"fmt": a string representation of an integer (not zero-terminated), type-options:
	format (one of "dec", "hex", "oct") and the value (a resource, int, flags or proc)
	the resulting data is always fixed-size (formatted as "%020llu", "0x%016llx" or "%023llo", respectively)
"len": length of another field (for array it is number of elements), type-options:
	argname of the object
"bytesize": similar to "len", but always denotes the size in bytes, type-options:
	argname of the object
"bitsize": similar to "len", but always denotes the size in bits, type-options:
	argname of the object
"offsetof": offset of the field from the beginning of the parent struct, type-options:
	field
"vma"/"vma64": a pointer to a set of pages (used as input for mmap/munmap/mremap/madvise), type-options:
	optional number of pages (e.g. vma[7]), or a range of pages (e.g. vma[2-4])
	vma64 has size of 8 bytes regardless of target pointer size
"proc": per process int (see description below), type-options:
	value range start, how many values per process, underlying type
"compressed_image": zlib-compressed disk image
	syscalls accepting compressed images must be marked with `no_generate`
	and `no_minimize` call attributes. if the content of the decompressed image
	can be checked by a `fsck`-like command, use the `fsck` syscall attribute
"text": machine code of the specified type, type-options:
	text type (x86_real, x86_16, x86_32, x86_64, arm64)
"void": type with static size 0
	mostly useful inside of templates and varlen unions, can't be syscall argument
```

flags/len/flags also have trailing underlying type type-option when used in structs/unions/pointers.

Flags are described as:

```
flagname = const ["," const]*
```

or for string flags as:

```
flagname = "\"" literal "\"" ["," "\"" literal "\""]*
```

Call attributes are:

```
"disabled": the call will not be used in fuzzing; useful to temporary disable some calls
	or prohibit particular argument combinations.
"timeout[N]": additional execution timeout (in ms) for the call on top of some default value.
"prog_timeout[N]": additional execution timeout (in ms) for the whole program if it contains this call;
	if a program contains several such calls, the max value is used.
"ignore_return": ignore return value of this syscall in fallback feedback; need to be used for calls
	that don't return fixed error codes but rather something else (e.g. the current time).
"breaks_returns": ignore return values of all subsequent calls in the program in fallback feedback (can't be trusted).
"no_generate": do not try to generate this syscall, i.e. use only seed descriptions to produce it.
"no_minimize": do not modify instances of this syscall when trying to minimize a crashing program.
"no_squash": do not attempt to pass squashed arguments to this syscall.
	Without that, the fuzzer will sometimes attempt to replace complex structures with arrays of bytes,
	possibly triggering interesting mutations, but also making programs hard to reason about.
"fsck": the content of the compressed buffer argument for this syscall is a file system and the
	string argument is a fsck-like command that will be called to verify the filesystem.
"remote_cover": wait longer to collect remote coverage for this call.
"kfuzz_test": the call is a kfuzztest target.
"snapshot": the call is enabled by default only in snapshot fuzzing mode, but can also be enabled in
    the non-snasphot mode when listed in "enable_syscalls" with its full name (as opposed to a wildcard match).
    It can also always be disabled via "disable_syscalls".
    The attribute is generally used to mark calls that are not safe to execute in non-snapshot mode
	(can lead to false positives, or lost connections to test machines.
```

## Ints

`int8`, `int16`, `int32` and `int64` denote an integer of the corresponding size.
`intptr` denotes a pointer-sized integer, i.e. C `long` type.

By appending `be` suffix (e.g. `int16be`) integers become big-endian.

It's possible to specify a range of values for an integer in the format of `int32[0:100]` or `int32[0:4096, 512]` for a 512-aligned int.

Integers can also take a reference to flags description or a value as its first type-option.
In that case, the alignment parameter is not supported.

To denote a bitfield of size N use `int64:N`.

It's possible to use these various kinds of ints as base types for `const`, `flags`, `len` and `proc`.

```
example_struct {
	f0	int8			# random 1-byte integer
	f1	const[0x42, int16be]	# const 2-byte integer with value 0x4200 (big-endian 0x42)
	f2	int32[0:100]		# random 4-byte integer with values from 0 to 100 inclusive
	f3	int32[1:10, 2]		# random 4-byte integer with values {1, 3, 5, 7, 9}
	f4	int64:20		# random 20-bit bitfield
	f5	int8[10]		# const 1-byte integer with value 10
	f6	int32[flagname]		# random 4-byte integer from the set of values referenced by flagname
}
```

## Structs

Structs are described as:

```
structname "{" "\n"
	(fieldname type ("(" fieldattribute* ")")? (if[expression])? "\n")+
"}" ("[" attribute* "]")?
```

Fields can have attributes specified in parentheses after the field, independent
of their type. `in/out/inout` attribute specify per-field direction, for example:

```
foo {
	field0	const[1, int32]	(in)
	field1	int32		(inout)
	field2	fd		(out)
}
```

You may specify conditions that determine whether a field will be included:

```
foo {
	field0	int32
	field1	int32 (if[value[field0] == 0x1])
}
```

See [the corresponding section](syscall_descriptions_syntax.md#conditional-fields)
for more details.

`out_overlay` attribute allows to have separate input and output layouts for the struct.
Fields before the `out_overlay` field are input, fields starting from `out_overlay` are output.
Input and output fields overlap in memory (both start from the beginning of the struct in memory).
For example:

```
foo {
	in0	const[1, int32]
	in1	flags[bar, int8]
	in2	ptr[in, string]
	out0	fd	(out_overlay)
	out1	int32
}
```

Structs can have attributes specified in square brackets after the struct.
Attributes are:

- `packed`: the struct does not have paddings between fields and has alignment 1; this is similar to GNU C `__attribute__((packed))`; struct alignment can be overridden with `align` attribute
- `align[N]`: the struct has alignment N and padded up to multiple of `N`; contents of the padding are unspecified (though, frequently are zeros); similar to GNU C `__attribute__((aligned(N)))`
- `size[N]`: the struct is padded up to the specified size `N`; contents of the padding are unspecified (though, frequently are zeros)

## Unions

Unions are described as:

```
unionname "[" "\n"
	(fieldname type (if[expression])? "\n")+
"]" ("[" attribute* "]")?
```

During fuzzing, syzkaller randomly picks one of the union options.

You may also specify conditions that determine whether the corresponding
option may or may not be selected, depending on values of other fields. See
[the corresponding section](syscall_descriptions_syntax.md#conditional-fields)
for more details.

Unions can have attributes specified in square brackets after the union.
Attributes are:

- `varlen`: union size is the size of the particular chosen option (not statically known); without this attribute unions are statically sized as maximum of all options (similar to C unions)
- `size[N]`: the union is padded up to the specified size `N`; contents of the padding are unspecified (though, frequently are zeros)

## Resources

Resources represent values that need to be passed from output of one syscall to input of another syscall. For example, `close` syscall requires an input value (fd) previously returned by `open` or `pipe` syscall. To achieve this, `fd` is declared as a resource. This is a way of modelling dependencies between syscalls, as defining a syscall as the producer of a resource and another syscall as the consumer defines a loose sense of ordering between them. Resources are described as:

```
"resource" identifier "[" underlying_type "]" [ ":" const ("," const)* ]
```

`underlying_type` is either one of `int8`, `int16`, `int32`, `int64`, `intptr` or another resource (which models inheritance, for example, a socket is a subtype of fd). The optional set of constants represent resource special values, for example, `0xffffffffffffffff` (-1) for "no fd", or `AT_FDCWD` for "the current dir". Special values are used once in a while as resource values. If no special values specified, special value of `0` is used. Resources can then be used as types, for example:

```
resource fd[int32]: 0xffffffffffffffff, AT_FDCWD, 1000000
resource sock[fd]
resource sock_unix[sock]

socket(...) sock
accept(fd sock, ...) sock
listen(fd sock, backlog int32)
```

Resources don't have to be necessarily returned by a syscall. They can be used as any other data type. For example:

```
resource my_resource[int32]

request_producer(..., arg ptr[out, my_resource])
request_consumer(..., arg ptr[inout, test_struct])

test_struct {
	...
	attr	my_resource
}
```

For more complex producer/consumer scenarios, field attributes can be utilized.
For example:

```
resource my_resource_1[int32]
resource my_resource_2[int32]

request_produce1_consume2(..., arg ptr[inout, test_struct])

test_struct {
	...
	field0	my_resource_1	(out)
	field1	my_resource_2	(in)
}
```

Each resource type must be "produced" (used as an output) by at least one syscall
(outside of unions and optional pointers) and "consumed" (used as an input)
by at least one syscall.

## Type Aliases

Complex types that are often repeated can be given short type aliases using the
following syntax:

```
type identifier underlying_type
```

For example:

```
type signalno int32[0:65]
type net_port proc[20000, 4, int16be]
```

Then, type alias can be used instead of the underlying type in any contexts.
Underlying type needs to be described as if it's a struct field, that is,
with the base type if it's required. However, type alias can be used as syscall
arguments as well. Underlying types are currently restricted to integer types,
`ptr`, `ptr64`, `const`, `flags` and `proc` types.

There are some builtin type aliases:

```
type bool8	int8[0:1]
type bool16	int16[0:1]
type bool32	int32[0:1]
type bool64	int64[0:1]
type boolptr	intptr[0:1]

type fileoff[BASE] BASE

type filename string[filename]

type buffer[DIR] ptr[DIR, array[int8]]
```

## Type Templates

Type templates can be declared as follows:

```
type buffer[DIR] ptr[DIR, array[int8]]
type fileoff[BASE] BASE
type nlattr[TYPE, PAYLOAD] {
	nla_len		len[parent, int16]
	nla_type	const[TYPE, int16]
	payload		PAYLOAD
} [align_4]
```

and later used as follows:

```
syscall(a buffer[in], b fileoff[int64], c ptr[in, nlattr[FOO, int32]])
```

There is builtin type template `optional` defined as:

```
type optional[T] [
	val	T
	void	void
] [varlen]
```

## Length

You can specify length of a particular field in struct or a named argument by
using `len`, `bytesize` and `bitsize` types, for example:

```
write(fd fd, buf ptr[in, array[int8]], count len[buf])

sock_fprog {
	len	len[filter, int16]
	filter	ptr[in, array[sock_filter]]
}
```

If `len`'s argument is a pointer, then the length of the pointee argument is used.

To denote the length of a field in N-byte words use `bytesizeN`, possible values
for N are 1, 2, 4 and 8.

To denote the length of the parent struct, you can use `len[parent, int8]`.
To denote the length of the higher level parent when structs are embedded into
one another, you can specify the type name of the particular parent:

```
s1 {
    f0      len[s2]  # length of s2
}

s2 {
    f0      s1
    f1      array[int32]
    f2      len[parent, int32]
}
```

`len` argument can also be a path expression which allows more complex
addressing. Path expressions are similar to C field references, but also allow
referencing parent and sibling elements. A special reference `syscall` used
in the beginning of the path allows to refer directly to the syscall arguments.
For example:

```
s1 {
	a	ptr[in, s2]
	b	ptr[in, s3]
	c	array[int8]
}

s2 {
	d	array[int8]
}

s3 {
# This refers to the array c in the parent s1.
	e	len[s1:c, int32]
# This refers to the array d in the sibling s2.
	f	len[s1:a:d, int32]
# This refers to the array k in the child s4.
	g	len[i:j, int32]
# This refers to syscall argument l.
	h	len[syscall:l, int32]
	i	ptr[in, s4]
}

s4 {
	j	array[int8]
}

foo(k ptr[in, s1], l ptr[in, array[int8]])
```

## Proc

The `proc` type can be used to denote per process integers.
The idea is to have a separate range of values for each executor, so they don't interfere.

The simplest example is a port number.
The `proc[20000, 4, int16be]` type means that we want to generate an `int16be`
integer starting from `20000` and assign `4` values for each process.
As a result the executor number `n` will get values in the `[20000 + n * 4, 20000 + (n + 1) * 4)` range.

## Integer Constants

Integer constants can be specified as decimal literals, as `0x`-prefixed
hex literals, as `'`-surrounded char literals, or as symbolic constants
extracted from kernel headers or defined by `define` directives. For example:

```
foo(a const[10], b const[-10])
foo(a const[0xabcd])
foo(a int8['a':'z'])
foo(a const[PATH_MAX])
foo(a int32[PATH_MAX])
foo(a ptr[in, array[int8, MY_PATH_MAX]])
define MY_PATH_MAX	PATH_MAX + 2
```

## Conditional fields

### In structures

In syzlang, it's possible to specify a condition for every struct field that
determines whether the field should be included or omitted:

```
header_fields {
  magic       const[0xabcd, int16]
  haveInteger int8
} [packed]

packet {
  header  header_fields
  integer int64  (if[value[header:haveInteger] == 0x1])
  body    array[int8]
} [packed]

some_call(a ptr[in, packet])
```

In this example, the `packet` structure will include the field `integer` only
if `header.haveInteger == 1`. In memory, `packet` will have the following
layout:

| header.magic = 0xabcd | header.haveInteger = 0x1 | integer | body |
| --------------------- | ------------------------ | ------- | ---- |

That corresponds to e.g. the following program:

```
some_call(&AUTO={{AUTO, 0x1}, @value=0xabcd, []})
```

If `header.haveInteger` is not `1`, syzkaller will just pretend that the field
`integer` does not exist.

```
some_call(&AUTO={{AUTO, 0x0}, @void, []})
```

| header.magic = 0xabcd | header.haveInteger = 0x0 | body |
| --------------------- | ------------------------ | ---- |

Every conditional field is assumed to be of variable length and so is the struct
to which this field belongs.

When a variable length field appears in the middle of a structure, the structure
must be marked with `[packed].`

Conditions on bitfields are prohibited:

```
struct {
  f0 int
  f1 int:3 (if[value[f0] == 0x1])  # It will not compile.
}
```

But you may reference bitfields in your conditions:

```
struct {
  f0 int:1
  f1 int:7
  f2 int   (if[value[f0] == value[f1]])
} [packed]
```

### In unions

Let's consider the following example.

```
struct {
  type int
  body alternatives
}

alternatives [
  int     int64 (if[value[struct:type] == 0x1])
  arr     array[int64, 5] (if[value[struct:type] == 0x2])
  default int32
] [varlen]

some_call(a ptr[in, struct])
```

In this case, the union option will be selected depending on the value of the
`type` field. For example, if `type` is `0x1`, then it can be either `int` or
`default`:

```
some_call(&AUTO={0x1, @int=0x123})
some_call(&AUTO={0x1, @default=0x123})
```

If `type` is `0x2`, it can be either `arr` or `default`.

If `type` is neither `0x1` nor `0x2`, syzkaller may only select `default`:

```
some_call(&AUTO={0x0, @default=0xabcd})
```

To ensure that a union can always be constructed, the last union field **must always
have no condition**.

Thus, the following definition would fail to compile:

```
alternatives [
  int int64 (if[value[struct:type] == 0x1])
  arr array[int64, 5] (if[value[struct:type] == 0x1])
] [varlen]
```

During prog mutation and generation syzkaller will select a random union field
whose condition is satisfied.

### Expression syntax

Currently, only `==`, `!=`, `&` and `||` operators are supported. However, the
functionality was designed in such a way that adding more operators is easy.
Feel free to file a GitHub issue or write us an email in case it's needed.

Expressions are evaluated as `int64` values. If the final result of an
expression is not 0, it's assumed to be satisfied.

If you want to reference a field's value, you can do it via
`value[path:to:field]`, which is similar to the `len[]` argument.

```
sub_struct {
  f0 int
  # Reference a field in a parent struct.
  f1 int (if[value[struct:f2]]) # Same as if[value[struct:f2] != 0].
}

struct {
  f2 int
  f3 sub_struct
  f4 int (if[value[f2] == 0x2]) # Reference a sibling field.
  f5 int (if[value[f3:f0] == 0x1]) # Reference a nested field.
  f6 int (if[value[f3:f0] == 0x1 || value[f3:f0] == 0x2]) # Reference a nested field which either equals to 0x1 or 0x2.
} [packed]

call(a ptr[in, struct])
```

The referenced field must be of integer type and there must be no
conditional fields in the path to it. For example, the following
descriptions will not compile.

```
struct {
  f0 int
  f1 int (if[value[f0] == 0x1])
  f2 int (if[value[f1] == 0x1])
}
```

You may also reference constants in expressions:

```
struct {
  f0 int
  f1 int
  f2 int (if[value[f0] & SOME_CONST == OTHER_CONST])
}
```

## Meta

Description files can also contain `meta` directives that specify meta-information for the whole file.

```
meta noextract
```

Tells `make extract` to not extract constants for this file.
Though, `syz-extract` can still be invoked manually on this file.

```
meta arches["arch1", "arch2"]
```

Restricts this file only to the given set of architectures.
`make extract` and `make generate` will not use it on other architectures.

## Misc

Description files also contain `include` directives that refer to Linux kernel header files,
`incdir` directives that refer to custom Linux kernel header directories
and `define` directives that define symbolic constant values.

The syzkaller executor defines some [pseudo system calls](./pseudo_syscalls.md)
that can be used as any other syscall in a description file. These pseudo
system calls expand to literal C code and can perform user-defined
custom actions. You can find some examples in
[executor/common_linux.h](../executor/common_linux.h).

Also see [tips](syscall_descriptions.md#tips) on writing good descriptions.

===

Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

Bug title: KASAN: slab-use-after-free Read in __usb_hcd_giveback_urb

The bug report to reproduce:
xpad 1-1:179.65: xpad_irq_in - usb_submit_urb failed with result -19
xpad 1-1:179.65: xpad_irq_out - usb_submit_urb failed with result -19
==================================================================
BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]
BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x28b/0x2f0 kernel/locking/spinlock_debug.c:115
Read of size 4 at addr ffff88806baa885c by task swapper/1/0

CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G             L      syzkaller #0 PREEMPT(full) 
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Call Trace:
 <IRQ>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xba/0x230 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]
 do_raw_spin_lock+0x28b/0x2f0 kernel/locking/spinlock_debug.c:115
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:133 [inline]
 _raw_spin_lock_irqsave+0x4c/0x60 kernel/locking/spinlock.c:162
 __wake_up_common_lock+0x2f/0x1f0 kernel/sched/wait.c:124
 __usb_hcd_giveback_urb+0x3b0/0x540 drivers/usb/core/hcd.c:1660
 dummy_timer+0xbbd/0x4650 drivers/usb/gadget/udc/dummy_hcd.c:2005
 __run_hrtimer kernel/time/hrtimer.c:1785 [inline]
 __hrtimer_run_queues+0x53a/0xcc0 kernel/time/hrtimer.c:1849
 hrtimer_run_softirq+0x182/0x5a0 kernel/time/hrtimer.c:1866
 handle_softirqs+0x22a/0x870 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 invoke_softirq kernel/softirq.c:496 [inline]
 __irq_exit_rcu+0x5f/0x150 kernel/softirq.c:723
 irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
 sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1056
 </IRQ>
 <TASK>
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:pv_native_safe_halt+0xf/0x20 arch/x86/kernel/paravirt.c:63
Code: 1e 6b 02 c3 cc cc cc cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d a3 22 19 00 fb f4 <e9> fc e9 02 00 cc cc cc cc cc cc cc cc cc cc cc cc 90 90 90 90 90
RSP: 0018:ffffc90000197e20 EFLAGS: 00000242
RAX: 000000000070e9cd RBX: ffffffff819aac7a RCX: 0000000080000001
RDX: 0000000000000001 RSI: ffffffff8defcc34 RDI: ffffffff8c27d880
RBP: ffffc90000197f10 R08: ffff8880b873399b R09: 1ffff110170e6733
R10: dffffc0000000000 R11: ffffed10170e6734 R12: 0000000000000001
R13: 1ffff11003b58000 R14: 0000000000000001 R15: 1ffff11003b58000
 arch_safe_halt arch/x86/kernel/process.c:766 [inline]
 default_idle+0x9/0x20 arch/x86/kernel/process.c:767
 default_idle_call+0x72/0xb0 kernel/sched/idle.c:122
 cpuidle_idle_call kernel/sched/idle.c:199 [inline]
 do_idle+0x36a/0x5f0 kernel/sched/idle.c:352
 cpu_startup_entry+0x43/0x60 kernel/sched/idle.c:451
 start_secondary+0x101/0x110 arch/x86/kernel/smpboot.c:312
 common_startup_64+0x13e/0x147
 </TASK>

Allocated by task 5914:
 kasan_save_stack mm/kasan/common.c:57 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
 poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
 __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415
 kasan_kmalloc include/linux/kasan.h:263 [inline]
 __kmalloc_cache_noprof+0x31c/0x660 mm/slub.c:5380
 kmalloc_noprof include/linux/slab.h:950 [inline]
 kzalloc_noprof include/linux/slab.h:1188 [inline]
 xpad_probe+0x428/0x1fc0 drivers/input/joystick/xpad.c:2085
 usb_probe_interface+0x668/0xc90 drivers/usb/core/driver.c:396
 call_driver_probe drivers/base/dd.c:-1 [inline]
 really_probe+0x267/0xaf0 drivers/base/dd.c:721
 __driver_probe_device+0x18c/0x320 drivers/base/dd.c:863
 driver_probe_device+0x4f/0x240 drivers/base/dd.c:893
 __device_attach_driver+0x279/0x430 drivers/base/dd.c:1021
 bus_for_each_drv+0x258/0x2f0 drivers/base/bus.c:500
 __device_attach+0x2c5/0x450 drivers/base/dd.c:1093
 device_initial_probe+0xa1/0xd0 drivers/base/dd.c:1148
 bus_probe_device+0x12a/0x220 drivers/base/bus.c:613
 device_add+0x7b6/0xb70 drivers/base/core.c:3690
 usb_set_configuration+0x1a87/0x2110 drivers/usb/core/message.c:2266
 usb_generic_driver_probe+0x8d/0x150 drivers/usb/core/generic.c:250
 usb_probe_device+0x1c4/0x3b0 drivers/usb/core/driver.c:291
 call_driver_probe drivers/base/dd.c:-1 [inline]
 really_probe+0x267/0xaf0 drivers/base/dd.c:721
 __driver_probe_device+0x18c/0x320 drivers/base/dd.c:863
 driver_probe_device+0x4f/0x240 drivers/base/dd.c:893
 __device_attach_driver+0x279/0x430 drivers/base/dd.c:1021
 bus_for_each_drv+0x258/0x2f0 drivers/base/bus.c:500
 __device_attach+0x2c5/0x450 drivers/base/dd.c:1093
 device_initial_probe+0xa1/0xd0 drivers/base/dd.c:1148
 bus_probe_device+0x12a/0x220 drivers/base/bus.c:613
 device_add+0x7b6/0xb70 drivers/base/core.c:3690
 usb_new_device+0xa08/0x16f0 drivers/usb/core/hub.c:2695
 hub_port_connect drivers/usb/core/hub.c:5567 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
 port_event drivers/usb/core/hub.c:5871 [inline]
 hub_event+0x2a1c/0x4f30 drivers/usb/core/hub.c:5953
 process_one_work kernel/workqueue.c:3288 [inline]
 process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3371
 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3452
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Freed by task 980:
 kasan_save_stack mm/kasan/common.c:57 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
 poison_slab_object mm/kasan/common.c:253 [inline]
 __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
 kasan_slab_free include/linux/kasan.h:235 [inline]
 slab_free_hook mm/slub.c:2685 [inline]
 slab_free mm/slub.c:6165 [inline]
 kfree+0x1c1/0x630 mm/slub.c:6483
 xpad_disconnect+0x350/0x480 drivers/input/joystick/xpad.c:2269
 usb_unbind_interface+0x26e/0x910 drivers/usb/core/driver.c:458
 device_remove drivers/base/dd.c:633 [inline]
 __device_release_driver drivers/base/dd.c:1344 [inline]
 device_release_driver_internal+0x4d9/0x870 drivers/base/dd.c:1367
 bus_remove_device+0x455/0x570 drivers/base/bus.c:657
 device_del+0x527/0x8f0 drivers/base/core.c:3879
 usb_disable_device+0x3d4/0x8d0 drivers/usb/core/message.c:1476
 usb_disconnect+0x32f/0x990 drivers/usb/core/hub.c:2345
 hub_port_connect drivers/usb/core/hub.c:5407 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
 port_event drivers/usb/core/hub.c:5871 [inline]
 hub_event+0x1cc9/0x4f30 drivers/usb/core/hub.c:5953
 process_one_work kernel/workqueue.c:3288 [inline]
 process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3371
 worker_thread+0xa53/0xfc0 kernel/workqueue.c:3452
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

The buggy address belongs to the object at ffff88806baa8800
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 92 bytes inside of
 freed 1024-byte region [ffff88806baa8800, ffff88806baa8c00)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806baad000 pfn:0x6baa8
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfff00000000240(workingset|head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000240 ffff88813fea7dc0 ffffea00007dbe10 ffffea000097be10
raw: ffff88806baad000 000000080010000d 00000000f5000000 0000000000000000
head: 00fff00000000240 ffff88813fea7dc0 ffffea00007dbe10 ffffea000097be10
head: ffff88806baad000 000000080010000d 00000000f5000000 0000000000000000
head: 00fff00000000003 ffffea0001aeaa01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5847, tgid 5847 (syz-executor), ts 86290423441, free_ts 78083357419
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1889
 prep_new_page mm/page_alloc.c:1897 [inline]
 get_page_from_freelist+0x24dc/0x2580 mm/page_alloc.c:3962
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5250
 alloc_slab_page mm/slub.c:3292 [inline]
 allocate_slab+0x77/0x660 mm/slub.c:3481
 new_slab mm/slub.c:3539 [inline]
 refill_objects+0x331/0x3c0 mm/slub.c:7175
 refill_sheaf mm/slub.c:2812 [inline]
 __pcs_replace_empty_main+0x2e6/0x730 mm/slub.c:4615
 alloc_from_pcs mm/slub.c:4717 [inline]
 slab_alloc_node mm/slub.c:4851 [inline]
 __do_kmalloc_node mm/slub.c:5259 [inline]
 __kmalloc_noprof+0x474/0x760 mm/slub.c:5272
 kmalloc_noprof include/linux/slab.h:954 [inline]
 kzalloc_noprof include/linux/slab.h:1188 [inline]
 ip6t_alloc_initial_table+0x6b/0x6d0 net/ipv6/netfilter/ip6_tables.c:40
 ip6table_security_table_init+0x1b/0x70 net/ipv6/netfilter/ip6table_security.c:42
 xt_find_table_lock+0x30c/0x3e0 net/netfilter/x_tables.c:1283
 xt_request_find_table_lock+0x26/0x100 net/netfilter/x_tables.c:1308
 get_info net/ipv6/netfilter/ip6_tables.c:979 [inline]
 do_ip6t_get_ctl+0x716/0x1230 net/ipv6/netfilter/ip6_tables.c:1668
 nf_getsockopt+0x26e/0x290 net/netfilter/nf_sockopt.c:116
 ipv6_getsockopt+0x1fd/0x2b0 net/ipv6/ipv6_sockglue.c:1473
 do_sock_getsockopt+0x2d3/0x3f0 net/socket.c:2448
 __sys_getsockopt net/socket.c:2477 [inline]
 __do_sys_getsockopt net/socket.c:2484 [inline]
 __se_sys_getsockopt net/socket.c:2481 [inline]
 __x64_sys_getsockopt+0x1a4/0x240 net/socket.c:2481
page last free pid 5810 tgid 5810 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1433 [inline]
 free_unref_folios+0xed5/0x16d0 mm/page_alloc.c:3040
 folios_put_refs+0x789/0x8d0 mm/swap.c:1002
 free_pages_and_swap_cache+0x2e7/0x5b0 mm/swap_state.c:423
 __tlb_batch_free_encoded_pages mm/mmu_gather.c:138 [inline]
 tlb_batch_pages_flush mm/mmu_gather.c:151 [inline]
 tlb_flush_mmu_free mm/mmu_gather.c:398 [inline]
 tlb_flush_mmu+0x6d3/0xa30 mm/mmu_gather.c:405
 tlb_finish_mmu+0xf9/0x230 mm/mmu_gather.c:530
 unmap_region+0x2a5/0x330 mm/vma.c:488
 vms_clear_ptes mm/vma.c:1284 [inline]
 vms_complete_munmap_vmas+0x493/0xc60 mm/vma.c:1326
 do_vmi_align_munmap+0x3b7/0x4b0 mm/vma.c:1585
 do_vmi_munmap+0x252/0x2d0 mm/vma.c:1633
 __vm_munmap+0x22c/0x3d0 mm/vma.c:3261
 __do_sys_munmap mm/mmap.c:1078 [inline]
 __se_sys_munmap mm/mmap.c:1075 [inline]
 __x64_sys_munmap+0x60/0x70 mm/mmap.c:1075
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
 ffff88806baa8700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88806baa8780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88806baa8800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                    ^
 ffff88806baa8880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88806baa8900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
----------------
Code disassembly (best guess), 1 bytes skipped:
   0:	6b 02 c3             	imul   $0xffffffc3,(%rdx),%eax
   3:	cc                   	int3
   4:	cc                   	int3
   5:	cc                   	int3
   6:	cc                   	int3
   7:	cc                   	int3
   8:	cc                   	int3
   9:	cc                   	int3
   a:	90                   	nop
   b:	90                   	nop
   c:	90                   	nop
   d:	90                   	nop
   e:	90                   	nop
   f:	90                   	nop
  10:	90                   	nop
  11:	90                   	nop
  12:	90                   	nop
  13:	90                   	nop
  14:	90                   	nop
  15:	90                   	nop
  16:	90                   	nop
  17:	90                   	nop
  18:	90                   	nop
  19:	90                   	nop
  1a:	f3 0f 1e fa          	endbr64
  1e:	66 90                	xchg   %ax,%ax
  20:	0f 00 2d a3 22 19 00 	verw   0x1922a3(%rip)        # 0x1922ca
  27:	fb                   	sti
  28:	f4                   	hlt
* 29:	e9 fc e9 02 00       	jmp    0x2ea2a <-- trapping instruction
  2e:	cc                   	int3
  2f:	cc                   	int3
  30:	cc                   	int3
  31:	cc                   	int3
  32:	cc                   	int3
  33:	cc                   	int3
  34:	cc                   	int3
  35:	cc                   	int3
  36:	cc                   	int3
  37:	cc                   	int3
  38:	cc                   	int3
  39:	cc                   	int3
  3a:	90                   	nop
  3b:	90                   	nop
  3c:	90                   	nop
  3d:	90                   	nop
  3e:	90                   	nop


The list of existing description files:
acpi_thermal_rel.txt
aio.txt
auto.txt
binfmt.txt
bpf.txt
bpf_prog.txt
bpf_trace.txt
cgroup.txt
damon.txt
dev_ashmem.txt
dev_bifrost.txt
dev_binder.txt
dev_binderfs.txt
dev_block.txt
dev_bsg.txt
dev_bus_usb.txt
dev_camx.txt
dev_cdrom.txt
dev_cec.txt
dev_char_usb.txt
dev_comedi.txt
dev_dma_heap.txt
dev_dri.txt
dev_dsp.txt
dev_dvb_demux.txt
dev_dvb_dvr.txt
dev_dvb_frontend.txt
dev_fb.txt
dev_floppy.txt
dev_hidraw.txt
dev_i2c.txt
dev_i915.txt
dev_img_rogue.txt
dev_infiniband_rdma.txt
dev_infiniband_rdma_cm.txt
dev_input.txt
dev_iommu.txt
dev_kvm.txt
dev_kvm_amd64.txt
dev_kvm_arm64.txt
dev_kvm_extra.txt
dev_kvm_riscv64.txt
dev_loop.txt
dev_mali.txt
dev_media.txt
dev_msm.txt
dev_msr.txt
dev_nbd.txt
dev_net_tun.txt
dev_panthor.txt
dev_ppp.txt
dev_ptmx.txt
dev_ptp.txt
dev_qat_adf_ctl.txt
dev_qrtr_tun.txt
dev_random.txt
dev_rfkill.txt
dev_rtc.txt
dev_sequencer.txt
dev_sg.txt
dev_snapshot.txt
dev_snd_control.txt
dev_snd_hw.txt
dev_snd_midi.txt
dev_snd_pcm.txt
dev_snd_seq.txt
dev_snd_timer.txt
dev_sr.txt
dev_sw_sync.txt
dev_tlk_device.txt
dev_trusty.txt
dev_udmabuf.txt
dev_uhid.txt
dev_uinput.txt
dev_usb_hiddev.txt
dev_usbmon.txt
dev_userio.txt
dev_vfio.txt
dev_vga_arbiter.txt
dev_vhci.txt
dev_video4linux.txt
dev_video4linux_vim2m.txt
dev_virtual_nci.txt
dev_vtpm.txt
fanotify.txt
filesystem.txt
fs_9p.txt
fs_fuse.txt
fs_incfs.txt
fs_ioctl.txt
fs_ioctl_autofs.txt
fs_ioctl_btrfs.txt
fs_ioctl_ext4.txt
fs_ioctl_f2fs.txt
fs_ioctl_fat.txt
fs_ioctl_fscrypt.txt
fs_ioctl_fsverity.txt
fs_ioctl_nilfs2.txt
fs_ioctl_ocfs2.txt
fs_ioctl_xfs.txt
futex.txt
hafnium.txt
inotify.txt
io_uring.txt
ipc.txt
key.txt
kfuzztest.txt
l2cap.txt
landlock.txt
lsm.txt
namespaces.txt
net_80211.txt
netfilter.txt
netfilter_arp.txt
netfilter_bridge.txt
netfilter_ipv4.txt
netfilter_ipv6.txt
netfilter_ipvs.txt
netfilter_targets.txt
pagemap_ioctl.txt
perf.txt
prctl.txt
quotactl.txt
seccomp.txt
security_apparmor.txt
security_selinux.txt
security_smack.txt
socket.txt
socket_alg.txt
socket_ax25.txt
socket_bluetooth.txt
socket_caif.txt
socket_can.txt
socket_ieee802154.txt
socket_inet.txt
socket_inet6.txt
socket_inet_dccp.txt
socket_inet_icmp.txt
socket_inet_igmp.txt
socket_inet_l2tp.txt
socket_inet_sctp.txt
socket_inet_tcp.txt
socket_inet_udp.txt
socket_ip_tunnel.txt
socket_isdn.txt
socket_kcm.txt
socket_key.txt
socket_llc.txt
socket_netlink.txt
socket_netlink_audit.txt
socket_netlink_crypto.txt
socket_netlink_generic.txt
socket_netlink_generic_80211.txt
socket_netlink_generic_batadv.txt
socket_netlink_generic_devlink.txt
socket_netlink_generic_ethtool.txt
socket_netlink_generic_fou.txt
socket_netlink_generic_gtp.txt
socket_netlink_generic_mptcp.txt
socket_netlink_generic_net_dm.txt
socket_netlink_generic_netlabel.txt
socket_netlink_generic_nfc.txt
socket_netlink_generic_seg6.txt
socket_netlink_generic_smc.txt
socket_netlink_generic_team.txt
socket_netlink_generic_wireguard.txt
socket_netlink_netfilter.txt
socket_netlink_netfilter_acct.txt
socket_netlink_netfilter_conntrack.txt
socket_netlink_netfilter_conntrack_exp.txt
socket_netlink_netfilter_conntrack_helper.txt
socket_netlink_netfilter_ipset.txt
socket_netlink_netfilter_log.txt
socket_netlink_netfilter_nft_compat.txt
socket_netlink_netfilter_nftables.txt
socket_netlink_netfilter_osf.txt
socket_netlink_netfilter_queue.txt
socket_netlink_netfilter_timeout.txt
socket_netlink_rdma.txt
socket_netlink_route.txt
socket_netlink_route_sched.txt
socket_netlink_route_sched_retired.txt
socket_netlink_sock_diag.txt
socket_netlink_xfrm.txt
socket_netrom.txt
socket_nfc.txt
socket_nvme_of_tcp.txt
socket_packet.txt
socket_phonet.txt
socket_pppox.txt
socket_qipcrtr.txt
socket_rds.txt
socket_rose.txt
socket_rxrpc.txt
socket_tipc.txt
socket_tipc_netlink.txt
socket_unix.txt
socket_vnet.txt
socket_x25.txt
socket_xdp.txt
sys.txt
uffd.txt
usbip.txt
vmw_vmci.txt
vnet.txt
vnet_mptcp.txt
vusb.txt
watch_queue.txt
xattr.txt

gemini-3.1-pro-preview

							input: 19275
							output: 18
							thoughts: 557
						

**Analyzing a KASAN Slab-Use-After-Free in USB Handling**

Okay, so I'm looking at a KASAN slab-use-after-free bug, and it looks like it's happening in `__usb_hcd_giveback_urb`. The crash report points to `debug_spin_lock_before` within the kernel's locking mechanism, specifically when it's being called by `do_raw_spin_lock`. The trace tells me it's a read of size 4, and the task involved is the `swapper`. This immediately suggests a critical issue – the system's core is trying to access freed memory.

The call trace reveals the culprit: `__usb_hcd_giveback_urb` is called from `dummy_timer` (in the `dummy_hcd` driver). This seems like a timer completion handler, or something similar. Further back in the trace, I see that the memory was allocated during the `xpad_probe` function (within the `xpad` joystick driver) and freed during `xpad_disconnect`.

My initial thought is that `xpad_disconnect` is freeing some memory, likely a `struct usb_xpad`, but a URB (USB Request Block) is still active. Then, the completion handler for the URB gets called (`xpad_irq_in` or `xpad_irq_out`). This completion handler, or potentially the `__usb_hcd_giveback_urb` function itself, then tries to access data that's already been freed. Is it the URB's context that's being accessed, or the URB itself?

Wait, hold on, it's occurring in `debug_spin_lock_before`. The `__usb_hcd_giveback_urb` function will call the `urb->complete(urb)` handler. 

The immediate next step is to examine `xpad_disconnect` in the `drivers/input/joystick/xpad.c` file, to understand precisely what memory is being freed and how this relates to URB completion. I need to trace the memory deallocation and ensure there's proper synchronization, or, find where the URB completion handler is, and how its execution is synchronized with deallocation.

map[Expression:xpad_disconnect]

map[Output:drivers/input/joystick/xpad.c=2069=static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id)
--
drivers/input/joystick/xpad.c-2247-
drivers/input/joystick/xpad.c:2248:static void xpad_disconnect(struct usb_interface *intf)
drivers/input/joystick/xpad.c-2249-{
--
drivers/input/joystick/xpad.c=2333=static struct usb_driver xpad_driver = {
--
drivers/input/joystick/xpad.c-2335-	.probe		= xpad_probe,
drivers/input/joystick/xpad.c:2336:	.disconnect	= xpad_disconnect,
drivers/input/joystick/xpad.c-2337-	.suspend	= xpad_suspend,
]

gemini-3.1-pro-preview

							input: 20585
							output: 44
							thoughts: 13
						

Here's my summary, as the expert:

**Diving into `xpad_disconnect`**

Okay, time to get my hands dirty. I need to understand what's going on with this xpad disconnect issue, so the first logical step is to dive right into the source code for the `xpad_disconnect` function. That's where the heart of the connection termination logic resides, after all. Gotta see how it's *supposed* to behave, what the expected cleanup is, and where potential flaws might be hiding. I'm looking for anything that could be incomplete, mis-handled, or not properly synchronized. I'm expecting to find a series of deregistration calls, resource releases, and probably some state updates. Knowing this level of detail is critical for debugging and finding the root cause of these connection problems. Time to dig in!

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_disconnect]

map[SourceCode:2248:	static void xpad_disconnect(struct usb_interface *intf)
2249:	{
2250:		struct usb_xpad *xpad = usb_get_intfdata(intf);
2251:	
2252:		if (xpad->xtype == XTYPE_XBOX360W)
2253:			xpad360w_stop_input(xpad);
2254:	
2255:		xpad_deinit_input(xpad);
2256:	
2257:		/*
2258:		 * Now that both input device and LED device are gone we can
2259:		 * stop output URB.
2260:		 */
2261:		xpad_stop_output(xpad);
2262:	
2263:		xpad_deinit_output(xpad);
2264:	
2265:		usb_free_urb(xpad->irq_in);
2266:		usb_free_coherent(xpad->udev, XPAD_PKT_LEN,
2267:				xpad->idata, xpad->idata_dma);
2268:	
2269:		kfree(xpad);
2270:	
2271:		usb_set_intfdata(intf, NULL);
2272:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 21217
							output: 140
							thoughts: 119
						

Okay, here's my breakdown of what's happening, from my expert perspective:

**Deconstructing the xpad Disconnect Sequence**

Right, so `xpad_disconnect` is the function that handles the removal of an Xpad device. My initial thought is, "Okay, what's involved in tearing down this particular instance?" The code calls a series of de-initialization functions: `xpad_deinit_input`, `xpad_stop_output`, and `xpad_deinit_output`. Pretty standard, logically separating input, output, and overall device state clean-up.

But then, the details get interesting. It's freeing `xpad->irq_in` with `usb_free_urb()`. My immediate question is: Is the URB itself terminated before being freed or does the call take care of it? It's crucial for resource management to ensure the underlying USB transfer is properly stopped. It also does a `usb_free_coherent()` and `kfree(xpad)` which seems appropriate.

So, I need to check the implementations of the deinit functions: `xpad_deinit_input`, `xpad_stop_output` and `xpad_deinit_output` to check the details of how the USB resources are being managed and ensure proper shutdown before the URB memory is freed.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_deinit_input]

map[SourceCode:1949:	static void xpad_deinit_input(struct usb_xpad *xpad)
1950:	{
1951:		if (xpad->input_created) {
1952:			xpad->input_created = false;
1953:			xpad_led_disconnect(xpad);
1954:			input_unregister_device(xpad->dev);
1955:		}
1956:	}
 SourceFile:drivers/input/joystick/xpad.c]

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_stop_output]

map[SourceCode:1455:	static void xpad_stop_output(struct usb_xpad *xpad)
1456:	{
1457:		if (xpad->xtype != XTYPE_UNKNOWN) {
1458:			if (!usb_wait_anchor_empty_timeout(&xpad->irq_out_anchor,
1459:							   5000)) {
1460:				dev_warn(&xpad->intf->dev,
1461:					 "timed out waiting for output URB to complete, killing\n");
1462:				usb_kill_anchored_urbs(&xpad->irq_out_anchor);
1463:			}
1464:		}
1465:	}
 SourceFile:drivers/input/joystick/xpad.c]

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_deinit_output]

map[SourceCode:1467:	static void xpad_deinit_output(struct usb_xpad *xpad)
1468:	{
1469:		if (xpad->xtype != XTYPE_UNKNOWN) {
1470:			usb_free_urb(xpad->irq_out);
1471:			usb_free_coherent(xpad->udev, XPAD_PKT_LEN,
1472:					xpad->odata, xpad->odata_dma);
1473:		}
1474:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 22306
							output: 44
							thoughts: 87
						

**Investigating the `xpad_disconnect` Routine**

Okay, hold on a second. This doesn't seem right. My initial assumption was that `xpad_disconnect` would cleanly terminate the `xpad->irq_in` input URB, but it appears that it *doesn't* explicitly do that. Now, that's interesting. I need to figure out where that input URB gets killed. Just to be clear, `xpad->irq_in` is the URB responsible for incoming data, so it's critical it be handled correctly.

My standard approach would be to trace the life cycle of the device, particularly the shutdown process. Often, `input_unregister_device` takes care of the cleanup, and that function calls the `input_dev->close` method. It's highly probable that `xpad_close` is the method responsible for terminating that URB. Therefore, I need to check `xpad_close`. I need to ensure the URB gets terminated there. Let's delve into that function and make sure it's doing what it should.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_close]

map[SourceCode:1911:	static void xpad_close(struct input_dev *dev)
1912:	{
1913:		struct usb_xpad *xpad = input_get_drvdata(dev);
1914:	
1915:		xpad_stop_input(xpad);
1916:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 22792
							output: 46
							thoughts: 12
						

Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:

**Analyzing the Function Call: `xpad_stop_input`**

Alright, so the prompt is just "Let's see `xpad_stop_input`". That's intriguing. My initial thought process immediately jumps into several areas. First, I'm already mentally parsing `xpad`, so this is very likely related to Xbox controller input, specifically its handling within a system. I'm assuming we are looking at kernel-level code, or at the very least, something fairly low-level, not user space.

The function name, `xpad_stop_input`, immediately signals that we are concerned with disabling or halting the input processing for an Xbox controller, or perhaps a series of them, managed through the Xpad driver. Now the real questions start to come. What is the context? Am I looking at a specific driver implementation, debugging a problem, or is this about broader system design?

Is this the final function to call before I unregister the device, or is this just to temporarily disable input due to an event. If it's a stop command, what is the impact to the data? Are there any race conditions with the input buffer needing attention? The implications of the function's behavior are highly contextual. Are there any resource management concerns associated with calling this, such as closing input devices or freeing allocated buffers. What are the mutexes or locks being held at this point, if any? I'm already formulating questions about the function's parameters, return values, any side effects, and how it interacts with other parts of the driver's state machine. This function is likely a critical part of the input device's lifecycle.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_stop_input]

map[SourceCode:1840:	static void xpad_stop_input(struct usb_xpad *xpad)
1841:	{
1842:		usb_kill_urb(xpad->irq_in);
1843:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 23318
							output: 44
							thoughts: 138
						

Okay, let me think this through.

**Analyzing the xpad Driver's Shutdown Sequence**

Alright, so `xpad_close` calls `xpad_stop_input`. I need to figure out the potential failure points. `xpad_stop_input`, from what I recall, is what's responsible for killing `xpad->irq_in`, right? So the interrupt input is stopped when the device is closed. But what if `xpad->input_created` is already false? And what happens if `input_unregister_device` doesn't call `xpad_close` as expected? That's a critical detail to get right. Hang on, I think I remember...`input_unregister_device` *only* calls `xpad_close` if the device is actually opened. Meaning, if the device isn't opened, `xpad_close` isn't called during unregistration. That makes sense. Let me follow this through… If the device isn't opened, `xpad->irq_in` wouldn't be submitted in the first place, right? Therefore, `xpad_close` wouldn't be needed for it in that scenario? Makes sense. Okay, let's just make sure I'm not forgetting something. I should review `xpad_open` to confirm my assumptions and make sure all bases are covered. I need to make sure I understand the complete lifecycle.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_open]

map[SourceCode:1904:	static int xpad_open(struct input_dev *dev)
1905:	{
1906:		struct usb_xpad *xpad = input_get_drvdata(dev);
1907:	
1908:		return xpad_start_input(xpad);
1909:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 23927
							output: 46
							thoughts: 12
						

Okay, here's my attempt at summarizing the thought process, as if it were my own, assuming I'm an expert in the field:

**Initial Examination of `xpad_start_input`**

Alright, let's dive into `xpad_start_input`. Immediately, I'm thinking about the fundamental purpose here: initiating input handling for an Xpad device. This probably kicks off the process of registering the device with the input subsystem, setting up any necessary data structures, and getting ready to receive data from the controller. I need to quickly determine whether the driver has already been loaded, and the Xpad controller present. I'm going to want to examine the function's arguments to understand its entry point, and determine whether its a general routine that handles multiple Xpad device types, or specific to a sub-category. From there, I'll need to confirm what steps it takes to connect with a controller, and whether its a specific controller, or a range of controllers. After that, I would then expect to see the code handling any necessary hardware initialization. Specifically, I'm looking for how it handles the interrupts and how the driver gets the data from the controller. It's likely involved in setting up the interrupt handlers, possibly configuring DMA if it's used, and maybe mapping the hardware registers. The next logical step is to see how the input reports are handled, which often includes setting up input devices. I'm especially interested in how it maps controller input (buttons, axes, triggers) to the standard input events. Also, I'm curious if the function handles hotplugging, or if that is a separate mechanism. The focus here is on ensuring the device is correctly detected, initialized, and ready to send input events. Finally, I'll be looking for how gracefully the function handles errors - are there sufficient checks and error messages? If it is a good initializiation function, these aspects are very important, as they provide an excellent starting point for determining the overall quality of the driver's implementation.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_start_input]

map[SourceCode:1801:	static int xpad_start_input(struct usb_xpad *xpad)
1802:	{
1803:		int error;
1804:	
1805:		if (usb_submit_urb(xpad->irq_in, GFP_KERNEL))
1806:			return -EIO;
1807:	
1808:		if (xpad->xtype == XTYPE_XBOXONE) {
1809:			error = xpad_start_xbox_one(xpad);
1810:			if (error) {
1811:				usb_kill_urb(xpad->irq_in);
1812:				return error;
1813:			}
1814:		}
1815:		if (xpad->xtype == XTYPE_XBOX360) {
1816:			/*
1817:			 * Some third-party controllers Xbox 360-style controllers
1818:			 * require this message to finish initialization.
1819:			 */
1820:			u8 dummy[20];
1821:	
1822:			error = usb_control_msg_recv(xpad->udev, 0,
1823:						     /* bRequest */ 0x01,
1824:						     /* bmRequestType */
1825:						     USB_TYPE_VENDOR | USB_DIR_IN |
1826:							USB_RECIP_INTERFACE,
1827:						     /* wValue */ 0x100,
1828:						     /* wIndex */ 0x00,
1829:						     dummy, sizeof(dummy),
1830:						     25, GFP_KERNEL);
1831:			if (error)
1832:				dev_warn(&xpad->dev->dev,
1833:					 "unable to receive magic message: %d\n",
1834:					 error);
1835:		}
1836:	
1837:		return 0;
1838:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 24986
							output: 44
							thoughts: 53
						

Okay, let me think this through.

**Analyzing the xpad Driver's Input Handling**

Right, so I'm tracing the data flow here in this `xpad` driver. The interrupt input, that `xpad->irq_in` thing, gets submitted during the `xpad_start_input` function, which makes sense. And that `xpad_start_input` function is called from `xpad_open`, which is, well, the expected entry point for device interaction.

But hold on a second... is `xpad_start_input` *also* being called from the probe function, `xpad_probe`? That's the part I need to verify. My gut tells me this is the case as part of the initial device setup. I need to refresh my memory of the initialization sequence. I suspect this is the key to understanding the full input handling lifecycle and ensuring that the interrupt-based input is properly established from the start, not just during open. I need to review the `xpad_probe` function definition to confirm that.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_probe]

map[SourceCode:2069:	static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id)
2070:	{
2071:		struct usb_device *udev = interface_to_usbdev(intf);
2072:		struct usb_xpad *xpad;
2073:		struct usb_endpoint_descriptor *ep_irq_in, *ep_irq_out;
2074:		int i, error;
2075:	
2076:		if (intf->cur_altsetting->desc.bNumEndpoints != 2)
2077:			return -ENODEV;
2078:	
2079:		for (i = 0; xpad_device[i].idVendor; i++) {
2080:			if ((le16_to_cpu(udev->descriptor.idVendor) == xpad_device[i].idVendor) &&
2081:			    (le16_to_cpu(udev->descriptor.idProduct) == xpad_device[i].idProduct))
2082:				break;
2083:		}
2084:	
2085:		xpad = kzalloc_obj(*xpad);
2086:		if (!xpad)
2087:			return -ENOMEM;
2088:	
2089:		usb_make_path(udev, xpad->phys, sizeof(xpad->phys));
2090:		strlcat(xpad->phys, "/input0", sizeof(xpad->phys));
2091:	
2092:		xpad->idata = usb_alloc_coherent(udev, XPAD_PKT_LEN,
2093:						 GFP_KERNEL, &xpad->idata_dma);
2094:		if (!xpad->idata) {
2095:			error = -ENOMEM;
2096:			goto err_free_mem;
2097:		}
2098:	
2099:		xpad->irq_in = usb_alloc_urb(0, GFP_KERNEL);
2100:		if (!xpad->irq_in) {
2101:			error = -ENOMEM;
2102:			goto err_free_idata;
2103:		}
2104:	
2105:		xpad->udev = udev;
2106:		xpad->intf = intf;
2107:		xpad->mapping = xpad_device[i].mapping;
2108:		xpad->xtype = xpad_device[i].xtype;
2109:		xpad->name = xpad_device[i].name;
2110:		if (xpad_device[i].flags & FLAG_DELAY_INIT)
2111:			xpad->delay_init = true;
2112:	
2113:		xpad->packet_type = PKT_XB;
2114:		INIT_WORK(&xpad->work, xpad_presence_work);
2115:	
2116:		if (xpad->xtype == XTYPE_UNKNOWN) {
2117:			if (intf->cur_altsetting->desc.bInterfaceClass == USB_CLASS_VENDOR_SPEC) {
2118:				if (intf->cur_altsetting->desc.bInterfaceProtocol == 129)
2119:					xpad->xtype = XTYPE_XBOX360W;
2120:				else if (intf->cur_altsetting->desc.bInterfaceProtocol == 208)
2121:					xpad->xtype = XTYPE_XBOXONE;
2122:				else
2123:					xpad->xtype = XTYPE_XBOX360;
2124:			} else {
2125:				xpad->xtype = XTYPE_XBOX;
2126:			}
2127:	
2128:			if (dpad_to_buttons)
2129:				xpad->mapping |= MAP_DPAD_TO_BUTTONS;
2130:			if (triggers_to_buttons)
2131:				xpad->mapping |= MAP_TRIGGERS_TO_BUTTONS;
2132:			if (sticks_to_null)
2133:				xpad->mapping |= MAP_STICKS_TO_NULL;
2134:		}
2135:	
2136:		if (xpad->xtype == XTYPE_XBOXONE &&
2137:		    intf->cur_altsetting->desc.bInterfaceNumber != GIP_WIRED_INTF_DATA) {
2138:			/*
2139:			 * The Xbox One controller lists three interfaces all with the
2140:			 * same interface class, subclass and protocol. Differentiate by
2141:			 * interface number.
2142:			 */
2143:			error = -ENODEV;
2144:			goto err_free_in_urb;
2145:		}
2146:	
2147:		ep_irq_in = ep_irq_out = NULL;
2148:	
2149:		for (i = 0; i < 2; i++) {
2150:			struct usb_endpoint_descriptor *ep =
2151:					&intf->cur_altsetting->endpoint[i].desc;
2152:	
2153:			if (usb_endpoint_xfer_int(ep)) {
2154:				if (usb_endpoint_dir_in(ep))
2155:					ep_irq_in = ep;
2156:				else
2157:					ep_irq_out = ep;
2158:			}
2159:		}
2160:	
2161:		if (!ep_irq_in || !ep_irq_out) {
2162:			error = -ENODEV;
2163:			goto err_free_in_urb;
2164:		}
2165:	
2166:		error = xpad_init_output(intf, xpad, ep_irq_out);
2167:		if (error)
2168:			goto err_free_in_urb;
2169:	
2170:		usb_fill_int_urb(xpad->irq_in, udev,
2171:				 usb_rcvintpipe(udev, ep_irq_in->bEndpointAddress),
2172:				 xpad->idata, XPAD_PKT_LEN, xpad_irq_in,
2173:				 xpad, ep_irq_in->bInterval);
2174:		xpad->irq_in->transfer_dma = xpad->idata_dma;
2175:		xpad->irq_in->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
2176:	
2177:		usb_set_intfdata(intf, xpad);
2178:	
2179:		/* Packet type detection */
2180:		if (le16_to_cpu(udev->descriptor.idVendor) == 0x045e) { /* Microsoft controllers */
2181:			if (le16_to_cpu(udev->descriptor.idProduct) == 0x02e3) {
2182:				/* The original elite controller always uses the oldest
2183:				 * type of extended packet
2184:				 */
2185:				xpad->packet_type = PKT_XBE1;
2186:			} else if (le16_to_cpu(udev->descriptor.idProduct) == 0x0b00) {
2187:				/* The elite 2 controller has seen multiple packet
2188:				 * revisions. These are tied to specific firmware
2189:				 * versions
2190:				 */
2191:				if (le16_to_cpu(udev->descriptor.bcdDevice) < 0x0500) {
2192:					/* This is the format that the Elite 2 used
2193:					 * prior to the BLE update
2194:					 */
2195:					xpad->packet_type = PKT_XBE2_FW_OLD;
2196:				} else if (le16_to_cpu(udev->descriptor.bcdDevice) <
2197:					   0x050b) {
2198:					/* This is the format that the Elite 2 used
2199:					 * prior to the update that split the packet
2200:					 */
2201:					xpad->packet_type = PKT_XBE2_FW_5_EARLY;
2202:				} else {
2203:					/* The split packet format that was introduced
2204:					 * in firmware v5.11
2205:					 */
2206:					xpad->packet_type = PKT_XBE2_FW_5_11;
2207:				}
2208:			}
2209:		}
2210:	
2211:		if (xpad->xtype == XTYPE_XBOX360W) {
2212:			/*
2213:			 * Submit the int URB immediately rather than waiting for open
2214:			 * because we get status messages from the device whether
2215:			 * or not any controllers are attached.  In fact, it's
2216:			 * exactly the message that a controller has arrived that
2217:			 * we're waiting for.
2218:			 */
2219:			error = xpad360w_start_input(xpad);
2220:			if (error)
2221:				goto err_deinit_output;
2222:			/*
2223:			 * Wireless controllers require RESET_RESUME to work properly
2224:			 * after suspend. Ideally this quirk should be in usb core
2225:			 * quirk list, but we have too many vendors producing these
2226:			 * controllers and we'd need to maintain 2 identical lists
2227:			 * here in this driver and in usb core.
2228:			 */
2229:			udev->quirks |= USB_QUIRK_RESET_RESUME;
2230:		} else {
2231:			error = xpad_init_input(xpad);
2232:			if (error)
2233:				goto err_deinit_output;
2234:		}
2235:		return 0;
2236:	
2237:	err_deinit_output:
2238:		xpad_deinit_output(xpad);
2239:	err_free_in_urb:
2240:		usb_free_urb(xpad->irq_in);
2241:	err_free_idata:
2242:		usb_free_coherent(udev, XPAD_PKT_LEN, xpad->idata, xpad->idata_dma);
2243:	err_free_mem:
2244:		kfree(xpad);
2245:		return error;
2246:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 28282
							output: 50
							thoughts: 62
						

**Diving into the Xbox 360 Wireless Controller Input Handling**

Okay, so I'm looking at `xpad_probe`, and the key conditional here is that `xpad->xtype` check. If it's an `XTYPE_XBOX360W`, that's our wireless controller. The code branches to `xpad360w_start_input(xpad)`. Right, that's where the magic probably happens. My next step, naturally, is to examine what's going on *inside* that function. Let's dig into `xpad360w_start_input` and see how it actually handles the initialization and input processing for the wireless version. That's where the critical difference surely lies.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad360w_start_input]

map[SourceCode:1872:	static int xpad360w_start_input(struct usb_xpad *xpad)
1873:	{
1874:		int error;
1875:	
1876:		error = usb_submit_urb(xpad->irq_in, GFP_KERNEL);
1877:		if (error)
1878:			return -EIO;
1879:	
1880:		/*
1881:		 * Send presence packet.
1882:		 * This will force the controller to resend connection packets.
1883:		 * This is useful in the case we activate the module after the
1884:		 * adapter has been plugged in, as it won't automatically
1885:		 * send us info about the controllers.
1886:		 */
1887:		error = xpad_inquiry_pad_presence(xpad);
1888:		if (error) {
1889:			usb_kill_urb(xpad->irq_in);
1890:			return error;
1891:		}
1892:	
1893:		return 0;
1894:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 28904
							output: 50
							thoughts: 98
						

**Analyzing the Xbox 360 Wireless Controller Driver**

Okay, let's break this down. For the `XTYPE_XBOX360W` type, which I know corresponds to the Xbox 360 wireless controller, the input interrupt, `xpad->irq_in`, gets submitted during the `xpad_probe` function. That's where we kick things off. Then, when a device is disconnected, `xpad_disconnect` is called, and the code checks:
```c
	if (xpad->xtype == XTYPE_XBOX360W)
		xpad360w_stop_input(xpad);
```
So, if it *is* an Xbox 360 wireless controller, `xpad360w_stop_input` gets called. Now, I need to understand what this function does. My next step is clearly to dive into the `xpad360w_stop_input` function definition. I need to see how the input stream is managed, specifically how the interrupt submission is reversed or stopped to ensure a clean disconnection.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad360w_stop_input]

map[SourceCode:1896:	static void xpad360w_stop_input(struct usb_xpad *xpad)
1897:	{
1898:		usb_kill_urb(xpad->irq_in);
1899:	
1900:		/* Make sure we are done with presence work if it was scheduled */
1901:		flush_work(&xpad->work);
1902:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 29438
							output: 64
							thoughts: 329
						

**Analyzing the Xbox 360 Wireless Controller Driver Disconnect Logic**

Alright, let's break this down. My immediate concern is how the Xbox 360 Wireless controller driver handles disconnection. The code shows `xpad360w_stop_input` explicitly kills `xpad->irq_in` - that much is clear. But it gets more interesting if the controller *isn't* a 360 Wireless (`xpad->xtype != XTYPE_XBOX360W`). In that scenario, `xpad_disconnect` *bypasses* `xpad360w_stop_input`. Instead, it goes to `xpad_deinit_input`.

`xpad_deinit_input` then calls `input_unregister_device(xpad->dev)` *only* if `xpad->input_created` is true. That seems straightforward. If the device was *opened* beforehand, then `xpad_close` would have been called, and that calls `xpad_stop_input`, which in turn kills `xpad->irq_in`, again. But this raises a flag - if the input device was *created*, but *not* opened, this path is potentially compromised. `xpad_close` wouldn't be invoked! 

Then again, if the device wasn't opened, `xpad_open` would *not* have been called. So `xpad_start_input` never ran, so `xpad->irq_in` was never submitted to begin with! Hmm, wait a minute, I need to confirm: Is there *any* other place where `xpad->irq_in` is submitted? I'm going to scan the codebase for `usb_submit_urb(xpad->irq_in`. I need to ensure there aren't other entry points I'm missing!

map[ContextFile:drivers/input/joystick/xpad.c IncludeSnippetLines:0 Name:usb_submit_urb SourceTreePrefix:drivers/input/joystick/xpad.c]

map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad360w_start_input SourceFile:drivers/input/joystick/xpad.c SourceLine:1876] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad_irq_in SourceFile:drivers/input/joystick/xpad.c SourceLine:1272] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad_irq_out SourceFile:drivers/input/joystick/xpad.c SourceLine:1407] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad_start_input SourceFile:drivers/input/joystick/xpad.c SourceLine:1805] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad_try_sending_next_out_packet SourceFile:drivers/input/joystick/xpad.c SourceLine:1359]] TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 30545
							output: 65
							thoughts: 530
						

**Analyzing USB URB Submission and Handling in the xpad Driver**

Okay, let's break down this `xpad` driver's USB URB management. My initial observation is that `usb_submit_urb` for `irq_in` is called from a few places: `xpad_irq_in`, `xpad_start_input`, and `xpad360w_start_input`. That's the interrupt IN endpoint, presumably for receiving data from the controller. Then there is `xpad_irq_out`, which submits the `xpad->irq_out` URB.

Now, my concern stems from the possible order of operations and potential race conditions. What if we have a scenario where `xpad_start_input` is called, it starts up, then `xpad_stop_input` is called, and finally, `xpad_disconnect` gets invoked? We need to ensure URBs are handled safely during device teardown.

My other concern is if `xpad_start_input` fails – does it properly clean up the `irq_in` URB? Looking at the code:

```c
	if (usb_submit_urb(xpad->irq_in, GFP_KERNEL))
		return -EIO;

	if (xpad->xtype == XTYPE_XBOXONE) {
		error = xpad_start_xbox_one(xpad);
		if (error) {
			usb_kill_urb(xpad->irq_in);
			return error;
		}
	}
```

Okay, so if `usb_submit_urb` *succeeds*, the `irq_in` URB *is* submitted. But if `xpad_start_xbox_one` fails *after* a successful `usb_submit_urb` (specifically the Xbox One implementation), it *does* kill the `irq_in` URB, preventing a leak. Good.

Next, what about `xpad->irq_out`? Where's the teardown for that? In `xpad_disconnect`:

```c
	/*
	 * Now that both input device and LED device are gone we can
	 * stop output URB.
	 */
	xpad_stop_output(xpad);

	xpad_deinit_output(xpad);
```

Okay, `xpad_stop_output` seems important. It does this:

```c
	if (xpad->xtype != XTYPE_UNKNOWN) {
		if (!usb_wait_anchor_empty_timeout(&xpad->irq_out_anchor,
						   5000)) {
			dev_warn(&xpad->intf->dev,
				 "timed out waiting for output URB to complete, killing\n");
			usb_kill_anchored_urbs(&xpad->irq_out_anchor);
		}
	}
```

Aha! `xpad_stop_output` *waits* for `irq_out_anchor` to be empty before killing the URBs. This is usually good. But... what if `xpad->irq_out` isn't anchored to begin with? I need to track down where `xpad->irq_out` gets anchored to fully understand this logic and eliminate the possibility of a use-after-free or double-free vulnerability if a URB is submitted but then the device unloads, which could result in a kernel panic. I'll need to examine where it's anchored and unanchored to complete the analysis.

requested entity does not exist

map[ContextFile:drivers/input/joystick/xpad.c IncludeSnippetLines:0 Name:irq_out_anchor SourceTreePrefix:drivers/input/joystick/xpad.c]

map[References:<nil> TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 31954
							output: 64
							thoughts: 12
						

Okay, here's my take on those thoughts, tailored for an expert audience:

**Investigating `usb_anchor_urb`**

Right, let's dive in. The first thing I'm thinking is, "Okay, `usb_anchor_urb`. That's the starting point." This suggests a pretty specific area of investigation: USB device driver internals, specifically concerning URBs (USB Request Blocks) and their anchoring. My mind immediately flashes to scenarios of managing asynchronous I/O, potential race conditions in USB transfers, and likely interactions with the USB core scheduler. I'm expecting this to lead down a path related to error handling, cancellation, and perhaps even some more advanced power management aspects within the USB subsystem. The "anchor" part implies some form of reference counting, locking, or a mechanism to prevent premature freeing of URBs while they are still active. It's probably worth looking at its interactions with the various USB transfer types (control, interrupt, bulk, isochronous) and how this anchoring is implemented differently across them. The kernel source will be the obvious place to look, but I'll probably also cross-reference relevant documentation and perhaps even some bug reports or mailing list archives to get a sense of its history and known quirks. It's likely involved in the complexities of managing the lifetime of URBs within a multi-threaded, asynchronous USB environment. Time to dig in and see what treasures (or potential landmines) await!

map[ContextFile:drivers/input/joystick/xpad.c IncludeSnippetLines:0 Name:usb_anchor_urb SourceTreePrefix:drivers/input/joystick/xpad.c]

map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad_irq_out SourceFile:drivers/input/joystick/xpad.c SourceLine:1406] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad_try_sending_next_out_packet SourceFile:drivers/input/joystick/xpad.c SourceLine:1358]] TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 32470
							output: 52
							thoughts: 18
						

Okay, let's break this down.

**Diving into `xpad_try_sending_next_out_packet`**

Alright, so I'm thinking about `xpad_try_sending_next_out_packet`. This function is central, obviously, to getting the gamepad data *out* to the device. I need to consider all the nuances involved in the sending process.

I need to quickly assess if there's anything ready to send. Is there a packet queued? Do we have data that's fresh and ready to go, and, if so, does the USB bus even have capacity right now? I know there can be contention and I must deal with the timing of that.

I have to carefully evaluate the state of the USB device. Is it connected? Is it powered? Has it enumerated properly? Any of these issues will result in a failed send, and I need to handle those gracefully—logging the problem, perhaps retrying later, or potentially indicating an error to the user if the problem persists.

I must keep in mind the potential for errors. USB communication can be finicky. I'll need error handling for this specific function. I'll have to consider how to handle retry mechanisms and any potential back-off strategies if the send fails. What about data corruption? I’m thinking integrity checks!

And finally, of course, I have to consider the overall thread context. Am I sending from an interrupt context, or a process context? This will inform how I can safely operate, whether or not to use locks, and whether I can safely call any blocking operations. All these aspects are very important, in the bigger picture of USB driver design, to ensure a solid and reliable connection between the device and the host machine.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_try_sending_next_out_packet]

map[SourceCode:1352:	/* Callers must hold xpad->odata_lock spinlock */
1353:	static int xpad_try_sending_next_out_packet(struct usb_xpad *xpad)
1354:	{
1355:		int error;
1356:	
1357:		if (!xpad->irq_out_active && xpad_prepare_next_out_packet(xpad)) {
1358:			usb_anchor_urb(xpad->irq_out, &xpad->irq_out_anchor);
1359:			error = usb_submit_urb(xpad->irq_out, GFP_ATOMIC);
1360:			if (error) {
1361:				if (error != -ENODEV)
1362:					dev_err(&xpad->intf->dev,
1363:						"%s - usb_submit_urb failed with result %d\n",
1364:						__func__, error);
1365:				usb_unanchor_urb(xpad->irq_out);
1366:				return error;
1367:			}
1368:	
1369:			xpad->irq_out_active = true;
1370:		}
1371:	
1372:		return 0;
1373:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 33294
							output: 47
							thoughts: 45
						

Okay, here's my interpretation of that thought process, from an expert's perspective:

**Debugging an xpad Driver: Interrupt Pins**

Alright, hang on a second. I'm looking at this `xpad` driver, and I've got a mental flag raised. I'm seeing that `xpad->irq_out` is clearly anchored, meaning it's tied down in the initialization somewhere. But, my brain is immediately pinging another question: what about the *other* interrupt, `xpad->irq_in`? That's the critical one for incoming data, and I need to be absolutely sure that's also properly anchored. Is it being handled the same way? Is there any potential for a race condition or an uninitialized value there?

I need to quickly verify that `xpad_irq_in` is being handled and initialized correctly. I need to refresh my memory on how this incoming interrupt is setup. I need to make sure this is being handled the same way as `xpad->irq_out`. I'm going to jump into that function and see what's going on.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_irq_in]

map[SourceCode:1232:	static void xpad_irq_in(struct urb *urb)
1233:	{
1234:		struct usb_xpad *xpad = urb->context;
1235:		struct device *dev = &xpad->intf->dev;
1236:		int retval, status;
1237:	
1238:		status = urb->status;
1239:	
1240:		switch (status) {
1241:		case 0:
1242:			/* success */
1243:			break;
1244:		case -ECONNRESET:
1245:		case -ENOENT:
1246:		case -ESHUTDOWN:
1247:			/* this urb is terminated, clean up */
1248:			dev_dbg(dev, "%s - urb shutting down with status: %d\n",
1249:				__func__, status);
1250:			return;
1251:		default:
1252:			dev_dbg(dev, "%s - nonzero urb status received: %d\n",
1253:				__func__, status);
1254:			goto exit;
1255:		}
1256:	
1257:		switch (xpad->xtype) {
1258:		case XTYPE_XBOX360:
1259:			xpad360_process_packet(xpad, xpad->dev, 0, xpad->idata);
1260:			break;
1261:		case XTYPE_XBOX360W:
1262:			xpad360w_process_packet(xpad, 0, xpad->idata);
1263:			break;
1264:		case XTYPE_XBOXONE:
1265:			xpadone_process_packet(xpad, 0, xpad->idata, urb->actual_length);
1266:			break;
1267:		default:
1268:			xpad_process_packet(xpad, 0, xpad->idata);
1269:		}
1270:	
1271:	exit:
1272:		retval = usb_submit_urb(urb, GFP_ATOMIC);
1273:		if (retval)
1274:			dev_err(dev, "%s - usb_submit_urb failed with result %d\n",
1275:				__func__, retval);
1276:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 34315
							output: 65
							thoughts: 364
						

**Analyzing the USB Xbox Pad Interrupt Handling**

Okay, so I'm digging into this Xbox pad driver. My initial thought is that `xpad_irq_in` is responsible for resubmitting the URB, which is standard procedure. However, a potential race condition or resource leak came to mind immediately. Specifically, the interplay between `xpad_disconnect` and `xpad->irq_in`. I see that `xpad_disconnect` frees the `xpad` structure itself, but critically it *doesn't* kill `xpad->irq_in` *unless* the `xpad->xtype` isn't `XTYPE_XBOX360W`. 

Hold on a second, though. Isn't `xpad->irq_in` killed in `xpad_stop_input`? Yes, it is, and `xpad_stop_input` is called from `xpad_close`. But that brings up the important question: what happens if `xpad_close` *isn't* called? That's the crux of this.

When is `xpad_close` called? Aha, it's called when the input device is closed, which is what I suspected. Okay, so if the device *is* open, `input_unregister_device` will call `xpad_close`, right? Let me confirm... yes, let's trace `input_unregister_device`. Yep, `input_unregister_device` calls `input_disconnect_device`, which in turn calls `dev->close(dev)` if there are open handles. That looks correct.

But, a new problem surfaces. What if the input device was never opened at all, but `xpad->irq_in` was somehow submitted? This is where it gets tricky, I can see a possible bug.

Okay, is there a case where `xpad->irq_in` is submitted *only* within `xpad_start_input`? Now that's the question. Let's think... Yes, it appears so, and `xpad_start_input` is called from `xpad_open`. So, if the device isn't opened, `xpad->irq_in` shouldn't be submitted, *in theory*.

However, is there any other possible place, outside of the normal `xpad_open` workflow, where `xpad_start_input` could be called? I need to be 100% sure, to rule out any subtle vulnerabilities. Let's do a quick search for `xpad_start_input` and double check.

map[ContextFile:drivers/input/joystick/xpad.c IncludeSnippetLines:0 Name:xpad_start_input SourceTreePrefix:drivers/input/joystick/xpad.c]

map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad_open SourceFile:drivers/input/joystick/xpad.c SourceLine:1908] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad_resume SourceFile:drivers/input/joystick/xpad.c SourceLine:2319] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpadone_process_packet SourceFile:drivers/input/joystick/xpad.c SourceLine:1102]] TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 35492
							output: 47
							thoughts: 35
						

Here's my summary, as though I'm thinking through this process:

**Diving into the Xbox Controller Driver**

Okay, so I'm digging into this Xbox controller driver, and I've just hit the crucial part where the data from the controller is actually *processed*. Right, the name itself, `xpadone_process_packet`, that immediately jumps out at me. And just what does this function do? It looks like it's the gateway for handling each data packet. Now, I see that this is where `xpad_start_input` gets called. Now, I should probably delve further into `xpadone_process_packet`. It is the most important piece of the puzzle to look at right now.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpadone_process_packet]

map[SourceCode:1051:	/*
1052:	 *	xpadone_process_packet
1053:	 *
1054:	 *	Completes a request by converting the data into events for the
1055:	 *	input subsystem. This version is for the Xbox One controller.
1056:	 *
1057:	 *	The report format was gleaned from
1058:	 *	https://github.com/kylelemons/xbox/blob/master/xbox.go
1059:	 */
1060:	static void xpadone_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char *data, u32 len)
1061:	{
1062:		struct input_dev *dev = xpad->dev;
1063:		bool do_sync = false;
1064:	
1065:		/* the xbox button has its own special report */
1066:		if (data[0] == GIP_CMD_VIRTUAL_KEY) {
1067:			/*
1068:			 * The Xbox One S controller requires these reports to be
1069:			 * acked otherwise it continues sending them forever and
1070:			 * won't report further mode button events.
1071:			 */
1072:			if (data[1] == (GIP_OPT_ACK | GIP_OPT_INTERNAL))
1073:				xpadone_ack_mode_report(xpad, data[2]);
1074:	
1075:			input_report_key(dev, BTN_MODE, data[4] & GENMASK(1, 0));
1076:			input_sync(dev);
1077:	
1078:			do_sync = true;
1079:		} else if (data[0] == GIP_CMD_FIRMWARE) {
1080:			/* Some packet formats force us to use this separate to poll paddle inputs */
1081:			if (xpad->packet_type == PKT_XBE2_FW_5_11) {
1082:				/* Mute paddles if controller is in a custom profile slot
1083:				 * Checked by looking at the active profile slot to
1084:				 * verify it's the default slot
1085:				 */
1086:				if (data[19] != 0)
1087:					data[18] = 0;
1088:	
1089:				/* Elite Series 2 split packet paddle bits */
1090:				input_report_key(dev, BTN_GRIPR, data[18] & BIT(0));
1091:				input_report_key(dev, BTN_GRIPR2, data[18] & BIT(1));
1092:				input_report_key(dev, BTN_GRIPL, data[18] & BIT(2));
1093:				input_report_key(dev, BTN_GRIPL2, data[18] & BIT(3));
1094:	
1095:				do_sync = true;
1096:			}
1097:		} else if (data[0] == GIP_CMD_ANNOUNCE) {
1098:			int error;
1099:	
1100:			if (xpad->delay_init && !xpad->delayed_init_done) {
1101:				xpad->delayed_init_done = true;
1102:				error = xpad_start_input(xpad);
1103:				if (error)
1104:					dev_warn(&xpad->dev->dev,
1105:						 "unable to start delayed input: %d\n",
1106:						 error);
1107:			}
1108:		} else if (data[0] == GIP_CMD_INPUT) { /* The main valid packet type for inputs */
1109:			/* menu/view buttons */
1110:			input_report_key(dev, BTN_START,  data[4] & BIT(2));
1111:			input_report_key(dev, BTN_SELECT, data[4] & BIT(3));
1112:			if (xpad->mapping & MAP_SHARE_BUTTON) {
1113:				if (xpad->mapping & MAP_SHARE_OFFSET)
1114:					input_report_key(dev, KEY_RECORD, data[len - 26] & BIT(0));
1115:				else
1116:					input_report_key(dev, KEY_RECORD, data[len - 18] & BIT(0));
1117:			}
1118:	
1119:			/* buttons A,B,X,Y */
1120:			input_report_key(dev, BTN_A,	data[4] & BIT(4));
1121:			input_report_key(dev, BTN_B,	data[4] & BIT(5));
1122:			input_report_key(dev, BTN_X,	data[4] & BIT(6));
1123:			input_report_key(dev, BTN_Y,	data[4] & BIT(7));
1124:	
1125:			/* digital pad */
1126:			if (xpad->mapping & MAP_DPAD_TO_BUTTONS) {
1127:				/* dpad as buttons (left, right, up, down) */
1128:				input_report_key(dev, BTN_DPAD_LEFT, data[5] & BIT(2));
1129:				input_report_key(dev, BTN_DPAD_RIGHT, data[5] & BIT(3));
1130:				input_report_key(dev, BTN_DPAD_UP, data[5] & BIT(0));
1131:				input_report_key(dev, BTN_DPAD_DOWN, data[5] & BIT(1));
1132:			} else {
1133:				input_report_abs(dev, ABS_HAT0X,
1134:						!!(data[5] & 0x08) - !!(data[5] & 0x04));
1135:				input_report_abs(dev, ABS_HAT0Y,
1136:						!!(data[5] & 0x02) - !!(data[5] & 0x01));
1137:			}
1138:	
1139:			/* TL/TR */
1140:			input_report_key(dev, BTN_TL,	data[5] & BIT(4));
1141:			input_report_key(dev, BTN_TR,	data[5] & BIT(5));
1142:	
1143:			/* stick press left/right */
1144:			input_report_key(dev, BTN_THUMBL, data[5] & BIT(6));
1145:			input_report_key(dev, BTN_THUMBR, data[5] & BIT(7));
1146:	
1147:			if (!(xpad->mapping & MAP_STICKS_TO_NULL)) {
1148:				/* left stick */
1149:				input_report_abs(dev, ABS_X,
1150:						(__s16) le16_to_cpup((__le16 *)(data + 10)));
1151:				input_report_abs(dev, ABS_Y,
1152:						~(__s16) le16_to_cpup((__le16 *)(data + 12)));
1153:	
1154:				/* right stick */
1155:				input_report_abs(dev, ABS_RX,
1156:						(__s16) le16_to_cpup((__le16 *)(data + 14)));
1157:				input_report_abs(dev, ABS_RY,
1158:						~(__s16) le16_to_cpup((__le16 *)(data + 16)));
1159:			}
1160:	
1161:			/* triggers left/right */
1162:			if (xpad->mapping & MAP_TRIGGERS_TO_BUTTONS) {
1163:				input_report_key(dev, BTN_TL2,
1164:						(__u16) le16_to_cpup((__le16 *)(data + 6)));
1165:				input_report_key(dev, BTN_TR2,
1166:						(__u16) le16_to_cpup((__le16 *)(data + 8)));
1167:			} else {
1168:				input_report_abs(dev, ABS_Z,
1169:						(__u16) le16_to_cpup((__le16 *)(data + 6)));
1170:				input_report_abs(dev, ABS_RZ,
1171:						(__u16) le16_to_cpup((__le16 *)(data + 8)));
1172:			}
1173:	
1174:			/* Profile button has a value of 0-3, so it is reported as an axis */
1175:			if (xpad->mapping & MAP_PROFILE_BUTTON)
1176:				input_report_abs(dev, ABS_PROFILE, data[34]);
1177:	
1178:			/* paddle handling */
1179:			/* based on SDL's SDL_hidapi_xboxone.c */
1180:			if (xpad->mapping & MAP_PADDLES) {
1181:				if (xpad->packet_type == PKT_XBE1) {
1182:					/* Mute paddles if controller has a custom mapping applied.
1183:					 * Checked by comparing the current mapping
1184:					 * config against the factory mapping config
1185:					 */
1186:					if (memcmp(&data[4], &data[18], 2) != 0)
1187:						data[32] = 0;
1188:	
1189:					/* OG Elite Series Controller paddle bits */
1190:					input_report_key(dev, BTN_GRIPR, data[32] & BIT(1));
1191:					input_report_key(dev, BTN_GRIPR2, data[32] & BIT(3));
1192:					input_report_key(dev, BTN_GRIPL, data[32] & BIT(0));
1193:					input_report_key(dev, BTN_GRIPL2, data[32] & BIT(2));
1194:				} else if (xpad->packet_type == PKT_XBE2_FW_OLD) {
1195:					/* Mute paddles if controller has a custom mapping applied.
1196:					 * Checked by comparing the current mapping
1197:					 * config against the factory mapping config
1198:					 */
1199:					if (data[19] != 0)
1200:						data[18] = 0;
1201:	
1202:					/* Elite Series 2 4.x firmware paddle bits */
1203:					input_report_key(dev, BTN_GRIPR, data[18] & BIT(0));
1204:					input_report_key(dev, BTN_GRIPR2, data[18] & BIT(1));
1205:					input_report_key(dev, BTN_GRIPL, data[18] & BIT(2));
1206:					input_report_key(dev, BTN_GRIPL2, data[18] & BIT(3));
1207:				} else if (xpad->packet_type == PKT_XBE2_FW_5_EARLY) {
1208:					/* Mute paddles if controller has a custom mapping applied.
1209:					 * Checked by comparing the current mapping
1210:					 * config against the factory mapping config
1211:					 */
1212:					if (data[23] != 0)
1213:						data[22] = 0;
1214:	
1215:					/* Elite Series 2 5.x firmware paddle bits
1216:					 * (before the packet was split)
1217:					 */
1218:					input_report_key(dev, BTN_GRIPR, data[22] & BIT(0));
1219:					input_report_key(dev, BTN_GRIPR2, data[22] & BIT(1));
1220:					input_report_key(dev, BTN_GRIPL, data[22] & BIT(2));
1221:					input_report_key(dev, BTN_GRIPL2, data[22] & BIT(3));
1222:				}
1223:			}
1224:	
1225:			do_sync = true;
1226:		}
1227:	
1228:		if (do_sync)
1229:			input_sync(dev);
1230:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 39215
							output: 46
							thoughts: 224
						

**Debugging the Xbox One Controller Driver**

Okay, so I'm tracing through this Xbox One controller driver code, and something's bugging me. I see that `xpadone_process_packet` is being called from `xpad_irq_in`, which makes sense for handling incoming interrupt packets. But hang on a second... if `xpad_irq_in` is being called, that implies that `xpad->irq_in` has *already* been submitted to the interrupt queue, right?

Which leads me to: when is `xpad->irq_in` submitted? Has `xpad_start_input` already been called, or is it submitted during `xpad_probe`? My initial assumption is it is submitted in `xpad_start_input`, so this has to be correct.

Now, for the `XTYPE_XBOXONE` case, I need to confirm: Is `xpad->irq_in` *actually* submitted within `xpad_probe`? This seems like the most likely scenario, so I'm going back to check `xpad_probe`. 

Okay, let's refresh our memory of the code. I see a conditional block here. Depending on `xpad->xtype`, there's a fork in the road: either `xpad360w_start_input` is called, or the more generic `xpad_init_input` gets executed. Now, this `xpad360w_start_input` looks specific to the 360 wireless controller. I am interested in the one, so I need to check `xpad_init_input` to see if that's where the submission happens. Let's dig into that next.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_init_input]

map[SourceCode:1958:	static int xpad_init_input(struct usb_xpad *xpad)
1959:	{
1960:		struct input_dev *input_dev;
1961:		int i, error;
1962:	
1963:		input_dev = input_allocate_device();
1964:		if (!input_dev)
1965:			return -ENOMEM;
1966:	
1967:		xpad->dev = input_dev;
1968:		input_dev->name = xpad->name;
1969:		input_dev->phys = xpad->phys;
1970:		usb_to_input_id(xpad->udev, &input_dev->id);
1971:	
1972:		if (xpad->xtype == XTYPE_XBOX360W) {
1973:			/* x360w controllers and the receiver have different ids */
1974:			input_dev->id.product = 0x02a1;
1975:		}
1976:	
1977:		input_dev->dev.parent = &xpad->intf->dev;
1978:	
1979:		input_set_drvdata(input_dev, xpad);
1980:	
1981:		if (xpad->xtype != XTYPE_XBOX360W) {
1982:			input_dev->open = xpad_open;
1983:			input_dev->close = xpad_close;
1984:		}
1985:	
1986:		if (!(xpad->mapping & MAP_STICKS_TO_NULL)) {
1987:			/* set up axes */
1988:			for (i = 0; xpad_abs[i] >= 0; i++)
1989:				xpad_set_up_abs(input_dev, xpad_abs[i]);
1990:		}
1991:	
1992:		/* set up standard buttons */
1993:		for (i = 0; xpad_common_btn[i] >= 0; i++)
1994:			input_set_capability(input_dev, EV_KEY, xpad_common_btn[i]);
1995:	
1996:		/* set up model-specific ones */
1997:		if (xpad->xtype == XTYPE_XBOX360 || xpad->xtype == XTYPE_XBOX360W ||
1998:		    xpad->xtype == XTYPE_XBOXONE) {
1999:			for (i = 0; xpad360_btn[i] >= 0; i++)
2000:				input_set_capability(input_dev, EV_KEY, xpad360_btn[i]);
2001:			if (xpad->mapping & MAP_SHARE_BUTTON)
2002:				input_set_capability(input_dev, EV_KEY, KEY_RECORD);
2003:		} else {
2004:			for (i = 0; xpad_btn[i] >= 0; i++)
2005:				input_set_capability(input_dev, EV_KEY, xpad_btn[i]);
2006:		}
2007:	
2008:		if (xpad->mapping & MAP_DPAD_TO_BUTTONS) {
2009:			for (i = 0; xpad_btn_pad[i] >= 0; i++)
2010:				input_set_capability(input_dev, EV_KEY,
2011:						     xpad_btn_pad[i]);
2012:		}
2013:	
2014:		/* set up paddles if the controller has them */
2015:		if (xpad->mapping & MAP_PADDLES) {
2016:			for (i = 0; xpad_btn_paddles[i] >= 0; i++)
2017:				input_set_capability(input_dev, EV_KEY, xpad_btn_paddles[i]);
2018:		}
2019:	
2020:		/*
2021:		 * This should be a simple else block. However historically
2022:		 * xbox360w has mapped DPAD to buttons while xbox360 did not. This
2023:		 * made no sense, but now we can not just switch back and have to
2024:		 * support both behaviors.
2025:		 */
2026:		if (!(xpad->mapping & MAP_DPAD_TO_BUTTONS) ||
2027:		    xpad->xtype == XTYPE_XBOX360W) {
2028:			for (i = 0; xpad_abs_pad[i] >= 0; i++)
2029:				xpad_set_up_abs(input_dev, xpad_abs_pad[i]);
2030:		}
2031:	
2032:		if (xpad->mapping & MAP_TRIGGERS_TO_BUTTONS) {
2033:			for (i = 0; xpad_btn_triggers[i] >= 0; i++)
2034:				input_set_capability(input_dev, EV_KEY,
2035:						     xpad_btn_triggers[i]);
2036:		} else {
2037:			for (i = 0; xpad_abs_triggers[i] >= 0; i++)
2038:				xpad_set_up_abs(input_dev, xpad_abs_triggers[i]);
2039:		}
2040:	
2041:		/* setup profile button as an axis with 4 possible values */
2042:		if (xpad->mapping & MAP_PROFILE_BUTTON)
2043:			xpad_set_up_abs(input_dev, ABS_PROFILE);
2044:	
2045:		error = xpad_init_ff(xpad);
2046:		if (error)
2047:			goto err_free_input;
2048:	
2049:		error = xpad_led_probe(xpad);
2050:		if (error)
2051:			goto err_destroy_ff;
2052:	
2053:		error = input_register_device(xpad->dev);
2054:		if (error)
2055:			goto err_disconnect_led;
2056:	
2057:		xpad->input_created = true;
2058:		return 0;
2059:	
2060:	err_disconnect_led:
2061:		xpad_led_disconnect(xpad);
2062:	err_destroy_ff:
2063:		input_ff_destroy(input_dev);
2064:	err_free_input:
2065:		input_free_device(input_dev);
2066:		return error;
2067:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 41755
							output: 48
							thoughts: 1167
						

**Analyzing the Xbox One Controller Driver Logic**

Okay, so I'm digging into this `xpad` driver code, and I need to sort out how the Xbox One controller input is handled. First, I noticed something immediately: `xpad_init_input` *doesn't* call `xpad_start_input`. That's a key detail! So for `XTYPE_XBOXONE`, the interrupt URB (`xpad->irq_in`) isn't submitted directly within `xpad_probe`. That seems odd. But, I see that within `xpad_probe`, it calls `xpad_init_input` for all types except `XTYPE_XBOX360W`.

Now, if the interrupt URB isn't initially submitted, how does `xpadone_process_packet` even *get* called from `xpad_irq_in`? Ah, right, `xpad_irq_in` is the *completion handler* for that URB. If the URB isn't submitted, `xpad_irq_in` is never invoked, and therefore `xpadone_process_packet` never runs. So, it *must* be submitted somewhere, right?

Then it hits me! When the device is opened (`xpad_open`), `xpad_start_input` *is* called, and *that* submits `xpad->irq_in`. So, the sequence is: open -> `xpad_start_input` (URB submit) -> URB completes -> `xpad_irq_in` is called, which then invokes `xpadone_process_packet`.

Now, here's where it gets interesting. `xpadone_process_packet` *might* call `xpad_start_input` *again*, specifically when `data[0]` is `GIP_CMD_ANNOUNCE`. And `xpad_start_input` calls `usb_submit_urb` again, and now my intuition goes into overdrive. If that URB is *already* active, wouldn't that call fail with something like `-EBUSY`?

Let me double-check `xpad_start_input` to be absolutely certain... yep, it calls `usb_submit_urb(xpad->irq_in, GFP_KERNEL)`. So, back to the `xpad_open` scenario with `xpad->delay_init` set to true. If that's the case, `xpad_start_input` is called after the device is opened. Okay, the URB is submitted. Then `xpad_irq_in` runs. `xpadone_process_packet` gets called.

And then, if `data[0] == GIP_CMD_ANNOUNCE`, `xpad_start_input` is called *again*. That calls `usb_submit_urb(xpad->irq_in, GFP_KERNEL)` again! But here is where it gets interesting... The URB *isn't* active *at the point* `xpadone_process_packet` is called, because `xpad_irq_in` resubmits the URB at the *end* of the function at the `exit:` label, *after* `xpadone_process_packet` is called.

Okay, let's trace this properly:
1.  `xpad_irq_in` processes the packet, and *then* resubmits the URB at the `exit:` label.
2.  So, at the point `xpadone_process_packet` might call `xpad_start_input` due to the `GIP_CMD_ANNOUNCE`, the URB is *not* active.
3.  Therefore, when `xpad_start_input` is called within the `GIP_CMD_ANNOUNCE` handler, `usb_submit_urb` *will* succeed in submitting the URB.
4. `xpad_start_input` then calls `xpad_start_xbox_one`, but does not seem to submit again.
5. `xpad_irq_in` function will *then* call `usb_submit_urb(urb, GFP_ATOMIC)` *again*, because it did not know that the URB was submitted by the `GIP_CMD_ANNOUNCE` handler.
6. This *second* `usb_submit_urb` *will* fail with `-EBUSY` or similar.

So the potential issue is a failed resubmission of the URB with `usb_submit_urb` in `xpad_irq_in` which means that the error will be

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_start_xbox_one]

map[SourceCode:1503:	static int xpad_start_xbox_one(struct usb_xpad *xpad)
1504:	{
1505:		int error;
1506:	
1507:		if (usb_ifnum_to_if(xpad->udev, GIP_WIRED_INTF_AUDIO)) {
1508:			/*
1509:			 * Explicitly disable the audio interface. This is needed
1510:			 * for some controllers, such as the PowerA Enhanced Wired
1511:			 * Controller for Series X|S (0x20d6:0x200e) to report the
1512:			 * guide button.
1513:			 */
1514:			error = usb_set_interface(xpad->udev,
1515:						  GIP_WIRED_INTF_AUDIO, 0);
1516:			if (error)
1517:				dev_warn(&xpad->dev->dev,
1518:					 "unable to disable audio interface: %d\n",
1519:					 error);
1520:		}
1521:	
1522:		guard(spinlock_irqsave)(&xpad->odata_lock);
1523:	
1524:		/*
1525:		 * Begin the init sequence by attempting to send a packet.
1526:		 * We will cycle through the init packet sequence before
1527:		 * sending any packets from the output ring.
1528:		 */
1529:		xpad->init_seq = 0;
1530:		return xpad_try_sending_next_out_packet(xpad);
1531:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 44472
							output: 47
							thoughts: 1176
						

**Analyzing the Xbox One Controller Driver Crash**

Okay, let's break this down. It seems we're dealing with a use-after-free in the Xbox One controller driver. I see that `xpad_start_xbox_one` calls `xpad_try_sending_next_out_packet`, which submits `xpad->irq_out`. My immediate thought is, when does the input process actually begin?

Now, the input is NOT started in `xpad_probe` for the `XTYPE_XBOXONE` device type. But if `xpad->delay_init` is true, then `xpad_init_input` is called from `xpad_probe`. Then I remember that `xpad_init_input` does *not* call `xpad_start_input`. Ah, but `xpad_start_input` *is* called from `xpad_open`. Okay, so it starts on open. But, what if the device is *never* opened? Then, `xpad->irq_in` is never submitted! And that's where the bug is.

Looking at the crash report again, I see USB submit errors, `-19`, and the KASAN report pointing to a slab-use-after-free, likely in `__usb_hcd_giveback_urb`. The trace includes `dummy_timer` from a dummy HCD, and those submission failures with `-ENODEV` confirm a disconnect. This means URBs were active when the device was disconnected.

For `XTYPE_XBOX360W`, the `irq_in` URB is submitted in `xpad_probe` and killed synchronously in `xpad_disconnect` via `usb_kill_urb`. This is fine. But how about `xpad->irq_out`? In `xpad_disconnect`, `xpad_stop_output` is called which kills it via `usb_kill_anchored_urbs`. It waits, or kills it. But what if it isn't anchored?

I see that `xpad->irq_out` *is* anchored using `usb_anchor_urb` right before submission in `xpad_try_sending_next_out_packet`. Okay, and it's cleared when the URB is handled. So it looks like these are handled, and killed safely in the disconnect process.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_irq_out]

map[SourceCode:1375:	static void xpad_irq_out(struct urb *urb)
1376:	{
1377:		struct usb_xpad *xpad = urb->context;
1378:		struct device *dev = &xpad->intf->dev;
1379:		int status = urb->status;
1380:		int error;
1381:	
1382:		guard(spinlock_irqsave)(&xpad->odata_lock);
1383:	
1384:		switch (status) {
1385:		case 0:
1386:			/* success */
1387:			xpad->irq_out_active = xpad_prepare_next_out_packet(xpad);
1388:			break;
1389:	
1390:		case -ECONNRESET:
1391:		case -ENOENT:
1392:		case -ESHUTDOWN:
1393:			/* this urb is terminated, clean up */
1394:			dev_dbg(dev, "%s - urb shutting down with status: %d\n",
1395:				__func__, status);
1396:			xpad->irq_out_active = false;
1397:			break;
1398:	
1399:		default:
1400:			dev_dbg(dev, "%s - nonzero urb status received: %d\n",
1401:				__func__, status);
1402:			break;
1403:		}
1404:	
1405:		if (xpad->irq_out_active) {
1406:			usb_anchor_urb(urb, &xpad->irq_out_anchor);
1407:			error = usb_submit_urb(urb, GFP_ATOMIC);
1408:			if (error) {
1409:				dev_err(dev,
1410:					"%s - usb_submit_urb failed with result %d\n",
1411:					__func__, error);
1412:				usb_unanchor_urb(urb);
1413:				xpad->irq_out_active = false;
1414:			}
1415:		}
1416:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 46843
							output: 63
							thoughts: 1034
						

**Analyzing a Potential Race Condition in the xpad Driver**

Okay, let's break this down. It seems like we have a potential race condition when the xpad driver is disconnecting. The crucial point here is how the `irq_out` URB is handled during shutdown.

My immediate thought is, `usb_wait_anchor_empty_timeout` is waiting for the anchor to be empty. Fine. But, `xpad_irq_out` takes `xpad->odata_lock`. This is where it gets interesting. If `xpad_irq_out` is running, it might have already unanchored the URB because `usb_hcd_giveback_urb` unanchors it *before* calling the completion handler. Right, `usb_hcd_giveback_urb` unanchors the URB before calling `urb->complete`! So, if `xpad_irq_out` is running, the URB is NOT anchored.

So, if `xpad_stop_output` is called concurrently, `usb_wait_anchor_empty_timeout` will return *immediately* because the anchor is empty! Then `xpad_stop_output` returns, and `xpad_disconnect` proceeds to free `xpad`! But, `xpad_irq_out` is still running! And it's accessing `xpad->odata_lock`! That's a textbook use-after-free scenario.

Let's look more closely at what's happening. `usb_kill_anchored_urbs` kills anchored URBs. But, if the URB is in its completion handler, it's NOT anchored. So, `usb_kill_anchored_urbs` does nothing! That's useless. Remember, `usb_kill_urb` *waits* for the completion handler. But, `xpad_stop_output` doesn't call `usb_kill_urb(xpad->irq_out)`! It only calls `usb_wait_anchor_empty_timeout` and `usb_kill_anchored_urbs`. Why? Why doesn't it just use `usb_kill_urb(xpad->irq_out)`?

Let me review `xpad_stop_output` again.

```c
static void xpad_stop_output(struct usb_xpad *xpad)
{
	if (xpad->xtype != XTYPE_UNKNOWN) {
		if (!usb_wait_anchor_empty_timeout(&xpad->irq_out_anchor,
						   5000)) {
			dev_warn(&xpad->intf->dev,
				 "timed out waiting for output URB to complete, killing\n");
			usb_kill_anchored_urbs(&xpad->irq_out_anchor);
		}
	}
}
```

Okay, if the URB is in the completion handler, the anchor is empty, and `usb_wait_anchor_empty_timeout` returns true (success). So the function will return. Then `xpad_stop_output` returns. Then `xpad_disconnect` calls `xpad_deinit_output`, which then calls `usb_free_urb(xpad->irq_out)`. And *then* `xpad_disconnect` frees `xpad`. But! `xpad_irq_out` is still running! It might try to re-anchor and re-submit the URB, or, at a minimum, try to access `xpad->odata_lock`!

Wait, `xpad_irq_out` *starts* with:

```c
	guard(spinlock_irqsave)(&xpad->odata_lock);
```

If `xpad` is freed, this is a use-after-free! That's definitely the bug. I think `xpad_irq_out` is called by `__usb_hcd_giveback_urb`. Is this it? Let's check `xpad_irq_in` for a similar issue. `xpad_stop_input` calls `usb_kill_urb(xpad->irq_in)`. `usb_kill_urb` waits for the completion handler to finish. So, `xpad_irq_in` is safe. But `xpad_stop_output` *doesn't* use `usb_kill_urb(xpad->irq_out)`! That's the key difference.

Why did they use `usb_wait_anchor_empty_timeout` instead of `usb_kill_urb`? Could it be because `xpad_play_effect` might be submitting

requested entity does not exist

map[ContextFile:drivers/input/joystick/xpad.c IncludeSnippetLines:0 Name:irq_out SourceTreePrefix:drivers/input/joystick/xpad.c]

map[References:<nil> TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 48986
							output: 64
							thoughts: 19
						

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Investigating USB URB Cancellation in xpad.c**

Alright, time to get to work. Seems like we're dealing with a potential USB issue related to the xpad driver. The specific function I need to look into is `usb_kill_urb`. Right, that's the function we use to cancel a USB transfer request. This is the likely area if we are having problems with unresponsive peripherals, unexpected disconnects, or general USB hiccups associated with an Xbox controller. Time to jump into `xpad.c` and hunt it down. I'll probably be looking for its call sites, how it's used, what the URB structure looks like and the contexts in which it's being called. I'm going to pay close attention to the conditions that might trigger these cancellations – could be error handling, device disconnects, or even some form of internal timeout. I suspect there may be a race condition lurking or maybe a problem with proper URB cleanup after a timeout. Hopefully, the surrounding code will shed some light on the design and intent of the developer.

map[ContextFile:drivers/input/joystick/xpad.c IncludeSnippetLines:0 Name:usb_kill_urb SourceTreePrefix:drivers/input/joystick/xpad.c]

map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad360w_start_input SourceFile:drivers/input/joystick/xpad.c SourceLine:1889] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad360w_stop_input SourceFile:drivers/input/joystick/xpad.c SourceLine:1898] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad_start_input SourceFile:drivers/input/joystick/xpad.c SourceLine:1811] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:xpad_stop_input SourceFile:drivers/input/joystick/xpad.c SourceLine:1842]] TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 49563
							output: 46
							thoughts: 634
						

**My Analysis of a Potential Use-After-Free in the xpad Driver**

Okay, let's break this down. It seems we've got a classic use-after-free scenario. The core issue revolves around the `irq_out` URB in the `xpad` driver.  The critical point is that `irq_out` is *never* explicitly killed, except when a timeout occurs in `usb_wait_anchor_empty_timeout`, initiated by `usb_kill_anchored_urbs`.

Here's the problem: The `irq_out` URB is only killed after a timeout. However, if the URB is actively *in* its completion handler, the anchor is effectively empty.  This causes `usb_wait_anchor_empty_timeout` to immediately return, skipping the URB kill. This leads to a race condition.

Wait a second, the completion handler for `xpad_irq_out` might *resubmit* the URB!  If it does, the URB gets re-added to the anchor.  But here's the kicker: `xpad_stop_output` has already returned!  And crucially, `xpad_deinit_output` is called subsequently, which calls `usb_free_urb(xpad->irq_out)`.

Now, `usb_free_urb` *doesn't* actually free the URB immediately; it just decrements the reference count. If the URB is submitted, it still has a reference, therefore it isn't freed. But the crucial thing here is that the `xpad` structure *will* be freed, or at least be on its way to being freed! Then, the `xpad_irq_out` completion handler runs again, and it attempts to access the now-freed `xpad` structure (specifically, the odata_lock). This is a perfect recipe for a use-after-free!

And the KASAN report confirms it, a `slab-use-after-free` specifically in a spinlock! The stack trace strongly suggests this is indeed the completion handler's fault. It seems that `xpad_disconnect` doesn't properly wait for the `xpad_irq_out` completion handler to finish because `usb_wait_anchor_empty_timeout` doesn't account for the completion handler.

So, how to trigger this? We need to get `irq_out` submitted. That happens in either `xpad_start_xbox_one`, which is conditional on `xpad->xtype == XTYPE_XBOXONE` from `xpad_start_input` or in `xpad_play_effect`, called when a force feedback effect is played. Let's look closely at `xpad_play_effect`.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_play_effect]

map[SourceCode:1555:	static int xpad_play_effect(struct input_dev *dev, void *data, struct ff_effect *effect)
1556:	{
1557:		struct usb_xpad *xpad = input_get_drvdata(dev);
1558:		struct xpad_output_packet *packet = &xpad->out_packets[XPAD_OUT_FF_IDX];
1559:		__u16 strong;
1560:		__u16 weak;
1561:	
1562:		if (effect->type != FF_RUMBLE)
1563:			return 0;
1564:	
1565:		strong = effect->u.rumble.strong_magnitude;
1566:		weak = effect->u.rumble.weak_magnitude;
1567:	
1568:		guard(spinlock_irqsave)(&xpad->odata_lock);
1569:	
1570:		switch (xpad->xtype) {
1571:		case XTYPE_XBOX:
1572:			packet->data[0] = 0x00;
1573:			packet->data[1] = 0x06;
1574:			packet->data[2] = 0x00;
1575:			packet->data[3] = strong / 256;	/* left actuator */
1576:			packet->data[4] = 0x00;
1577:			packet->data[5] = weak / 256;	/* right actuator */
1578:			packet->len = 6;
1579:			packet->pending = true;
1580:			break;
1581:	
1582:		case XTYPE_XBOX360:
1583:			packet->data[0] = 0x00;
1584:			packet->data[1] = 0x08;
1585:			packet->data[2] = 0x00;
1586:			packet->data[3] = strong / 256;  /* left actuator? */
1587:			packet->data[4] = weak / 256;	/* right actuator? */
1588:			packet->data[5] = 0x00;
1589:			packet->data[6] = 0x00;
1590:			packet->data[7] = 0x00;
1591:			packet->len = 8;
1592:			packet->pending = true;
1593:			break;
1594:	
1595:		case XTYPE_XBOX360W:
1596:			packet->data[0] = 0x00;
1597:			packet->data[1] = 0x01;
1598:			packet->data[2] = 0x0F;
1599:			packet->data[3] = 0xC0;
1600:			packet->data[4] = 0x00;
1601:			packet->data[5] = strong / 256;
1602:			packet->data[6] = weak / 256;
1603:			packet->data[7] = 0x00;
1604:			packet->data[8] = 0x00;
1605:			packet->data[9] = 0x00;
1606:			packet->data[10] = 0x00;
1607:			packet->data[11] = 0x00;
1608:			packet->len = 12;
1609:			packet->pending = true;
1610:			break;
1611:	
1612:		case XTYPE_XBOXONE:
1613:			packet->data[0] = GIP_CMD_RUMBLE; /* activate rumble */
1614:			packet->data[1] = 0x00;
1615:			packet->data[2] = xpad->odata_serial++;
1616:			packet->data[3] = GIP_PL_LEN(9);
1617:			packet->data[4] = 0x00;
1618:			packet->data[5] = GIP_MOTOR_ALL;
1619:			packet->data[6] = 0x00; /* left trigger */
1620:			packet->data[7] = 0x00; /* right trigger */
1621:			packet->data[8] = strong / 512;	/* left actuator */
1622:			packet->data[9] = weak / 512;	/* right actuator */
1623:			packet->data[10] = 0xFF; /* on period */
1624:			packet->data[11] = 0x00; /* off period */
1625:			packet->data[12] = 0xFF; /* repeat count */
1626:			packet->len = 13;
1627:			packet->pending = true;
1628:			break;
1629:	
1630:		default:
1631:			dev_dbg(&xpad->dev->dev,
1632:				"%s - rumble command sent to unsupported xpad type: %d\n",
1633:				__func__, xpad->xtype);
1634:			return -EINVAL;
1635:		}
1636:	
1637:		return xpad_try_sending_next_out_packet(xpad);
1638:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 52361
							output: 46
							thoughts: 1092
						

**Analyzing the XPAD Driver's Potential Use-After-Free Vulnerability**

Okay, let's break this down. My initial thought was that the issue boils down to `xpad_play_effect` and `xpad_start_xbox_one` both submitting `irq_out`. `xpad_start_xbox_one` gets triggered by `xpad_start_input`, which in turn is called from `xpad_open`. So, if the input device is opened when the device type (`xpad->xtype`) is `XTYPE_XBOXONE`, then we’re going to get an `irq_out` submission.

However, `xpad_probe` doesn't directly call `xpad_start_input` for `XTYPE_XBOXONE`. It's `xpad_init_input` that registers the input device, and then syzkaller opens it, which then calls `xpad_open`. `xpad_open` kicks off `xpad_start_input` which leads to `xpad_start_xbox_one` submitting `irq_out`. Then, the device gets disconnected.

Here’s where it gets interesting: `xpad_disconnect` calls `xpad_stop_output`, and if `irq_out` is currently in its completion handler, `usb_wait_anchor_empty_timeout` returns immediately. Then, `xpad_disconnect` frees `xpad`.  Boom, the completion handler `xpad_irq_out` accesses `xpad->odata_lock` and we've got a use-after-free!

My first thought was, "Is `xpad_irq_in` also affected?" Thankfully, I've got that covered!  `xpad_stop_input` calls `usb_kill_urb(xpad->irq_in)`. This function waits for the completion handler to finish. So, `xpad_irq_in` *shouldn't* be affected. Good.

But then I see in the crash report:

```
xpad 1-1:179.65: xpad_irq_in - usb_submit_urb failed with result -19
xpad 1-1:179.65: xpad_irq_out - usb_submit_urb failed with result -19
```

This *strongly* suggests that *both* `xpad_irq_in` and `xpad_irq_out` were running and failed to resubmit. I was expecting `xpad_irq_in` to be properly handled. I remember how `xpad_disconnect` calls `xpad_deinit_input`, which then calls `input_unregister_device`. If the device *was* open, `input_unregister_device` calls `xpad_close`, which calls `xpad_stop_input`, which then calls `usb_kill_urb(xpad->irq_in)`.  But... what if the device *wasn't* opened?  If the device wasn't opened, `xpad_close` doesn't get called. However, if the device wasn't open, `xpad_start_input` never gets called to start the `irq_in`, so this logic works.

Then, I thought, "What if `xpad->xtype == XTYPE_XBOX360W`?" In this case, `xpad360w_start_input` *is* called from `xpad_probe`. Then, `xpad_disconnect` calls `xpad360w_stop_input`, which *also* calls `usb_kill_urb(xpad->irq_in)`. So in this case, `irq_in` is killed correctly.

Let's look at `XTYPE_XBOXONE` again.  `xpadone_process_packet` is called from `xpad_irq_in`.  Crucially, it calls `xpad_start_input` *only if* `data[0] == GIP_CMD_ANNOUNCE` *and* `xpad->delay_init` is true! If `irq_in` isn't submitted, `xpad_irq_in` is NEVER called! Therefore, `xpadone_process_packet` and `xpad_start_input` *are* NEVER called in that specific scenario.

So, I had to ask myself if there was ANY other way `irq_in` is submitted? I went back to `xpad_probe` again.

```c
	if (xpad->xtype ==

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_led_probe]

map[SourceCode:1743:	static int xpad_led_probe(struct usb_xpad *xpad)
1744:	{
1745:		struct xpad_led *led;
1746:		struct led_classdev *led_cdev;
1747:		int error;
1748:	
1749:		if (xpad->xtype != XTYPE_XBOX360 && xpad->xtype != XTYPE_XBOX360W)
1750:			return 0;
1751:	
1752:		xpad->led = led = kzalloc_obj(*led);
1753:		if (!led)
1754:			return -ENOMEM;
1755:	
1756:		xpad->pad_nr = ida_alloc(&xpad_pad_seq, GFP_KERNEL);
1757:		if (xpad->pad_nr < 0) {
1758:			error = xpad->pad_nr;
1759:			goto err_free_mem;
1760:		}
1761:	
1762:		snprintf(led->name, sizeof(led->name), "xpad%d", xpad->pad_nr);
1763:		led->xpad = xpad;
1764:	
1765:		led_cdev = &led->led_cdev;
1766:		led_cdev->name = led->name;
1767:		led_cdev->brightness_set = xpad_led_set;
1768:		led_cdev->flags = LED_CORE_SUSPENDRESUME;
1769:	
1770:		error = led_classdev_register(&xpad->udev->dev, led_cdev);
1771:		if (error)
1772:			goto err_free_id;
1773:	
1774:		xpad_identify_controller(xpad);
1775:	
1776:		return 0;
1777:	
1778:	err_free_id:
1779:		ida_free(&xpad_pad_seq, xpad->pad_nr);
1780:	err_free_mem:
1781:		kfree(led);
1782:		xpad->led = NULL;
1783:		return error;
1784:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 55188
							output: 46
							thoughts: 17
						

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Analyzing the xpad Driver's LED Probe**

Alright, let's break this down. `xpad_led_probe` is being triggered, and I need to figure out the controller's LED capabilities. Makes sense. The logical next step, as I would expect to see, is a call to `xpad_identify_controller`. This is the core of the identification process. So, `xpad_led_probe` likely needs to know *what* kind of controller it's dealing with before it can intelligently control any LEDs, right? It makes me think that `xpad_identify_controller` is likely where the magic happens, maybe reading some USB descriptors, checking vendor/product IDs against a known database, or maybe even sending some initial commands to get the device to identify itself. The LEDs would be configured based on the controller, so knowing the hardware is vital. So far, so good. This flow makes logical sense from a driver's standpoint. I would expect `xpad_identify_controller` to populate a structure of capabilities for that device. Then, in `xpad_led_probe`, it would interrogate that structure, and then the LED functions, based on that information.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_identify_controller]

map[SourceCode:1725:	/*
1726:	 * Light up the segment corresponding to the pad number on
1727:	 * Xbox 360 Controllers.
1728:	 */
1729:	static void xpad_identify_controller(struct usb_xpad *xpad)
1730:	{
1731:		led_set_brightness(&xpad->led->led_cdev, (xpad->pad_nr % 4) + 2);
1732:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 55687
							output: 46
							thoughts: 16
						

Here's my understanding of the situation, tailored for an expert like yourself:

**Led Brightness Control Analysis**

Okay, so I see that `led_set_brightness` is the function that handles brightness adjustments, and it's calling `xpad_led_set` internally. From a functional perspective, this tells me that `led_set_brightness` is likely the public-facing API for controlling the LEDs, while `xpad_led_set` is the lower-level function that actually interacts with the hardware or the device driver. I'd expect `led_set_brightness` to handle things like range checking on the brightness value and potentially any necessary scaling or translation of the input before passing it along to `xpad_led_set`. The naming convention strongly suggests `xpad_led_set` is specific to an Xpad device. This modular design is good - separation of concerns, easy to change `xpad_led_set` without affecting the API for the rest of the system. I will need to delve deeper into each function to fully understand the flow of control and potential issues.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_led_set]

map[SourceCode:1734:	static void xpad_led_set(struct led_classdev *led_cdev,
1735:				 enum led_brightness value)
1736:	{
1737:		struct xpad_led *xpad_led = container_of(led_cdev,
1738:							 struct xpad_led, led_cdev);
1739:	
1740:		xpad_send_led_command(xpad_led->xpad, value);
1741:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 56150
							output: 48
							thoughts: 18
						

Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person:

**Analyzing the xpad_send_led_command Function**

Right, so `xpad_send_led_command`... it's submitting `irq_out`. That's the key takeaway, isn't it? The immediate implication is that this function is how we're driving the LEDs, which is pretty standard for XInput devices. It's almost certain this is where the LED commands, whatever their encoding, are being enqueued for transmission. This also tells me that `irq_out` likely represents the output interrupt or the queue that feeds it, or potentially a similar mechanism to signal the need to transmit data. We're looking at a direct path from the LED command encoding within `xpad_send_led_command` directly to, for example, a USB write. I'd be looking closely now at the data structures associated with `irq_out` -- what's the actual format being sent? Is this a simple FIFO, a more complex circular buffer? Are there any synchronization primitives involved? Furthermore, I'd want to check how the interrupt is actually handled. What's the context? What happens if the write fails or the FIFO is full? What is the overall buffering strategy? The performance bottleneck here could be either on the command encoding, enqueuing/dequeueing or the USB transmit itself, and understanding the role of `irq_out` helps me understand where to look. In a broader context, how does this fit with the overall power management scheme? Does this contribute to device wakeups or interrupts?

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_send_led_command]

map[SourceCode:1666:	/*
1667:	 * set the LEDs on Xbox 360 / Wireless Controllers
1668:	 * @param command
1669:	 *  0: off
1670:	 *  1: all blink, then previous setting
1671:	 *  2: 1/top-left blink, then on
1672:	 *  3: 2/top-right blink, then on
1673:	 *  4: 3/bottom-left blink, then on
1674:	 *  5: 4/bottom-right blink, then on
1675:	 *  6: 1/top-left on
1676:	 *  7: 2/top-right on
1677:	 *  8: 3/bottom-left on
1678:	 *  9: 4/bottom-right on
1679:	 * 10: rotate
1680:	 * 11: blink, based on previous setting
1681:	 * 12: slow blink, based on previous setting
1682:	 * 13: rotate with two lights
1683:	 * 14: persistent slow all blink
1684:	 * 15: blink once, then previous setting
1685:	 */
1686:	static void xpad_send_led_command(struct usb_xpad *xpad, int command)
1687:	{
1688:		struct xpad_output_packet *packet =
1689:				&xpad->out_packets[XPAD_OUT_LED_IDX];
1690:	
1691:		command %= 16;
1692:	
1693:		guard(spinlock_irqsave)(&xpad->odata_lock);
1694:	
1695:		switch (xpad->xtype) {
1696:		case XTYPE_XBOX360:
1697:			packet->data[0] = 0x01;
1698:			packet->data[1] = 0x03;
1699:			packet->data[2] = command;
1700:			packet->len = 3;
1701:			packet->pending = true;
1702:			break;
1703:	
1704:		case XTYPE_XBOX360W:
1705:			packet->data[0] = 0x00;
1706:			packet->data[1] = 0x00;
1707:			packet->data[2] = 0x08;
1708:			packet->data[3] = 0x40 + command;
1709:			packet->data[4] = 0x00;
1710:			packet->data[5] = 0x00;
1711:			packet->data[6] = 0x00;
1712:			packet->data[7] = 0x00;
1713:			packet->data[8] = 0x00;
1714:			packet->data[9] = 0x00;
1715:			packet->data[10] = 0x00;
1716:			packet->data[11] = 0x00;
1717:			packet->len = 12;
1718:			packet->pending = true;
1719:			break;
1720:		}
1721:	
1722:		xpad_try_sending_next_out_packet(xpad);
1723:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 57545
							output: 44
							thoughts: 1196
						

**Bug Analysis: Xbox 360 Wireless Controller Use-After-Free**

Okay, let's break this down. It seems the problem stems from a race condition during the disconnection of an Xbox 360 Wireless controller, specifically a use-after-free vulnerability.  Let me walk through my thought process.

First, I see that `xpad_led_probe` is called from `xpad_init_input`, which in turn comes from `xpad_probe`. That's where the initial setup happens.  Crucially, `xpad_led_probe` is responsible for sending commands via `xpad_send_led_command`, which leads to `xpad_try_sending_next_out_packet` and finally, submitting `irq_out`.  I've found something interesting. For `XTYPE_XBOX360` and `XTYPE_XBOX360W` controllers, this `irq_out` is submitted *during the probe itself*!  That's a key detail.

Now, if the device is disconnected, `xpad_disconnect` gets called.  That calls `xpad_stop_output`. Now, if `irq_out` is currently in its completion handler, `xpad_stop_output` immediately returns, which allows the code to then free the `xpad` structure. And, it appears, that completion handler then tries to access `xpad->odata_lock`, which would cause a use-after-free.

But the crash report shows errors:
```
xpad 1-1:179.65: xpad_irq_in - usb_submit_urb failed with result -19
xpad 1-1:179.65: xpad_irq_out - usb_submit_urb failed with result -19
```
This means both `irq_in` and `irq_out` were active during the disconnection process.

For `XTYPE_XBOX360W`, `irq_in` is submitted in `xpad_probe` through `xpad360w_start_input`, and `irq_out` is submitted in `xpad_probe` through `xpad_led_probe`. Both are launched DURING probe!  When disconnecting, `xpad_disconnect` calls `xpad360w_stop_input`, which calls `usb_kill_urb(xpad->irq_in)`.  But `usb_kill_urb` waits for `irq_in` to finish, so the completion handler can be scheduled after freeing the `xpad` structure.

It's clear, `xpad_irq_in` prints the message BEFORE `usb_kill_urb` returns. Since `usb_kill_urb` waits, this means the `xpad_irq_in` completes first, before the `xpad` is freed.  Crucially, `xpad_irq_out` is *not* killed by `usb_kill_urb`!  `xpad_stop_output` calls `usb_wait_anchor_empty_timeout(&xpad->irq_out_anchor, 5000)`.  If `xpad_irq_out` is running, then the URB isn't anchored, and `usb_wait_anchor_empty_timeout` returns immediately. Then, `xpad_stop_output` returns, and `xpad_disconnect` frees the `xpad` struct. Then, the completion handler for `irq_out` accesses `xpad->odata_lock` which leads to our use-after-free!

So, the root cause is crystal clear now:

1.  We have an Xbox 360 Wireless controller (`XTYPE_XBOX360W`).
2.  `xpad_probe` submits both `irq_in` and `irq_out`.
3.  We disconnect the controller *while `irq_out` is completing*. This is the race condition.

The tricky part will be reliably triggering this race. `irq_out` likely completes very quickly. I'm thinking about how to precisely time the completion of that URB so that it coincides with `xpad_disconnect` freeing the structure. Syzkaller's `dummy_hcd` might be the answer, since it allows for controlling USB URB completion times. If we can rapidly connect and disconnect, we might hit it.

An alternative is to investigate `XTYPE_XBOXONE`. For that device, `irq_in` isn't submitted during probe. But `xpad_start_xbox_one` does submit `ir

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_device]

map[SourceCode: 126:	static const struct xpad_device {
 127:		u16 idVendor;
 128:		u16 idProduct;
 129:		char *name;
 130:		u8 mapping;
 131:		u8 xtype;
 132:		u8 flags;
 133:	} xpad_device[] = {
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 59945
							output: 22
							thoughts: 13
						

Okay, here's my take on those thoughts, tailored for an expert audience:

**Examining `xpad_device` Entries**

Alright, let's dive in. My mind immediately goes to the `xpad_device` structure. It's the core, right? The nexus of interaction with that specific hardware. I need to get a handle on what's currently being managed in there. My initial thought is to inspect the current entries, see what's instantiated, and maybe understand the state of any particular device. Are we talking about a single XInput device or a whole array? Is the enumeration process behaving as expected? What's the driver's current relationship with the hardware – is it connected, partially initialized, or in an error state? I'm looking for clues about the current interaction of the `xpad_device` with the USB subsystem or HID layer, potentially related to the specific model that's connected.

map[Expression:XTYPE_XBOX360]

map[Output:drivers/input/joystick/xpad.c-91-#define XTYPE_XBOX        0
drivers/input/joystick/xpad.c:92:#define XTYPE_XBOX360     1
drivers/input/joystick/xpad.c:93:#define XTYPE_XBOX360W    2
drivers/input/joystick/xpad.c-94-#define XTYPE_XBOXONE     3
--
drivers/input/joystick/xpad.c=126=static const struct xpad_device {
--
drivers/input/joystick/xpad.c-134-	/* Please keep this list sorted by vendor and product ID. */
drivers/input/joystick/xpad.c:135:	{ 0x0079, 0x18d4, "GPD Win 2 X-Box Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:136:	{ 0x0351, 0x1000, "CRKD LP Blueberry Burst Pro Edition (Xbox)", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:137:	{ 0x0351, 0x2000, "CRKD LP Black Tribal Edition (Xbox) ", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:138:	{ 0x03eb, 0xff01, "Wooting One (Legacy)", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:139:	{ 0x03eb, 0xff02, "Wooting Two (Legacy)", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:140:	{ 0x03f0, 0x038D, "HyperX Clutch", 0, XTYPE_XBOX360 },			/* wired */
drivers/input/joystick/xpad.c:141:	{ 0x03f0, 0x048D, "HyperX Clutch", 0, XTYPE_XBOX360 },			/* wireless */
drivers/input/joystick/xpad.c-142-	{ 0x03f0, 0x0495, "HyperX Clutch Gladiate", 0, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-149-	{ 0x044f, 0x0f10, "Thrustmaster Modena GT Wheel", 0, XTYPE_XBOX },
drivers/input/joystick/xpad.c:150:	{ 0x044f, 0xb326, "Thrustmaster Gamepad GP XID", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-151-	{ 0x044f, 0xd01e, "ThrustMaster, Inc. ESWAP X 2 ELDEN RING EDITION", 0, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-156-	{ 0x045e, 0x0289, "Microsoft X-Box pad v2 (US)", 0, XTYPE_XBOX },
drivers/input/joystick/xpad.c:157:	{ 0x045e, 0x028e, "Microsoft X-Box 360 pad", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:158:	{ 0x045e, 0x028f, "Microsoft X-Box 360 pad v2", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:159:	{ 0x045e, 0x0291, "Xbox 360 Wireless Receiver (XBOX)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
drivers/input/joystick/xpad.c:160:	{ 0x045e, 0x02a9, "Xbox 360 Wireless Receiver (Unofficial)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
drivers/input/joystick/xpad.c-161-	{ 0x045e, 0x02d1, "Microsoft X-Box One pad", 0, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-164-	{ 0x045e, 0x02ea, "Microsoft X-Box One S pad", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:165:	{ 0x045e, 0x0719, "Xbox 360 Wireless Receiver", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
drivers/input/joystick/xpad.c-166-	{ 0x045e, 0x0b00, "Microsoft X-Box One Elite 2 pad", MAP_PADDLES, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-168-	{ 0x045e, 0x0b12, "Microsoft Xbox Series S|X Controller", MAP_SHARE_BUTTON | MAP_SHARE_OFFSET, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:169:	{ 0x046d, 0xc21d, "Logitech Gamepad F310", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:170:	{ 0x046d, 0xc21e, "Logitech Gamepad F510", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:171:	{ 0x046d, 0xc21f, "Logitech Gamepad F710", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:172:	{ 0x046d, 0xc242, "Logitech Chillstream Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-173-	{ 0x046d, 0xca84, "Logitech Xbox Cordless Controller", 0, XTYPE_XBOX },
--
drivers/input/joystick/xpad.c-175-	{ 0x046d, 0xca8a, "Logitech Precision Vibration Feedback Wheel", 0, XTYPE_XBOX },
drivers/input/joystick/xpad.c:176:	{ 0x046d, 0xcaa3, "Logitech DriveFx Racing Wheel", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:177:	{ 0x0502, 0x1305, "Acer NGR200", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:178:	{ 0x056e, 0x2004, "Elecom JC-U3613M", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-179-	{ 0x05fd, 0x1007, "Mad Catz Controller (unverified)", 0, XTYPE_XBOX },
--
drivers/input/joystick/xpad.c-186-	{ 0x06a3, 0x0201, "Saitek Adrenalin", 0, XTYPE_XBOX },
drivers/input/joystick/xpad.c:187:	{ 0x06a3, 0xf51a, "Saitek P3600", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-188-	{ 0x0738, 0x4503, "Mad Catz Racing Wheel", 0, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-200-	{ 0x0738, 0x45ff, "Mad Catz Beat Pad (w/ Handle)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
drivers/input/joystick/xpad.c:201:	{ 0x0738, 0x4716, "Mad Catz Wired Xbox 360 Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:202:	{ 0x0738, 0x4718, "Mad Catz Street Fighter IV FightStick SE", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:203:	{ 0x0738, 0x4726, "Mad Catz Xbox 360 Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:204:	{ 0x0738, 0x4728, "Mad Catz Street Fighter IV FightPad", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:205:	{ 0x0738, 0x4736, "Mad Catz MicroCon Gamepad", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:206:	{ 0x0738, 0x4738, "Mad Catz Wired Xbox 360 Controller (SFIV)", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:207:	{ 0x0738, 0x4740, "Mad Catz Beat Pad", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-208-	{ 0x0738, 0x4743, "Mad Catz Beat Pad Pro", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
drivers/input/joystick/xpad.c:209:	{ 0x0738, 0x4758, "Mad Catz Arcade Game Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-210-	{ 0x0738, 0x4a01, "Mad Catz FightStick TE 2", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c-211-	{ 0x0738, 0x6040, "Mad Catz Beat Pad Pro", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
drivers/input/joystick/xpad.c:212:	{ 0x0738, 0x9871, "Mad Catz Portable Drum", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:213:	{ 0x0738, 0xb726, "Mad Catz Xbox controller - MW2", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:214:	{ 0x0738, 0xb738, "Mad Catz MVC2TE Stick 2", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:215:	{ 0x0738, 0xbeef, "Mad Catz JOYTECH NEO SE Advanced GamePad", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:216:	{ 0x0738, 0xcb02, "Saitek Cyborg Rumble Pad - PC/Xbox 360", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:217:	{ 0x0738, 0xcb03, "Saitek P3200 Rumble Pad - PC/Xbox 360", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:218:	{ 0x0738, 0xcb29, "Saitek Aviator Stick AV8R02", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:219:	{ 0x0738, 0xf738, "Super SFIV FightStick TE S", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:220:	{ 0x07ff, 0xffff, "Mad Catz GamePad", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-221-	{ 0x0b05, 0x1a38, "ASUS ROG RAIKIRI", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-230-	{ 0x0d2f, 0x0002, "Andamiro Pump It Up pad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
drivers/input/joystick/xpad.c:231:	{ 0x0db0, 0x1901, "Micro Star International Xbox360 Controller for Windows", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-232-	{ 0x0e4c, 0x1097, "Radica Gamester Controller", 0, XTYPE_XBOX },
--
drivers/input/joystick/xpad.c-239-	{ 0x0e6f, 0x0008, "After Glow Pro Controller", 0, XTYPE_XBOX },
drivers/input/joystick/xpad.c:240:	{ 0x0e6f, 0x0105, "HSM3 Xbox360 dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:241:	{ 0x0e6f, 0x0113, "Afterglow AX.1 Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:242:	{ 0x0e6f, 0x011f, "Rock Candy Gamepad Wired Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:243:	{ 0x0e6f, 0x0131, "PDP EA Sports Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:244:	{ 0x0e6f, 0x0133, "Xbox 360 Wired Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-245-	{ 0x0e6f, 0x0139, "Afterglow Prismatic Wired Controller", 0, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-255-	{ 0x0e6f, 0x0165, "PDP Titanfall 2", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:256:	{ 0x0e6f, 0x0201, "Pelican PL-3601 'TSZ' Wired Xbox 360 Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:257:	{ 0x0e6f, 0x0213, "Afterglow Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:258:	{ 0x0e6f, 0x021f, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-259-	{ 0x0e6f, 0x0246, "Rock Candy Gamepad for Xbox One 2015", 0, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-270-	{ 0x0e6f, 0x02b8, "Afterglow Prismatic Wired Controller", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:271:	{ 0x0e6f, 0x0301, "Logic3 Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-272-	{ 0x0e6f, 0x0346, "Rock Candy Gamepad for Xbox One 2016", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:273:	{ 0x0e6f, 0x0401, "Logic3 Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:274:	{ 0x0e6f, 0x0413, "Afterglow AX.1 Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:275:	{ 0x0e6f, 0x0501, "PDP Xbox 360 Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:276:	{ 0x0e6f, 0xf900, "PDP Afterglow AX.1", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-277-	{ 0x0e8f, 0x0201, "SmartJoy Frag Xpad/PS2 adaptor", 0, XTYPE_XBOX },
drivers/input/joystick/xpad.c-278-	{ 0x0e8f, 0x3008, "Generic xbox control (dealextreme)", 0, XTYPE_XBOX },
drivers/input/joystick/xpad.c:279:	{ 0x0f0d, 0x000a, "Hori Co. DOA4 FightStick", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:280:	{ 0x0f0d, 0x000c, "Hori PadEX Turbo", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:281:	{ 0x0f0d, 0x000d, "Hori Fighting Stick EX2", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:282:	{ 0x0f0d, 0x0016, "Hori Real Arcade Pro.EX", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:283:	{ 0x0f0d, 0x001b, "Hori Real Arcade Pro VX", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-284-	{ 0x0f0d, 0x0063, "Hori Real Arcade Pro Hayabusa (USA) Xbox One", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-287-	{ 0x0f0d, 0x00c5, "Hori Fighting Commander ONE", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:288:	{ 0x0f0d, 0x00dc, "HORIPAD FPS for Nintendo Switch", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-289-	{ 0x0f0d, 0x0151, "Hori Racing Wheel Overdrive for Xbox Series X", 0, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-295-	{ 0x102c, 0xff0c, "Joytech Wireless Advanced Controller", 0, XTYPE_XBOX },
drivers/input/joystick/xpad.c:296:	{ 0x1038, 0x1430, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:297:	{ 0x1038, 0x1431, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-298-	{ 0x10f5, 0x7005, "Turtle Beach Recon Controller", 0, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-300-	{ 0x10f5, 0x7073, "Turtle Beach Stealth Ultra Controller", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:301:	{ 0x11c9, 0x55f0, "Nacon GC-100XF", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:302:	{ 0x11ff, 0x0511, "PXN V900", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:303:	{ 0x1209, 0x2882, "Ardwiino Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:304:	{ 0x12ab, 0x0004, "Honey Bee Xbox360 dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:305:	{ 0x12ab, 0x0301, "PDP AFTERGLOW AX.1", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:306:	{ 0x12ab, 0x0303, "Mortal Kombat Klassic FightStick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-307-	{ 0x12ab, 0x8809, "Xbox DDR dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
drivers/input/joystick/xpad.c:308:	{ 0x1430, 0x4748, "RedOctane Guitar Hero X-plorer", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-309-	{ 0x1430, 0x8888, "TX6500+ Dance Pad (first generation)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
drivers/input/joystick/xpad.c:310:	{ 0x1430, 0xf801, "RedOctane Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:311:	{ 0x146b, 0x0601, "BigBen Interactive XBOX 360 Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:312:	{ 0x146b, 0x0604, "Bigben Interactive DAIJA Arcade Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-313-	{ 0x1532, 0x0a00, "Razer Atrox Arcade Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-315-	{ 0x1532, 0x0a29, "Razer Wolverine V2", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:316:	{ 0x1532, 0x0a57, "Razer Wolverine V3 Pro (Wired)", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:317:	{ 0x1532, 0x0a59, "Razer Wolverine V3 Pro (2.4 GHz Dongle)", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:318:	{ 0x15e4, 0x3f00, "Power A Mini Pro Elite", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:319:	{ 0x15e4, 0x3f0a, "Xbox Airflo wired controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:320:	{ 0x15e4, 0x3f10, "Batarang Xbox 360 controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:321:	{ 0x162e, 0xbeef, "Joytech Neo-Se Take2", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:322:	{ 0x1689, 0xfd00, "Razer Onza Tournament Edition", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:323:	{ 0x1689, 0xfd01, "Razer Onza Classic Edition", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:324:	{ 0x1689, 0xfe00, "Razer Sabertooth", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:325:	{ 0x17ef, 0x6182, "Lenovo Legion Controller for Windows", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:326:	{ 0x1949, 0x041a, "Amazon Game Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:327:	{ 0x1a86, 0xe310, "Legion Go S", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:328:	{ 0x1bad, 0x0002, "Harmonix Rock Band Guitar", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:329:	{ 0x1bad, 0x0003, "Harmonix Rock Band Drumkit", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:330:	{ 0x1bad, 0x0130, "Ion Drum Rocker", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:331:	{ 0x1bad, 0xf016, "Mad Catz Xbox 360 Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:332:	{ 0x1bad, 0xf018, "Mad Catz Street Fighter IV SE Fighting Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:333:	{ 0x1bad, 0xf019, "Mad Catz Brawlstick for Xbox 360", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:334:	{ 0x1bad, 0xf021, "Mad Cats Ghost Recon FS GamePad", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:335:	{ 0x1bad, 0xf023, "MLG Pro Circuit Controller (Xbox)", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:336:	{ 0x1bad, 0xf025, "Mad Catz Call Of Duty", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:337:	{ 0x1bad, 0xf027, "Mad Catz FPS Pro", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:338:	{ 0x1bad, 0xf028, "Street Fighter IV FightPad", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:339:	{ 0x1bad, 0xf02e, "Mad Catz Fightpad", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:340:	{ 0x1bad, 0xf030, "Mad Catz Xbox 360 MC2 MicroCon Racing Wheel", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:341:	{ 0x1bad, 0xf036, "Mad Catz MicroCon GamePad Pro", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:342:	{ 0x1bad, 0xf038, "Street Fighter IV FightStick TE", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:343:	{ 0x1bad, 0xf039, "Mad Catz MvC2 TE", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:344:	{ 0x1bad, 0xf03a, "Mad Catz SFxT Fightstick Pro", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:345:	{ 0x1bad, 0xf03d, "Street Fighter IV Arcade Stick TE - Chun Li", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:346:	{ 0x1bad, 0xf03e, "Mad Catz MLG FightStick TE", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:347:	{ 0x1bad, 0xf03f, "Mad Catz FightStick SoulCaliber", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:348:	{ 0x1bad, 0xf042, "Mad Catz FightStick TES+", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:349:	{ 0x1bad, 0xf080, "Mad Catz FightStick TE2", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:350:	{ 0x1bad, 0xf501, "HoriPad EX2 Turbo", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:351:	{ 0x1bad, 0xf502, "Hori Real Arcade Pro.VX SA", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:352:	{ 0x1bad, 0xf503, "Hori Fighting Stick VX", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:353:	{ 0x1bad, 0xf504, "Hori Real Arcade Pro. EX", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:354:	{ 0x1bad, 0xf505, "Hori Fighting Stick EX2B", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:355:	{ 0x1bad, 0xf506, "Hori Real Arcade Pro.EX Premium VLX", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:356:	{ 0x1bad, 0xf900, "Harmonix Xbox 360 Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:357:	{ 0x1bad, 0xf901, "Gamestop Xbox 360 Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:358:	{ 0x1bad, 0xf903, "Tron Xbox 360 controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:359:	{ 0x1bad, 0xf904, "PDP Versus Fighting Pad", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:360:	{ 0x1bad, 0xf906, "MortalKombat FightStick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:361:	{ 0x1bad, 0xfa01, "MadCatz GamePad", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:362:	{ 0x1bad, 0xfd00, "Razer Onza TE", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:363:	{ 0x1bad, 0xfd01, "Razer Onza", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:364:	{ 0x1ee9, 0x1590, "ZOTAC Gaming Zone", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:365:	{ 0x20bc, 0x5134, "BETOP BTP-KP50B Xinput Dongle", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:366:	{ 0x20bc, 0x514a, "BETOP BTP-KP50C Xinput Dongle", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-367-	{ 0x20d6, 0x2001, "BDA Xbox Series X Wired Controller", 0, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-369-	{ 0x20d6, 0x2064, "PowerA Wired Controller for Xbox", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:370:	{ 0x20d6, 0x281f, "PowerA Wired Controller For Xbox 360", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-371-	{ 0x20d6, 0x400b, "PowerA FUSION Pro 4 Wired Controller", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c-372-	{ 0x20d6, 0x890b, "PowerA MOGA XP-Ultra Controller", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:373:	{ 0x2345, 0xe00b, "Machenike G5 Pro Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:374:	{ 0x24c6, 0x5000, "Razer Atrox Arcade Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:375:	{ 0x24c6, 0x5300, "PowerA MINI PROEX Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:376:	{ 0x24c6, 0x5303, "Xbox Airflo wired controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:377:	{ 0x24c6, 0x530a, "Xbox 360 Pro EX Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:378:	{ 0x24c6, 0x531a, "PowerA Pro Ex", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:379:	{ 0x24c6, 0x5397, "FUS1ON Tournament Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-380-	{ 0x24c6, 0x541a, "PowerA Xbox One Mini Wired Controller", 0, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-382-	{ 0x24c6, 0x543a, "PowerA Xbox One wired controller", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:383:	{ 0x24c6, 0x5500, "Hori XBOX 360 EX 2 with Turbo", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:384:	{ 0x24c6, 0x5501, "Hori Real Arcade Pro VX-SA", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:385:	{ 0x24c6, 0x5502, "Hori Fighting Stick VX Alt", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:386:	{ 0x24c6, 0x5503, "Hori Fighting Edge", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:387:	{ 0x24c6, 0x5506, "Hori SOULCALIBUR V Stick", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:388:	{ 0x24c6, 0x550d, "Hori GEM Xbox controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:389:	{ 0x24c6, 0x550e, "Hori Real Arcade Pro V Kai 360", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:390:	{ 0x24c6, 0x5510, "Hori Fighting Commander ONE (Xbox 360/PC Mode)", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-391-	{ 0x24c6, 0x551a, "PowerA FUSION Pro Controller", 0, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-393-	{ 0x24c6, 0x581a, "ThrustMaster XB1 Classic Controller", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:394:	{ 0x24c6, 0x5b00, "ThrustMaster Ferrari 458 Racing Wheel", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:395:	{ 0x24c6, 0x5b02, "Thrustmaster, Inc. GPX Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:396:	{ 0x24c6, 0x5b03, "Thrustmaster Ferrari 458 Racing Wheel", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:397:	{ 0x24c6, 0x5d04, "Razer Sabertooth", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:398:	{ 0x24c6, 0xfafe, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:399:	{ 0x2563, 0x058d, "OneXPlayer Gamepad", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-400-	{ 0x294b, 0x3303, "Snakebyte GAMEPAD BASE X", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c-401-	{ 0x294b, 0x3404, "Snakebyte GAMEPAD RGB X", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:402:	{ 0x2993, 0x2001, "TECNO Pocket Go", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-403-	{ 0x2dc8, 0x2000, "8BitDo Pro 2 Wired Controller fox Xbox", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c-404-	{ 0x2dc8, 0x200f, "8BitDo Ultimate 3-mode Controller for Xbox", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:405:	{ 0x2dc8, 0x3106, "8BitDo Ultimate Wireless / Pro 2 Wired Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:406:	{ 0x2dc8, 0x3109, "8BitDo Ultimate Wireless Bluetooth", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:407:	{ 0x2dc8, 0x310a, "8BitDo Ultimate 2C Wireless Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:408:	{ 0x2dc8, 0x310b, "8BitDo Ultimate 2 Wireless Controller", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:409:	{ 0x2dc8, 0x6001, "8BitDo SN30 Pro", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-410-	{ 0x2e24, 0x0423, "Hyperkin DuchesS Xbox One pad", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
--
drivers/input/joystick/xpad.c-413-	{ 0x2e95, 0x0504, "SCUF Gaming Controller", MAP_SHARE_BUTTON, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:414:	{ 0x31e3, 0x1100, "Wooting One", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:415:	{ 0x31e3, 0x1200, "Wooting Two", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:416:	{ 0x31e3, 0x1210, "Wooting Lekker", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:417:	{ 0x31e3, 0x1220, "Wooting Two HE", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:418:	{ 0x31e3, 0x1230, "Wooting Two HE (ARM)", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:419:	{ 0x31e3, 0x1300, "Wooting 60HE (AVR)", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:420:	{ 0x31e3, 0x1310, "Wooting 60HE (ARM)", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-421-	{ 0x3285, 0x0603, "Nacon Pro Compact controller for Xbox", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:422:	{ 0x3285, 0x0607, "Nacon GC-100", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-423-	{ 0x3285, 0x0614, "Nacon Pro Compact", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c-424-	{ 0x3285, 0x0646, "Nacon Pro Compact", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:425:	{ 0x3285, 0x0662, "Nacon Revolution5 Pro", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-426-	{ 0x3285, 0x0663, "Nacon Evol-X", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:427:	{ 0x3537, 0x1004, "GameSir T4 Kaleid", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-428-	{ 0x3537, 0x1010, "GameSir G7 SE", 0, XTYPE_XBOXONE },
drivers/input/joystick/xpad.c:429:	{ 0x3651, 0x1000, "CRKD SG", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-430-	{ 0x366c, 0x0005, "ByoWave Proteus Controller", MAP_SHARE_BUTTON, XTYPE_XBOXONE, FLAG_DELAY_INIT },
drivers/input/joystick/xpad.c-431-	{ 0x3767, 0x0101, "Fanatec Speedster 3 Forceshock Wheel", 0, XTYPE_XBOX },
drivers/input/joystick/xpad.c:432:	{ 0x37d7, 0x2501, "Flydigi Apex 5", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c:433:	{ 0x413d, 0x2104, "Black Shark Green Ghost Gamepad", 0, XTYPE_XBOX360 },
drivers/input/joystick/xpad.c-434-	{ 0xffff, 0xffff, "Chinese-made Xbox Controller", 0, XTYPE_XBOX },
--
drivers/input/joystick/xpad.c=896=static void xpad360_process_packet(struct usb_xpad *xpad, struct input_dev *dev,
--
drivers/input/joystick/xpad.c-918-	if (!(xpad->mapping & MAP_DPAD_TO_BUTTONS) ||
drivers/input/joystick/xpad.c:919:	    xpad->xtype == XTYPE_XBOX360W) {
drivers/input/joystick/xpad.c-920-		input_report_abs(dev, ABS_HAT0X,
--
drivers/input/joystick/xpad.c-968-	/* XBOX360W controllers can't be turned off without driver assistance */
drivers/input/joystick/xpad.c:969:	if (xpad->xtype == XTYPE_XBOX360W) {
drivers/input/joystick/xpad.c-970-		if (xpad->mode_btn_down_ts > 0 && xpad->pad_present &&
--
drivers/input/joystick/xpad.c=1232=static void xpad_irq_in(struct urb *urb)
--
drivers/input/joystick/xpad.c-1257-	switch (xpad->xtype) {
drivers/input/joystick/xpad.c:1258:	case XTYPE_XBOX360:
drivers/input/joystick/xpad.c-1259-		xpad360_process_packet(xpad, xpad->dev, 0, xpad->idata);
drivers/input/joystick/xpad.c-1260-		break;
drivers/input/joystick/xpad.c:1261:	case XTYPE_XBOX360W:
drivers/input/joystick/xpad.c-1262-		xpad360w_process_packet(xpad, 0, xpad->idata);
--
drivers/input/joystick/xpad.c=1555=static int xpad_play_effect(struct input_dev *dev, void *data, struct ff_effect *effect)
--
drivers/input/joystick/xpad.c-1581-
drivers/input/joystick/xpad.c:1582:	case XTYPE_XBOX360:
drivers/input/joystick/xpad.c-1583-		packet->data[0] = 0x00;
--
drivers/input/joystick/xpad.c-1594-
drivers/input/joystick/xpad.c:1595:	case XTYPE_XBOX360W:
drivers/input/joystick/xpad.c-1596-		packet->data[0] = 0x00;
--
drivers/input/joystick/xpad.c=1686=static void xpad_send_led_command(struct usb_xpad *xpad, int command)
--
drivers/input/joystick/xpad.c-1695-	switch (xpad->xtype) {
drivers/input/joystick/xpad.c:1696:	case XTYPE_XBOX360:
drivers/input/joystick/xpad.c-1697-		packet->data[0] = 0x01;
--
drivers/input/joystick/xpad.c-1703-
drivers/input/joystick/xpad.c:1704:	case XTYPE_XBOX360W:
drivers/input/joystick/xpad.c-1705-		packet->data[0] = 0x00;
--
drivers/input/joystick/xpad.c=1743=static int xpad_led_probe(struct usb_xpad *xpad)
--
drivers/input/joystick/xpad.c-1748-
drivers/input/joystick/xpad.c:1749:	if (xpad->xtype != XTYPE_XBOX360 && xpad->xtype != XTYPE_XBOX360W)
drivers/input/joystick/xpad.c-1750-		return 0;
--
drivers/input/joystick/xpad.c=1801=static int xpad_start_input(struct usb_xpad *xpad)
--
drivers/input/joystick/xpad.c-1814-	}
drivers/input/joystick/xpad.c:1815:	if (xpad->xtype == XTYPE_XBOX360) {
drivers/input/joystick/xpad.c-1816-		/*
--
drivers/input/joystick/xpad.c=1958=static int xpad_init_input(struct usb_xpad *xpad)
--
drivers/input/joystick/xpad.c-1971-
drivers/input/joystick/xpad.c:1972:	if (xpad->xtype == XTYPE_XBOX360W) {
drivers/input/joystick/xpad.c-1973-		/* x360w controllers and the receiver have different ids */
--
drivers/input/joystick/xpad.c-1980-
drivers/input/joystick/xpad.c:1981:	if (xpad->xtype != XTYPE_XBOX360W) {
drivers/input/joystick/xpad.c-1982-		input_dev->open = xpad_open;
--
drivers/input/joystick/xpad.c-1996-	/* set up model-specific ones */
drivers/input/joystick/xpad.c:1997:	if (xpad->xtype == XTYPE_XBOX360 || xpad->xtype == XTYPE_XBOX360W ||
drivers/input/joystick/xpad.c-1998-	    xpad->xtype == XTYPE_XBOXONE) {
--
drivers/input/joystick/xpad.c-2026-	if (!(xpad->mapping & MAP_DPAD_TO_BUTTONS) ||
drivers/input/joystick/xpad.c:2027:	    xpad->xtype == XTYPE_XBOX360W) {
drivers/input/joystick/xpad.c-2028-		for (i = 0; xpad_abs_pad[i] >= 0; i++)
--
drivers/input/joystick/xpad.c=2069=static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id)
--
drivers/input/joystick/xpad.c-2118-			if (intf->cur_altsetting->desc.bInterfaceProtocol == 129)
drivers/input/joystick/xpad.c:2119:				xpad->xtype = XTYPE_XBOX360W;
drivers/input/joystick/xpad.c-2120-			else if (intf->cur_altsetting->desc.bInterfaceProtocol == 208)
--
drivers/input/joystick/xpad.c-2122-			else
drivers/input/joystick/xpad.c:2123:				xpad->xtype = XTYPE_XBOX360;
drivers/input/joystick/xpad.c-2124-		} else {
--
drivers/input/joystick/xpad.c-2210-
drivers/input/joystick/xpad.c:2211:	if (xpad->xtype == XTYPE_XBOX360W) {
drivers/input/joystick/xpad.c-2212-		/*
--
drivers/input/joystick/xpad.c=2248=static void xpad_disconnect(struct usb_interface *intf)
--
drivers/input/joystick/xpad.c-2251-
drivers/input/joystick/xpad.c:2252:	if (xpad->xtype == XTYPE_XBOX360W)
drivers/input/joystick/xpad.c-2253-		xpad360w_stop_input(xpad);
--
drivers/input/joystick/xpad.c=2274=static int xpad_suspend(struct usb_interface *intf, pm_message_t message)
--
drivers/input/joystick/xpad.c-2278-
drivers/input/joystick/xpad.c:2279:	if (xpad->xtype == XTYPE_XBOX360W) {
drivers/input/joystick/xpad.c-2280-		/*
--
drivers/input/joystick/xpad.c=2307=static int xpad_resume(struct usb_interface *intf)
--
drivers/input/joystick/xpad.c-2312-	xpad->delayed_init_done = false;
drivers/input/joystick/xpad.c:2313:	if (xpad->xtype == XTYPE_XBOX360W)
drivers/input/joystick/xpad.c-2314-		return xpad360w_start_input(xpad);
]

gemini-3.1-pro-preview

							input: 75321
							output: 50
							thoughts: 395
						

**Analyzing the Xbox 360 Wireless Controller Driver Logic**

Okay, so I'm looking at how the `xpad_device` handles different Xbox 360 controller types. Specifically, I see that for the `XTYPE_XBOX360`, the device IDs are `0x045e, 0x028e`, and for the `XTYPE_XBOX360W`, it's `0x045e, 0x0291`. Right, got it.

Now, if we are dealing with `XTYPE_XBOX360W` (`0x045e, 0x0291`), the `xpad_probe` function *does* call `xpad360w_start_input`, which is expected to submit `irq_in`. But hang on a second... `xpad_probe` doesn't call `xpad_init_input` for `XTYPE_XBOX360W` directly! I need to re-examine that logic.

Ah, here it is:

```c
	if (xpad->xtype == XTYPE_XBOX360W) {
		error = xpad360w_start_input(xpad);
		if (error)
			goto err_deinit_output;
		udev->quirks |= USB_QUIRK_RESET_RESUME;
	} else {
		error = xpad_init_input(xpad);
		if (error)
			goto err_deinit_output;
	}
```

Okay, so that confirms it. For `XTYPE_XBOX360W`, the code *doesn't* call `xpad_init_input` during the probe. If `xpad_init_input` isn't called, then `xpad_led_probe` won't be called, either. This is the crucial point.

So, since `xpad_led_probe` isn't called, that means `irq_out` is *not* submitted during the probe stage for `XTYPE_XBOX360W` devices! That raises a question: if `irq_out` isn't submitted initially, how is it active when the device is disconnected? Seems impossible!

Wait a second. Maybe `xpad_init_input` *is* called later for `XTYPE_XBOX360W`? I'll need to trace the execution path. Let me check `xpad360w_process_packet`, that must be where initialization occurs.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad360w_process_packet]

map[SourceCode:1011:	/*
1012:	 * xpad360w_process_packet
1013:	 *
1014:	 * Completes a request by converting the data into events for the
1015:	 * input subsystem. It is version for xbox 360 wireless controller.
1016:	 *
1017:	 * Byte.Bit
1018:	 * 00.1 - Status change: The controller or headset has connected/disconnected
1019:	 *                       Bits 01.7 and 01.6 are valid
1020:	 * 01.7 - Controller present
1021:	 * 01.6 - Headset present
1022:	 * 01.1 - Pad state (Bytes 4+) valid
1023:	 *
1024:	 */
1025:	static void xpad360w_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char *data)
1026:	{
1027:		struct input_dev *dev;
1028:		bool present;
1029:	
1030:		/* Presence change */
1031:		if (data[0] & 0x08) {
1032:			present = (data[1] & 0x80) != 0;
1033:	
1034:			if (xpad->pad_present != present) {
1035:				xpad->pad_present = present;
1036:				schedule_work(&xpad->work);
1037:			}
1038:		}
1039:	
1040:		/* Valid pad data */
1041:		if (data[1] != 0x1)
1042:			return;
1043:	
1044:		rcu_read_lock();
1045:		dev = rcu_dereference(xpad->x360w_dev);
1046:		if (dev)
1047:			xpad360_process_packet(xpad, dev, cmd, &data[4]);
1048:		rcu_read_unlock();
1049:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 76956
							output: 46
							thoughts: 38
						

Okay, here's my interpretation of those thoughts, tailored for an expert audience, and delivered as a first-person summary:

**Digging into Xbox 360 Controller Presence Handling**

Right, so I see that `xpad360w_process_packet` is the function that triggers the `xpad->work` work queue item whenever the controller's presence state changes. Makes sense; that's the obvious entry point. The interesting part, though, is how it handles the details. Now, let's dive deeper and figure out exactly what happens within `xpad_presence_work`. I'm curious to see if it's doing something simple like toggling a flag or if there are any subtle state machine implementations that I can pick apart. I'd like to get a handle on the control flow here.

map[ContextFile:drivers/input/joystick/xpad.c IncludeLines:true Name:xpad_presence_work]

map[SourceCode: 986:	static void xpad_presence_work(struct work_struct *work)
 987:	{
 988:		struct usb_xpad *xpad = container_of(work, struct usb_xpad, work);
 989:		int error;
 990:	
 991:		if (xpad->pad_present) {
 992:			error = xpad_init_input(xpad);
 993:			if (error) {
 994:				/* complain only, not much else we can do here */
 995:				dev_err(&xpad->dev->dev,
 996:					"unable to init device: %d\n", error);
 997:			} else {
 998:				rcu_assign_pointer(xpad->x360w_dev, xpad->dev);
 999:			}
1000:		} else {
1001:			RCU_INIT_POINTER(xpad->x360w_dev, NULL);
1002:			synchronize_rcu();
1003:			/*
1004:			 * Now that we are sure xpad360w_process_packet is not
1005:			 * using input device we can get rid of it.
1006:			 */
1007:			xpad_deinit_input(xpad);
1008:		}
1009:	}
 SourceFile:drivers/input/joystick/xpad.c]

gemini-3.1-pro-preview

							input: 77626
							output: 49
							thoughts: 2959
						

**The Xbox Controller Use-After-Free Vulnerability: A Deep Dive**

Okay, here's the breakdown of this Xbox controller driver vulnerability, as I see it. It looks like a classic use-after-free issue, and I've got a pretty clear path to exploit it, if I'm understanding this correctly.

It all starts with the `xpad_presence_work` function, which is triggered when the device sends a presence packet, for controllers defined as `XTYPE_XBOX360W`. This calls `xpad_init_input` which then calls `xpad_led_probe`. Crucially, `xpad_led_probe` submits the `irq_out` USB interrupt request. So, we've got an `irq_out` submission happening *very* early in the device's lifecycle. `irq_in` is submitted in the probe itself when the device is `XTYPE_XBOX360W`. So, now, both `irq_in` and `irq_out` are active at the same time.

The core of the bug lies in the disconnection sequence. When the device disconnects, `xpad_disconnect` is called. It calls `xpad360w_stop_input` which kills `irq_in`. Then, `xpad_disconnect` calls `xpad_stop_output`, which calls `usb_wait_anchor_empty_timeout` on `irq_out_anchor`. It calls `usb_kill_urb(xpad->irq_in)` which waits for `xpad_irq_in` to finish. But, `usb_kill_urb` returns *before* the completion handler is executed. `xpad_disconnect` will free `xpad` *before* the completion handler for `irq_out` runs. Which is `xpad_irq_out`! This is where the use-after-free happens. `xpad_irq_out` accesses `xpad` *after* it's been freed. 

The interesting part is, `usb_wait_anchor_empty_timeout` will wait for `irq_out` to complete. This is the race condition. It is a very small race window, it seems. If `irq_out` *isn't* running, the wait returns immediately. If it *is* running, the wait will return after it completes. But because of `usb_kill_urb`, it has to finish and return, before the main disconnect process can continue.

Even if we use `XTYPE_XBOX360` the bug remains. The flow is different, but the end result is the same: `xpad_irq_out` accesses freed memory. In this case, `irq_out` is submitted during the `xpad_probe` call. We don't even need to open the device to trigger this use-after-free!

So, the key steps to reproduce are this:

1.  We need a USB device that matches the `xpad_device` struct. The relevant values are vendor ID `0x045e` and product ID `0x028e` (for `XTYPE_XBOX360`) or `0x0291` (for `XTYPE_XBOX360W`). The interface needs exactly two interrupt endpoints, one IN and one OUT.
2.  The device needs to be opened (if `XTYPE_XBOX360`) or send a presence packet (if `XTYPE_XBOX360W`).
3.  Then we disconnect!

We can trigger `XTYPE_XBOX360W` by setting the interface class to `USB_CLASS_VENDOR_SPEC` and the protocol to `129`. This is nice, because we can probably reproduce this on a variety of devices, not just actual Xbox controllers.

To trigger the use-after-free with `XTYPE_XBOX360W`, we need to find a way to make `irq_out` stay active during the disconnect. In the completion handler, `xpad_irq_out`, the URB is only resubmitted if another LED command is queued. And `irq_out` is submitted only once, so the window is tiny. So, we must have another LED command in progress when the disconnect is triggered. If `dummy_hcd` delays the completion of `irq_out`, then there is a chance of hitting the race. But, we can send a stream of presence packets and toggle `pad_present`, to keep calling `xpad_init_input` which calls `xpad_led_probe` and sends LED commands.

map[ContextFile:drivers/usb/core/hcd.c IncludeLines:true Name:__usb_hcd_giveback_urb]

map[SourceCode:1630:	static void __usb_hcd_giveback_urb(struct urb *urb)
1631:	{
1632:		struct usb_hcd *hcd = bus_to_hcd(urb->dev->bus);
1633:		struct usb_anchor *anchor = urb->anchor;
1634:		int status = urb->unlinked;
1635:	
1636:		urb->hcpriv = NULL;
1637:		if (unlikely((urb->transfer_flags & URB_SHORT_NOT_OK) &&
1638:		    urb->actual_length < urb->transfer_buffer_length &&
1639:		    !status))
1640:			status = -EREMOTEIO;
1641:	
1642:		unmap_urb_for_dma(hcd, urb);
1643:		usbmon_urb_complete(&hcd->self, urb, status);
1644:		usb_anchor_suspend_wakeups(anchor);
1645:		usb_unanchor_urb(urb);
1646:		if (likely(status == 0))
1647:			usb_led_activity(USB_LED_EVENT_HOST);
1648:	
1649:		/* pass ownership to the completion handler */
1650:		urb->status = status;
1651:		/*
1652:		 * This function can be called in task context inside another remote
1653:		 * coverage collection section, but kcov doesn't support that kind of
1654:		 * recursion yet. Only collect coverage in softirq context for now.
1655:		 */
1656:		kcov_remote_start_usb_softirq((u64)urb->dev->bus->busnum);
1657:		urb->complete(urb);
1658:		kcov_remote_stop_softirq();
1659:	
1660:		usb_anchor_resume_wakeups(anchor);
1661:		atomic_dec(&urb->use_count);
1662:		/*
1663:		 * Order the write of urb->use_count above before the read
1664:		 * of urb->reject below.  Pairs with the memory barriers in
1665:		 * usb_kill_urb() and usb_poison_urb().
1666:		 */
1667:		smp_mb__after_atomic();
1668:	
1669:		if (unlikely(atomic_read(&urb->reject)))
1670:			wake_up(&usb_kill_urb_queue);
1671:		usb_put_urb(urb);
1672:	}
 SourceFile:drivers/usb/core/hcd.c]

gemini-3.1-pro-preview

							input: 82393
							output: 22
							thoughts: 2053
						

**Race Condition Discovery and Exploitation with USB Disconnect**

Okay, so I've zeroed in on a critical use-after-free vulnerability within the xpad driver, specifically triggered by a race condition during USB device disconnect. My analysis shows this is a classic scenario. The sequence of events is clear: `usb_unanchor_urb` is called *before* `urb->complete(urb)`, meaning when `xpad_irq_out` (part of the complete callback) is running, the URB isn't anchored anymore. This is the crux of the problem.

If `xpad_stop_output` is waiting for the anchor to empty via `usb_wait_anchor_empty_timeout`, it will be immediately woken up by `usb_unanchor_urb`. Then `xpad_disconnect` gets control and frees `xpad`. Then, because `xpad_irq_out` is running, it accesses `xpad->odata_lock`, leading to the use-after-free. This is easily triggered. The trigger is to connect the device, and then disconnect it immediately while the `irq_out` callback is running.

I initially thought `usb_wait_anchor_empty_timeout` might be a timed wait, but it's not. It uses `wait_event_timeout` and calls `wake_up` right away, so the disconnect proceeds immediately after the `usb_unanchor_urb` call. Given that `xpad_irq_out` is running in a softirq context on a potentially different CPU, there's a clear window for this race. Syzkaller, with its concurrent execution, is primed to hit this reliably.

To exploit this in syzkaller, the process is straightforward: connect a vulnerable device, then exit, causing disconnection. The `syz_usb_connect` call is the key, and because of how syzkaller works, the device is disconnected on exit. I need to construct the appropriate descriptors for a Microsoft X-Box 360 pad. I've got the vendor and product IDs (0x045e, 0x028e), and can build the device descriptor, configuration descriptor, and interface descriptors.

I noted an interesting check in `xpad_probe` based on the interface protocol. Initially, if the interface protocol is 129, the `xtype` will be `XTYPE_XBOX360W`, protocol 208 will cause `XTYPE_XBOXONE`, and the other one will cause `XTYPE_XBOX360`. However, the driver has a table that already knows this:

```c
{ 0x045e, 0x028e, "Microsoft X-Box 360 pad", 0, XTYPE_XBOX360 }
```

So `xtype` will be set to `XTYPE_XBOX360`, and `xpad_init_input` is called and `xpad_led_probe` is called. So `irq_out` will be submitted.

The crash report confirms that the problem is either with `XTYPE_XBOX360W` or `XTYPE_XBOX360`. Syzkaller will also open the input device, submitting `irq_in`, so I think that means it is `XTYPE_XBOX360`.

I've constructed the syzkaller program, providing the necessary device and configuration descriptors. I've confirmed the syntax and now have the `syz_usb_connect` call ready to trigger the vulnerability.

map[File:dev_bus_usb.txt]

map[Output:# Copyright 2019 syzkaller project authors. All rights reserved.
# Use of this source code is governed by Apache 2 LICENSE that can be found in the LICENSE file.

# https://elixir.bootlin.com/linux/latest/source/drivers/usb/core/devio.c

include <linux/ioctl.h>
include <linux/usb.h>
include <linux/usbdevice_fs.h>
include <uapi/linux/fcntl.h>
include <uapi/linux/usb/ch9.h>

define MAXDRIVERNAME	USBDEVFS_MAXDRIVERNAME + 1

resource fd_usbfs[fd]

syz_open_dev$usbfs(dev ptr[in, string["/dev/bus/usb/00#/00#"]], id intptr, flags flags[open_flags]) fd_usbfs

read$usbfs(fd fd_usbfs, buf buffer[out], count len[buf])

mmap$usbfs(addr vma, len len[addr], prot flags[mmap_prot], flags flags[mmap_flags], fd fd_usbfs, offset fileoff)
_ = __NR_mmap2

# TODO: arg is a pointer to a previously submitted URB.
ioctl$USBDEVFS_REAPURB(fd fd_usbfs, cmd const[USBDEVFS_REAPURB], arg ptr[out, int64])
ioctl$USBDEVFS_REAPURBNDELAY(fd fd_usbfs, cmd const[USBDEVFS_REAPURBNDELAY], arg ptr[out, int64])

ioctl$USBDEVFS_CONTROL(fd fd_usbfs, cmd const[USBDEVFS_CONTROL], arg ptr[in, usbdevfs_ctrltransfer])
ioctl$USBDEVFS_BULK(fd fd_usbfs, cmd const[USBDEVFS_BULK], arg ptr[in, usbdevfs_bulktransfer])
ioctl$USBDEVFS_RESETEP(fd fd_usbfs, cmd const[USBDEVFS_RESETEP], arg ptr[in, usbdevfs_ep])
ioctl$USBDEVFS_RESET(fd fd_usbfs, cmd const[USBDEVFS_RESET])
ioctl$USBDEVFS_CLEAR_HALT(fd fd_usbfs, cmd const[USBDEVFS_CLEAR_HALT], arg ptr[in, usbdevfs_ep])
ioctl$USBDEVFS_GETDRIVER(fd fd_usbfs, cmd const[USBDEVFS_GETDRIVER], arg ptr[inout, usbdevfs_getdriver])
ioctl$USBDEVFS_CONNECTINFO(fd fd_usbfs, cmd const[USBDEVFS_CONNECTINFO], arg ptr[out, usbdevfs_connectinfo])
ioctl$USBDEVFS_SETINTERFACE(fd fd_usbfs, cmd const[USBDEVFS_SETINTERFACE], arg ptr[in, usbdevfs_setinterface])
ioctl$USBDEVFS_SETCONFIGURATION(fd fd_usbfs, cmd const[USBDEVFS_SETCONFIGURATION], arg ptr[in, int32])
ioctl$USBDEVFS_SUBMITURB(fd fd_usbfs, cmd const[USBDEVFS_SUBMITURB], arg ptr[in, usbdevfs_urb])

# TODO: arg is a pointer to a previously submitted URB.
ioctl$USBDEVFS_DISCARDURB(fd fd_usbfs, cmd const[USBDEVFS_DISCARDURB], arg ptr[in, int64])

ioctl$USBDEVFS_DISCSIGNAL(fd fd_usbfs, cmd const[USBDEVFS_DISCSIGNAL], arg ptr[in, usbdevfs_disconnectsignal])
ioctl$USBDEVFS_CLAIMINTERFACE(fd fd_usbfs, cmd const[USBDEVFS_CLAIMINTERFACE], arg ptr[in, int32])
ioctl$USBDEVFS_RELEASEINTERFACE(fd fd_usbfs, cmd const[USBDEVFS_RELEASEINTERFACE], arg ptr[in, int32])
ioctl$USBDEVFS_IOCTL(fd fd_usbfs, cmd const[USBDEVFS_IOCTL], arg ptr[in, usbdevfs_ioctl])
ioctl$USBDEVFS_CLAIM_PORT(fd fd_usbfs, cmd const[USBDEVFS_CLAIM_PORT], arg ptr[in, int32])
ioctl$USBDEVFS_RELEASE_PORT(fd fd_usbfs, cmd const[USBDEVFS_RELEASE_PORT], arg ptr[in, int32])
ioctl$USBDEVFS_GET_CAPABILITIES(fd fd_usbfs, cmd const[USBDEVFS_GET_CAPABILITIES], arg ptr[out, int32])
ioctl$USBDEVFS_DISCONNECT_CLAIM(fd fd_usbfs, cmd const[USBDEVFS_DISCONNECT_CLAIM], arg ptr[in, usbdevfs_disconnect_claim])
ioctl$USBDEVFS_ALLOC_STREAMS(fd fd_usbfs, cmd const[USBDEVFS_ALLOC_STREAMS], arg ptr[in, usbdevfs_streams])
ioctl$USBDEVFS_FREE_STREAMS(fd fd_usbfs, cmd const[USBDEVFS_FREE_STREAMS], arg ptr[in, usbdevfs_streams])
ioctl$USBDEVFS_DROP_PRIVILEGES(fd fd_usbfs, cmd const[USBDEVFS_DROP_PRIVILEGES], arg ptr[in, int32])
ioctl$USBDEVFS_GET_SPEED(fd fd_usbfs, cmd const[USBDEVFS_GET_SPEED])
ioctl$USBDEVFS_FORBID_SUSPEND(fd fd_usbfs, cmd const[USBDEVFS_FORBID_SUSPEND])
ioctl$USBDEVFS_ALLOW_SUSPEND(fd fd_usbfs, cmd const[USBDEVFS_ALLOW_SUSPEND])
ioctl$USBDEVFS_WAIT_FOR_RESUME(fd fd_usbfs, cmd const[USBDEVFS_WAIT_FOR_RESUME])

usbdevfs_ep {
	num	int8:7[0:15]
	dir	int8:1
}

usbdevfs_ctrltransfer {
	bRequestType	flags[usb_request_type_flags, int8]
	bRequest	flags[usb_requests, int8]
	wValue		int16
	wIndex		int16
	wLength		len[data, int16]
	timeout		int32
	data		ptr[inout, array[int8]]
}

usb_request_type_flags = USB_DIR_OUT, USB_DIR_IN, USB_TYPE_MASK, USB_TYPE_STANDARD, USB_TYPE_CLASS, USB_TYPE_VENDOR, USB_TYPE_RESERVED, USB_RECIP_MASK, USB_RECIP_DEVICE, USB_RECIP_INTERFACE, USB_RECIP_ENDPOINT, USB_RECIP_OTHER, USB_RECIP_PORT, USB_RECIP_RPIPE

usbdevfs_bulktransfer {
	ep	align32[usbdevfs_ep]
	len	len[data, int32]
	timeout	int32
	data	ptr[inout, array[int8]]
}

usbdevfs_getdriver {
	interface	int32
	driver		array[int8, MAXDRIVERNAME]
}

usbdevfs_connectinfo {
	devnum	int32
	slow	int8
}

usbdevfs_setinterface {
	interface	int32
	altsetting	int32
}

usbdevfs_urb [
	urb_type_control	usbdevfs_urb_control
	urb_type_bulk		usbdevfs_urb_bulk
	urb_type_interrupt	usbdevfs_urb_interrupt
	urb_type_iso		usbdevfs_urb_iso
] [varlen]

usbdevfs_urb_control {
	type		const[USBDEVFS_URB_TYPE_CONTROL, int8]
	endpoint	usbdevfs_ep
	status		int32
	flags		flags[urb_flags, int32]
	buffer		ptr[in, usb_ctrlrequest]
	buffer_length	len[buffer, int32]
	actual_length	int32
	start_frame	int32
	u		const[0, int32]
	error_count	int32
	signr		int32
	usercontext	ptr[in, array[int8]]
}

usb_ctrlrequest {
	bRequestType	flags[usb_request_type_flags, int8]
	bRequest	flags[usb_requests, int8]
	wValue		int16
	wIndex		int16
	wLength		int16
} [packed]

usbdevfs_urb_bulk {
	type		const[USBDEVFS_URB_TYPE_BULK, int8]
	endpoint	usbdevfs_ep
	status		int32
	flags		flags[urb_flags, int32]
	buffer		ptr[in, array[int8]]
	buffer_length	len[buffer, int32]
	actual_length	int32
	start_frame	int32
	stream_id	int32
	error_count	int32
	signr		int32
	usercontext	ptr[in, array[int8]]
}

usbdevfs_urb_interrupt {
	type		const[USBDEVFS_URB_TYPE_INTERRUPT, int8]
	endpoint	usbdevfs_ep
	status		int32
	flags		flags[urb_flags, int32]
	buffer		ptr[in, array[int8]]
	buffer_length	len[buffer, int32]
	actual_length	int32
	start_frame	int32
	u		const[0, int32]
	error_count	int32
	signr		int32
	usercontext	ptr[in, array[int8]]
}

usbdevfs_urb_iso {
	type			const[USBDEVFS_URB_TYPE_ISO, int8]
	endpoint		usbdevfs_ep
	status			int32
	flags			flags[urb_flags, int32]
	buffer			ptr[in, array[int8]]
	buffer_length		len[buffer, int32]
	actual_length		int32
	start_frame		int32
	number_of_packets	len[iso_frame_desc, int32]
	error_count		int32
	signr			int32
	usercontext		ptr[in, array[int8]]
	iso_frame_desc		array[usbdevfs_iso_packet_desc, 1:127]
}

urb_flags = USBDEVFS_URB_SHORT_NOT_OK, USBDEVFS_URB_ISO_ASAP, USBDEVFS_URB_BULK_CONTINUATION, USBDEVFS_URB_NO_FSBR, USBDEVFS_URB_ZERO_PACKET, USBDEVFS_URB_NO_INTERRUPT

usbdevfs_iso_packet_desc {
	length		int32
	actual_length	int32
	status		int32
}

usbdevfs_disconnectsignal {
	signr	int32
	context	ptr[in, array[int8]]
}

usbdevfs_ioctl [
	usbdevfs_disconnect	usbdevfs_ioctl_disconnect
	usbdevfs_connect	usbdevfs_ioctl_connect
	usbdevfs_driver		usbdevfs_ioctl_driver
]

usbdevfs_ioctl_disconnect {
	ifno		int32
	ioctl_code	const[USBDEVFS_DISCONNECT, int32]
	data		const[0, intptr]
}

usbdevfs_ioctl_connect {
	ifno		int32
	ioctl_code	const[USBDEVFS_CONNECT, int32]
	data		const[0, intptr]
}

usbdevfs_ioctl_driver {
	ifno		int32
	ioctl_code	int32
	data		ptr[inout, array[int8]]
}

usbdevfs_disconnect_claim {
	interface	int32
	flags		flags[disconnect_flags, int32]
	driver		array[int8, MAXDRIVERNAME]
}

disconnect_flags = USBDEVFS_DISCONNECT_CLAIM_IF_DRIVER, USBDEVFS_DISCONNECT_CLAIM_EXCEPT_DRIVER

usbdevfs_streams {
	num_streams	int32[2:65536]
	num_eps		len[eps, int32]
	eps		array[usbdevfs_ep, 1:USB_MAXENDPOINTS]
}
]

gemini-3.1-pro-preview

							input: 88220
							output: 19
							thoughts: 19
						

Here's my thought process, summarized as you requested:

**A USB Connection Aha!**

Okay, hold on a second... *syz_usb_connect*! That function name... it's familiar. I need to quickly cross-reference this. Let me see, wasn't that discussed in the context of some recent fuzzer findings related to USB? Where did I see that documented? Wait... yes! It's in *vusb.txt*! Fantastic. That's exactly where I was expecting to see the relevant details. This confirms the connection and gives me a good starting point for further investigation. This simplifies the search significantly.

map[File:vusb.txt]

map[Output:# Copyright 2019 syzkaller project authors. All rights reserved.
# Use of this source code is governed by Apache 2 LICENSE that can be found in the LICENSE file.

include <linux/types.h>
include <linux/byteorder/generic.h>

include <uapi/linux/usb/ch9.h>
include <uapi/linux/usb/ch11.h>

include <uapi/linux/usb/midi.h>
include <uapi/linux/usb/audio.h>
include <linux/usb/audio-v2.h>
include <linux/usb/audio-v3.h>
include <uapi/linux/hid.h>
include <linux/hid.h>
include <uapi/linux/usb/cdc.h>
include <uapi/linux/if_ether.h>
include <linux/interrupt.h>
include <linux/usb/cdc_ncm.h>
include <drivers/net/usb/asix.h>

# This is a special fd for USB fuzzing and should only be used with syz_usb_* pseudo-syscalls.
# We don't inherit it from the fd resource, to discourage syzkaller calling raw ioctls on it.
resource fd_usb[int32]: -1

# These are generic pseudo-syscalls for emulating arbitrary USB devices.
# They are mostly targeted to cover the enumeration process.
syz_usb_connect(speed flags[usb_device_speed], dev_len len[dev], dev ptr[in, usb_device_descriptor], conn_descs ptr[in, vusb_connect_descriptors]) fd_usb (timeout[3000], prog_timeout[3000], remote_cover)
syz_usb_control_io(fd fd_usb, descs ptr[in, vusb_descriptors], resps ptr[in, vusb_responses]) (timeout[300], remote_cover)
syz_usb_ep_write(fd fd_usb, ep int8, len len[data], data ptr[in, array[int8, 0:256]]) (timeout[300], remote_cover)
syz_usb_ep_read(fd fd_usb, ep int8, len len[data], data buffer[out]) (timeout[300], remote_cover)
syz_usb_disconnect(fd fd_usb) (timeout[300], remote_cover)

usb_device_speed = USB_SPEED_UNKNOWN, USB_SPEED_LOW, USB_SPEED_FULL, USB_SPEED_HIGH, USB_SPEED_WIRELESS, USB_SPEED_SUPER, USB_SPEED_SUPER_PLUS

# TODO: consider patching idVendor and idProduct for all class specific descriptions in Go code to cover more drivers.
# TODO: custom syz_usb_ep_write() descriptions for all class specific descriptions.
# TODO: consider adding custom vusb_connect_descriptors definitions to all class specific descriptions.

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

type usb_device_descriptor_verbose_t[USB, CLASS, SUBCLASS, PROTOCOL, PACKET, VENDOR, PRODUCT, DEVICE, CFS] {
	bLength			const[USB_DT_DEVICE_SIZE, int8]
	bDescriptorType		const[USB_DT_DEVICE, int8]

	bcdUSB			USB
	bDeviceClass		const[CLASS, int8]
	bDeviceSubClass		const[SUBCLASS, int8]
	bDeviceProtocol		const[PROTOCOL, int8]
	bMaxPacketSize0		PACKET
	idVendor		const[VENDOR, int16]
	idProduct		const[PRODUCT, int16]
	bcdDevice		const[DEVICE, int16]
	iManufacturer		const[1, int8]
	iProduct		const[2, int8]
	iSerialNumber		const[3, int8]
	bNumConfigurations	len[configs, int8]

	configs			CFS
} [packed]

type usb_device_descriptor_t[CLASS, SUBCLASS, PROTOCOL, VENDOR, PRODUCT, DEVICE, CFS] usb_device_descriptor_verbose_t[flags[usb_versions, int16], CLASS, SUBCLASS, PROTOCOL, flags[usb_device_max_packet_sizes, int8], VENDOR, PRODUCT, DEVICE, CFS]
type usb_device_descriptor_fixed_t[USB, CLASS, SUBCLASS, PROTOCOL, PACKET, VENDOR, PRODUCT, DEVICE, CFS] usb_device_descriptor_verbose_t[const[USB, int16], CLASS, SUBCLASS, PROTOCOL, const[PACKET, int8], VENDOR, PRODUCT, DEVICE, CFS]

usb_versions = 0x110, 0x200, 0x201, 0x250, 0x300, 0x310

# https://elixir.bootlin.com/linux/v5.1.7/source/drivers/usb/core/hub.c#L4661
usb_device_max_packet_sizes = 8, 16, 32, 64, 255

type usb_config_descriptor_verbose_t[NUM, IFSNUM, ICONFIG, ATTRS, POWER, EXTRA, IFS] {
	bLength			const[USB_DT_CONFIG_SIZE, int8]
	bDescriptorType		const[USB_DT_CONFIG, int8]

	wTotalLength		len[parent, int16]
	bNumInterfaces		IFSNUM
	bConfigurationValue	NUM
	iConfiguration		ICONFIG
	bmAttributes		ATTRS
	bMaxPower		POWER

	extra			EXTRA
	interfaces		IFS
} [packed]

type usb_config_descriptor_t[NUM, IFSNUM, IFS] usb_config_descriptor_verbose_t[NUM, IFSNUM, int8, flags[usb_config_attributes, int8], int8, void, IFS]
type usb_config_descriptor_ifaces_array_t[NUM, IFS] usb_config_descriptor_t[NUM, len[interfaces, int8], IFS]
type usb_config_descriptor_fixed_t[NUM, IFSNUM, ATTRS, POWER, IFS] usb_config_descriptor_verbose_t[const[NUM, int8], const[IFSNUM, int8], const[0, int8], const[ATTRS, int8], const[POWER, int8], void, IFS]
type usb_config_descriptor_extra_t[NUM, IFSNUM, EXTRA, IFS] usb_config_descriptor_verbose_t[NUM, IFSNUM, int8, flags[usb_config_attributes, int8], int8, EXTRA, IFS]

type usb_interface_descriptor_verbose_t[IFNUM, ALTNUM, EPSNUM, CLASS, SUBCLASS, PROTOCOL, IIF, EXTRA, EPS] {
	bLength			const[USB_DT_INTERFACE_SIZE, int8]
	bDescriptorType		const[USB_DT_INTERFACE, int8]

	bInterfaceNumber	IFNUM
	bAlternateSetting	ALTNUM
	bNumEndpoints		EPSNUM
	bInterfaceClass		CLASS
	bInterfaceSubClass	SUBCLASS
	bInterfaceProtocol	PROTOCOL
	iInterface		IIF

	extra			EXTRA
	endpoints		EPS
} [packed]

type usb_interface_descriptor_t[IFNUM, ALTNUM, EPSNUM, CLASS, SUBCLASS, PROTOCOL, EXTRA, EPS] usb_interface_descriptor_verbose_t[IFNUM, ALTNUM, EPSNUM, CLASS, SUBCLASS, PROTOCOL, int8, EXTRA, EPS]
type usb_interface_descriptor_eps_array_t[IFNUM, ALTNUM, CLASS, SUBCLASS, PROTOCOL, EXTRA, EPS] usb_interface_descriptor_t[IFNUM, ALTNUM, len[endpoints, int8], CLASS, SUBCLASS, PROTOCOL, EXTRA, EPS]
type usb_interface_descriptor_fixed_t[IFNUM, ALTNUM, EPSNUM, CLASS, SUBCLASS, PROTOCOL, EXTRA, EPS] usb_interface_descriptor_verbose_t[const[IFNUM, int8], const[ALTNUM, int8], const[EPSNUM, int8], const[CLASS, int8], const[SUBCLASS, int8], const[PROTOCOL, int8], const[0, int8], EXTRA, EPS]

# TODO: non-audio endpoints have USB_DT_ENDPOINT_SIZE.
type usb_endpoint_descriptor_verbose_t[ADDR, ATTRS, PACKET, INTERVAL, REFRESH, SYNCH, EXTRA] {
	bLength			const[USB_DT_ENDPOINT_AUDIO_SIZE, int8]
	bDescriptorType		const[USB_DT_ENDPOINT, int8]

	bEndpointAddress	ADDR
	bmAttributes		ATTRS
	wMaxPacketSize		PACKET
	bInterval		INTERVAL

	bRefresh		REFRESH
	bSynchAddress		SYNCH

	extra			EXTRA
} [packed]

type usb_endpoint_descriptor_t[ADDR, ATTRS, EXTRA] usb_endpoint_descriptor_verbose_t[ADDR, ATTRS, flags[usb_endpoint_max_packet_sizes, int16], int8, int8, int8, EXTRA]
type usb_endpoint_descriptor_fixed_t[ADDR, ATTRS, PACKET, INTERVAL, EXTRA] usb_endpoint_descriptor_verbose_t[const[ADDR, int8], const[ATTRS, int8], const[PACKET, int16], const[INTERVAL, int8], const[0, int8], const[0, int8], EXTRA]

# TODO: dummy driver has complex requirements for packet sizes, account for those:
# https://elixir.bootlin.com/linux/v5.3.6/source/drivers/usb/gadget/udc/dummy_hcd.c#L497
usb_endpoint_max_packet_sizes = 8, 16, 32, 64, 512, 1023, 1024

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# Generic USB device, configuration, interface and endpoint descriptors.

# We only support one configuration per device.
# bDeviceClass, bDeviceSubClass, bDeviceProtocol, idVendor, idProduct
# and bcdDevice are patched by Go code, see sys/linux/init_vusb.go.
usb_device_descriptor {
	inner	usb_device_descriptor_t[0, 0, 0, 0, 0, 0, array[usb_config_descriptor, 1]]
} [packed]

usb_config_descriptor {
	inner	usb_config_descriptor_ifaces_array_t[int8, array[usb_interface_descriptor, 1:4]]
} [packed]

usb_config_attributes = USB_CONFIG_ATT_ONE, USB_CONFIG_ATT_SELFPOWER, USB_CONFIG_ATT_WAKEUP, USB_CONFIG_ATT_BATTERY

# bInterfaceNumber, bInterfaceClass, bInterfaceSubClass and bInterfaceProtocol
# are patched by Go code, see sys/linux/init_vusb.go.
usb_interface_descriptor {
	inner	usb_interface_descriptor_eps_array_t[int8, int8, const[0, int8], const[0, int8], const[0, int8], array[usb_interface_extra_descriptor, 0:2], array[usb_endpoint_descriptor, 0:16]]
} [packed]

usb_endpoint_descriptor {
	inner	usb_endpoint_descriptor_t[flags[usb_endpoint_addresses, int8], flags[usb_endpoint_attributes, int8], array[usb_endpoint_extra_descriptor, 0:2]]
} [packed]

usb_endpoint_addresses = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, USB_DIR_OUT, USB_DIR_IN

usb_endpoint_attributes = USB_ENDPOINT_XFER_CONTROL, USB_ENDPOINT_XFER_ISOC, USB_ENDPOINT_XFER_BULK, USB_ENDPOINT_XFER_INT, USB_ENDPOINT_INTR_PERIODIC, USB_ENDPOINT_INTR_NOTIFICATION, USB_ENDPOINT_SYNC_NONE, USB_ENDPOINT_SYNC_ASYNC, USB_ENDPOINT_SYNC_ADAPTIVE, USB_ENDPOINT_SYNC_SYNC, USB_ENDPOINT_USAGE_DATA, USB_ENDPOINT_USAGE_FEEDBACK, USB_ENDPOINT_USAGE_FEEDBACK

vusb_connect_descriptors {
	qual_len	len[qual, int32]
	qual		ptr[in, usb_qualifier_descriptor]
	bos_len		len[bos, int32]
	bos		ptr[in, usb_bos_descriptor]
	strs_len	len[strs, int32]
	strs		array[vusb_connect_string_descriptor]
} [packed]

vusb_connect_string_descriptor {
	len	len[str, int32]
	str	ptr[in, usb_string_descriptor]
} [packed]

vusb_descriptors {
	len	len[parent, int32]
	generic	ptr[in, vusb_descriptor_generic]

	string	ptr[in, vusb_descriptor_t[USB_TYPE_STANDARD, USB_DT_STRING, usb_string_descriptor]]
	bos	ptr[in, vusb_descriptor_t[USB_TYPE_STANDARD, USB_DT_BOS, usb_bos_descriptor]]

	hub_hs	ptr[in, vusb_descriptor_t[USB_TYPE_CLASS, USB_DT_HUB, usb_hub_descriptor_hs]]
	hub_ss	ptr[in, vusb_descriptor_t[USB_TYPE_CLASS, USB_DT_SS_HUB, usb_hub_descriptor_ss]]
} [packed]

vusb_descriptor_generic {
	req_type	flags[usb_request_types, int8]
	desc_type	flags[usb_descriptor_types, int8]
	len		bytesize[data, int32]
	data		usb_generic_descriptor
} [packed]

usb_request_types = USB_TYPE_STANDARD, USB_TYPE_CLASS, USB_TYPE_VENDOR

type vusb_descriptor_t[CLASS, REQ, DATA] {
	type	const[CLASS, int8]
	req	const[REQ, int8]
	len	bytesize[data, int32]
	data	DATA
} [packed]

# TODO: consider doing lookups based on USB_RECIP values.
vusb_responses {
	len				len[parent, int32]
	generic				ptr[in, vusb_response_generic]

	get_interface			ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_INTERFACE, int8]]
	get_configuration		ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_CONFIGURATION, int8]]

# TODO: move these into custom descriptions for hub class when they are added.
	hub_USB_REQ_GET_STATUS_hub	ptr[in, vusb_response_t[USB_TYPE_CLASS, USB_REQ_GET_STATUS, usb_hub_status]]
	hub_USB_REQ_GET_STATUS_port	ptr[in, vusb_response_t[USB_TYPE_CLASS, USB_REQ_GET_STATUS, usb_port_status]]

# TODO: move these into custom descriptions for asix driver when they are added.
	asix_AX_CMD_READ_MII_REG	ptr[in, vusb_response_t[USB_TYPE_VENDOR, AX_CMD_READ_MII_REG, int16]]
	asix_AX_CMD_STATMNGSTS_REG	ptr[in, vusb_response_t[USB_TYPE_VENDOR, AX_CMD_STATMNGSTS_REG, int8]]
	asix_AX_CMD_READ_EEPROM		ptr[in, vusb_response_t[USB_TYPE_VENDOR, AX_CMD_READ_EEPROM, array[int8, 2]]]
	asix_AX_CMD_READ_RX_CTL		ptr[in, vusb_response_t[USB_TYPE_VENDOR, AX_CMD_READ_RX_CTL, int16]]
	asix_AX_CMD_READ_NODE_ID	ptr[in, vusb_response_t[USB_TYPE_VENDOR, AX_CMD_READ_NODE_ID, mac_addr]]
	asix_AX88172_CMD_READ_NODE_ID	ptr[in, vusb_response_t[USB_TYPE_VENDOR, AX88172_CMD_READ_NODE_ID, mac_addr]]
	asix_AX_CMD_READ_PHY_ID		ptr[in, vusb_response_t[USB_TYPE_VENDOR, AX_CMD_READ_PHY_ID, array[int8, 2]]]
	asix_AX_CMD_READ_MEDIUM_STATUS	ptr[in, vusb_response_t[USB_TYPE_VENDOR, AX_CMD_READ_MEDIUM_STATUS, int16]]
	asix_AX_CMD_READ_MONITOR_MODE	ptr[in, vusb_response_t[USB_TYPE_VENDOR, AX_CMD_READ_MONITOR_MODE, int8]]
	asix_AX_CMD_READ_GPIOS		ptr[in, vusb_response_t[USB_TYPE_VENDOR, AX_CMD_READ_GPIOS, int8]]
	asix_AX_CMD_SW_PHY_STATUS	ptr[in, vusb_response_t[USB_TYPE_VENDOR, AX_CMD_SW_PHY_STATUS, int8]]
} [packed]

vusb_response_generic {
	type	flags[usb_request_types, int8]
	req	flags[usb_requests, int8]
	len	bytesize[data, int32]
	data	array[int8, 0:256]
} [packed]

usb_requests = USB_REQ_GET_STATUS, USB_REQ_CLEAR_FEATURE, USB_REQ_SET_FEATURE, USB_REQ_SET_ADDRESS, USB_REQ_GET_DESCRIPTOR, USB_REQ_SET_DESCRIPTOR, USB_REQ_GET_CONFIGURATION, USB_REQ_SET_CONFIGURATION, USB_REQ_GET_INTERFACE, USB_REQ_SET_INTERFACE, USB_REQ_SYNCH_FRAME, USB_REQ_SET_SEL, USB_REQ_SET_ISOCH_DELAY, USB_REQ_SET_ENCRYPTION, USB_REQ_GET_ENCRYPTION, USB_REQ_RPIPE_ABORT, USB_REQ_SET_HANDSHAKE, USB_REQ_RPIPE_RESET, USB_REQ_GET_HANDSHAKE, USB_REQ_SET_CONNECTION, USB_REQ_SET_SECURITY_DATA, USB_REQ_GET_SECURITY_DATA, USB_REQ_SET_WUSB_DATA, USB_REQ_LOOPBACK_DATA_WRITE, USB_REQ_LOOPBACK_DATA_READ, USB_REQ_SET_INTERFACE_DS, USB_REQ_GET_PARTNER_PDO, USB_REQ_GET_BATTERY_STATUS, USB_REQ_SET_PDO, USB_REQ_GET_VDM, USB_REQ_SEND_VDM

type vusb_response_t[CLASS, REQ, DATA] {
	type	const[CLASS, int8]
	req	const[REQ, int8]
	len	bytesize[data, int32]
	data	DATA
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# USB descriptors requested by the kernel before the SET_CONFIGURATION request.

# TODO: figure out when is the USB_DT_OTG descriptor used.
# TODO: figure out when is the USB_DT_INTERFACE_ASSOCIATION descriptor used.
# TODO: figure out when is the USB_DT_BOS descriptor used.

type usb_string_descriptor_t[DATA] {
	bLength		len[parent, int8]
	bDescriptorType	const[USB_DT_STRING, int8]

	data		DATA
} [packed]

usb_string_descriptor [
	lang_id	usb_string_descriptor_t[flags[usb_lang_ids, int16]]
	string	usb_string_descriptor_t[array[int8, 0:256]]
] [varlen]

usb_lang_ids = 0x436, 0x41c, 0x401, 0x801, 0xc01, 0x1001, 0x1401, 0x1801, 0x1c01, 0x2001, 0x2401, 0x2801, 0x2c01, 0x3001, 0x3401, 0x3801, 0x3c01, 0x4001, 0x42b, 0x44d, 0x42c, 0x82c, 0x42d, 0x423, 0x445, 0x402, 0x455, 0x403, 0x404, 0x804, 0xc04, 0x1004, 0x1404, 0x41a, 0x405, 0x406, 0x413, 0x813, 0x409, 0x809, 0xc09, 0x1009, 0x1409, 0x1809, 0x1c09, 0x2009, 0x2409, 0x2809, 0x2c09, 0x3009, 0x3409, 0x425, 0x438, 0x429, 0x40b, 0x40c, 0x80c, 0xc0c, 0x100c, 0x140c, 0x180c, 0x437, 0x407, 0x807, 0xc07, 0x1007, 0x1407, 0x408, 0x447, 0x40d, 0x439, 0x40e, 0x40f, 0x421, 0x410, 0x810, 0x411, 0x44b, 0x860, 0x43f, 0x457, 0x412, 0x812, 0x426, 0x427, 0x827, 0x42f, 0x43e, 0x83e, 0x44c, 0x458, 0x44e, 0x861, 0x414, 0x814, 0x448, 0x415, 0x416, 0x816, 0x446, 0x418, 0x419, 0x44f, 0xc1a, 0x81a, 0x459, 0x41b, 0x424, 0x40a, 0x80a, 0xc0a, 0x100a, 0x140a, 0x180a, 0x1c0a, 0x200a, 0x240a, 0x280a, 0x2c0a, 0x300a, 0x340a, 0x380a, 0x3c0a, 0x400a, 0x440a, 0x480a, 0x4c0a, 0x500a, 0x430, 0x441, 0x41d, 0x81d, 0x449, 0x444, 0x44a, 0x41e, 0x41f, 0x422, 0x420, 0x820, 0x443, 0x843, 0x42a, 0x4ff, 0xf0ff, 0xf4ff, 0xf8ff, 0xfcff

usb_qualifier_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_DEVICE_QUALIFIER, int8]

	bcdUSB			flags[usb_versions, int16]
	bDeviceClass		int8
	bDeviceSubClass		int8
	bDeviceProtocol		int8
	bMaxPacketSize0		flags[usb_device_max_packet_sizes, int8]
	bNumConfigurations	int8
	bRESERVED		const[0, int8]
} [packed]

usb_bos_descriptor {
	bLength		const[USB_DT_BOS_SIZE, int8]
	bDescriptorType	const[USB_DT_BOS, int8]

	wTotalLength	len[parent, int16]
	bNumDeviceCaps	len[caps, int8]

	caps		array[usb_dev_cap, 0:6]
} [packed]

usb_dev_cap [
	generic		usb_generic_cap_descriptor
	wireless	usb_wireless_cap_descriptor
	ext_cap		usb_ext_cap_descriptor
	ss_cap		usb_ss_cap_descriptor
	ss_container_id	usb_ss_container_id_descriptor
	ssp_cap		usb_ssp_cap_descriptor
	ptm_cap		usb_ptm_cap_descriptor
] [varlen]

usb_generic_cap_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_DEVICE_CAPABILITY, int8]
	bDevCapabilityType	flags[usb_capability_types, int8]

	data			array[int8, 0:256]
} [packed]

usb_capability_types = USB_CAP_TYPE_WIRELESS_USB, USB_CAP_TYPE_EXT, USB_SS_CAP_TYPE, USB_SSP_CAP_TYPE, CONTAINER_ID_TYPE, USB_PTM_CAP_TYPE

usb_wireless_cap_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_DEVICE_CAPABILITY, int8]
	bDevCapabilityType	const[USB_CAP_TYPE_WIRELESS_USB, int8]

	bmAttributes		flags[usb_wireless_cap_attributes, int8]
	wPHYRates		flags[usb_wireless_cap_phyrates, int16]
	bmTFITXPowerInfo	int8
	bmFFITXPowerInfo	int8
	bmBandGroup		int16
	bReserved		int8
} [packed]

usb_wireless_cap_attributes = USB_WIRELESS_P2P_DRD, USB_WIRELESS_BEACON_MASK, USB_WIRELESS_BEACON_SELF, USB_WIRELESS_BEACON_DIRECTED, USB_WIRELESS_BEACON_NONE

usb_wireless_cap_phyrates = USB_WIRELESS_PHY_53, USB_WIRELESS_PHY_80, USB_WIRELESS_PHY_107, USB_WIRELESS_PHY_160, USB_WIRELESS_PHY_200, USB_WIRELESS_PHY_320, USB_WIRELESS_PHY_400, USB_WIRELESS_PHY_480

usb_ext_cap_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_DEVICE_CAPABILITY, int8]
	bDevCapabilityType	const[USB_CAP_TYPE_EXT, int8]

	bmAttributes1		flags[usb_ext_cap_attributes, int32:8]
	bmAttributes2		int32:4
	bmAttributes3		int32:4
	bmAttributes4		int32:16
} [packed]

usb_ext_cap_attributes = USB_LPM_SUPPORT, USB_BESL_SUPPORT, USB_BESL_BASELINE_VALID, USB_BESL_DEEP_VALID

usb_ss_cap_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_DEVICE_CAPABILITY, int8]
	bDevCapabilityType	const[USB_SS_CAP_TYPE, int8]

	bmAttributes		flags[usb_ss_cap_attributes, int8]
	wSpeedSupported		flags[usb_ss_cap_speed, int16]
	bFunctionalitySupport	int8
	bU1devExitLat		int8
	bU2DevExitLat		int16
} [packed]

usb_ss_cap_attributes = USB_LTM_SUPPORT

usb_ss_cap_speed = USB_LOW_SPEED_OPERATION, USB_FULL_SPEED_OPERATION, USB_HIGH_SPEED_OPERATION, USB_5GBPS_OPERATION

usb_ss_container_id_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_DEVICE_CAPABILITY, int8]
	bDevCapabilityType	const[CONTAINER_ID_TYPE, int8]

	bReserved		int8
	ContainerID		array[int8, 16]
} [packed]

usb_ssp_cap_descriptor {
	bLength				len[parent, int8]
	bDescriptorType			const[USB_DT_DEVICE_CAPABILITY, int8]
	bDevCapabilityType		const[USB_SSP_CAP_TYPE, int8]

	bReserved			int8
	bmAttributesSublinkSpeeds	len[bmSublinkSpeedAttr, int32:5]
	bmAttributesSpeedIDs		int32:27
	wFunctionalitySupport		flags[usb_ssp_cap_funcs, int16]
	wReserved			int16
	bmSublinkSpeedAttr		array[flags[usb_ssp_cap_sublink_speeds, int32], 0:6]
} [packed]

usb_ssp_cap_funcs = USB_SSP_MIN_SUBLINK_SPEED_ATTRIBUTE_ID, USB_SSP_MIN_RX_LANE_COUNT, USB_SSP_MIN_TX_LANE_COUNT

usb_ssp_cap_sublink_speeds = USB_SSP_SUBLINK_SPEED_SSID, USB_SSP_SUBLINK_SPEED_LSE, USB_SSP_SUBLINK_SPEED_ST, USB_SSP_SUBLINK_SPEED_RSVD, USB_SSP_SUBLINK_SPEED_LP, USB_SSP_SUBLINK_SPEED_LSM

usb_ptm_cap_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_DEVICE_CAPABILITY, int8]
	bDevCapabilityType	const[USB_PTM_CAP_TYPE, int8]
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# Extra USB descriptors that come after an interface or an endpoint descriptor.

# TODO: consider removing class specific descriptors here for described classes.
usb_interface_extra_descriptor [
	generic		usb_generic_descriptor
	hid_hid		usb_hid_descriptor_hid
	cdc_ecm		usb_cdc_header_ecm
	cdc_ncm		usb_cdc_header_ncm
	uac_control	uac_control_iface_extra_descriptors
	uac_as		uac_as_iface_extra_descriptors
] [varlen]

usb_endpoint_extra_descriptor [
	generic	usb_generic_descriptor
	uac_iso	uac_iso_endpoint_descriptor
] [varlen]

usb_generic_descriptor {
	bLength		len[parent, int8]
	bDescriptorType	flags[usb_descriptor_types, int8]

	data		array[int8, 0:256]
} [packed]

usb_descriptor_types = USB_DT_DEVICE, USB_DT_CONFIG, USB_DT_STRING, USB_DT_INTERFACE, USB_DT_ENDPOINT, USB_DT_DEVICE_QUALIFIER, USB_DT_OTHER_SPEED_CONFIG, USB_DT_INTERFACE_POWER, USB_DT_OTG, USB_DT_DEBUG, USB_DT_INTERFACE_ASSOCIATION, USB_DT_SECURITY, USB_DT_KEY, USB_DT_ENCRYPTION_TYPE, USB_DT_BOS, USB_DT_DEVICE_CAPABILITY, USB_DT_WIRELESS_ENDPOINT_COMP, USB_DT_WIRE_ADAPTER, USB_DT_RPIPE, USB_DT_CS_RADIO_CONTROL, USB_DT_PIPE_USAGE, USB_DT_SS_ENDPOINT_COMP, USB_DT_SSP_ISOC_ENDPOINT_COMP, HID_DT_HID, HID_DT_REPORT, HID_DT_PHYSICAL

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# USB descriptors requested after the SET_CONFIGURATION request.

usb_hub_descriptor_hs {
	bDescLength		len[parent, int8]
	bDescriptorType		const[USB_DT_HUB, int8]

	bNbrPorts		int8
	wHubCharacteristics	flags[usb_hub_characteristics, int16]
	bPwrOn2PwrGood		int8
	bHubContrCurrent	int8

	DeviceRemovable		array[int8, USB_HUB_PORTS_BITS]
	PortPwrCtrlMask		array[int8, USB_HUB_PORTS_BITS]
} [packed]

usb_hub_descriptor_ss {
	bDescLength		len[parent, int8]
	bDescriptorType		const[USB_DT_SS_HUB, int8]

	bNbrPorts		int8
	wHubCharacteristics	flags[usb_hub_characteristics, int16]
	bPwrOn2PwrGood		int8
	bHubContrCurrent	int8

	bHubHdrDecLat		int8
	wHubDelay		int16
	DeviceRemovable		int16
} [packed]

define USB_HUB_PORTS_BITS	((USB_MAXCHILDREN + 1 + 7) / 8)

usb_hub_characteristics = HUB_CHAR_LPSM, HUB_CHAR_COMMON_LPSM, HUB_CHAR_INDV_PORT_LPSM, HUB_CHAR_NO_LPSM, HUB_CHAR_COMPOUND, HUB_CHAR_OCPM, HUB_CHAR_COMMON_OCPM, HUB_CHAR_INDV_PORT_OCPM, HUB_CHAR_NO_OCPM, HUB_CHAR_TTTT, HUB_CHAR_PORTIND

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# Replies to USB control requests requested after the SET_CONFIGURATION request.

usb_port_status {
	wPortStatus	flags[usb_port_status_flags, int16]
	wPortChange	flags[usb_port_change_flags, int16]
	dwExtPortStatus	array[flags[usb_ext_port_status_flags, int32], 0:1]
} [packed]

usb_port_status_flags = USB_PORT_STAT_CONNECTION, USB_PORT_STAT_ENABLE, USB_PORT_STAT_SUSPEND, USB_PORT_STAT_OVERCURRENT, USB_PORT_STAT_RESET, USB_PORT_STAT_L1, USB_PORT_STAT_POWER, USB_PORT_STAT_LOW_SPEED, USB_PORT_STAT_HIGH_SPEED, USB_PORT_STAT_TEST, USB_PORT_STAT_INDICATOR, USB_PORT_STAT_LINK_STATE, USB_SS_PORT_STAT_POWER, USB_SS_PORT_STAT_SPEED, USB_PORT_STAT_SPEED_5GBPS, USB_SS_PORT_LS_U0, USB_SS_PORT_LS_U1, USB_SS_PORT_LS_U2, USB_SS_PORT_LS_U3, USB_SS_PORT_LS_SS_DISABLED, USB_SS_PORT_LS_RX_DETECT, USB_SS_PORT_LS_SS_INACTIVE, USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RECOVERY, USB_SS_PORT_LS_HOT_RESET, USB_SS_PORT_LS_COMP_MOD, USB_SS_PORT_LS_LOOPBACK

usb_port_change_flags = USB_PORT_STAT_C_CONNECTION, USB_PORT_STAT_C_ENABLE, USB_PORT_STAT_C_SUSPEND, USB_PORT_STAT_C_OVERCURRENT, USB_PORT_STAT_C_RESET, USB_PORT_STAT_C_L1, USB_PORT_STAT_C_BH_RESET, USB_PORT_STAT_C_LINK_STATE, USB_PORT_STAT_C_CONFIG_ERROR

usb_ext_port_status_flags = USB_EXT_PORT_STAT_RX_SPEED_ID, USB_EXT_PORT_STAT_TX_SPEED_ID, USB_EXT_PORT_STAT_RX_LANES, USB_EXT_PORT_STAT_TX_LANES

usb_hub_status {
	wHubStatus	flags[usb_hub_status_flags, int16]
	wHubChange	flags[usb_hub_change_flags, int16]
} [packed]

usb_hub_status_flags = HUB_STATUS_LOCAL_POWER, HUB_STATUS_OVERCURRENT

usb_hub_change_flags = HUB_CHANGE_LOCAL_POWER, HUB_CHANGE_OVERCURRENT

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# HID device class specific descriptions.
# https://www.usb.org/sites/default/files/documents/hid1_11.pdf
# https://elixir.bootlin.com/linux/latest/source/drivers/hid/usbhid/hid-core.c
# https://elixir.bootlin.com/linux/latest/source/drivers/hid/hid-core.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/legacy/hid.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/function/f_hid.c

# Connected HID devices are known to create the following /dev/ files:
# /dev/hidraw#, /dev/usb/hiddev# and /dev/input/event#.

resource fd_usb_hid[fd_usb]

syz_usb_connect$hid(speed flags[usb_device_speed], dev_len len[dev], dev ptr[in, usb_device_descriptor_hid], conn_descs ptr[in, vusb_connect_descriptors]) fd_usb_hid (timeout[3000], prog_timeout[3000], remote_cover)
syz_usb_control_io$hid(fd fd_usb_hid, descs ptr[in, vusb_descriptors_hid], resps ptr[in, vusb_responses_hid]) (timeout[300], remote_cover)

# idVendor and idProduct are patched by Go code, see sys/linux/init_vusb.go.
usb_device_descriptor_hid {
	inner	usb_device_descriptor_t[0, 0, 0, 0, 0, 64, array[usb_config_descriptor_hid, 1]]
} [packed]

usb_config_descriptor_hid {
	inner	usb_config_descriptor_ifaces_array_t[const[1, int8], array[usb_interface_descriptor_hid, 1]]
} [packed]

usb_interface_descriptor_hid {
	inner	usb_interface_descriptor_t[const[0, int8], int8, int8[1:2], const[USB_CLASS_HID, int8], const[USB_INTERFACE_SUBCLASS_BOOT, int8], flags[usb_hid_protocols, int8], usb_hid_descriptor_hid, usb_endpoint_descriptors_hid]
} [packed]

usb_hid_protocols = USB_INTERFACE_PROTOCOL_KEYBOARD, USB_INTERFACE_PROTOCOL_MOUSE

usb_endpoint_descriptors_hid {
	in	usb_endpoint_descriptor_hid_in
	out	array[usb_endpoint_descriptor_hid_out, 0:1]
} [packed]

usb_endpoint_descriptor_hid_in {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_HID_IN_ADDRESS, int8], const[USB_ENDPOINT_HID_ATTRIBUTES, int8], void]
} [packed]

usb_endpoint_descriptor_hid_out {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_HID_OUT_ADDRESS, int8], const[USB_ENDPOINT_HID_ATTRIBUTES, int8], void]
} [packed]

define USB_ENDPOINT_HID_ATTRIBUTES	(USB_ENDPOINT_XFER_INT)
define USB_ENDPOINT_HID_IN_ADDRESS	(1 | USB_DIR_IN)
define USB_ENDPOINT_HID_OUT_ADDRESS	(2)

vusb_descriptors_hid {
	len		len[parent, int32]
	generic		ptr[in, vusb_descriptor_generic]

	USB_DT_STRING	ptr[in, vusb_descriptor_t[USB_TYPE_STANDARD, USB_DT_STRING, usb_string_descriptor]]

# For unknown reasons these are requested as USB_TYPE_STANDARD and not as USB_TYPE_CLASS.
# Linux doesn't request HID_DT_HID, but some hosts might do that.
	HID_DT_REPORT	ptr[in, vusb_descriptor_t[USB_TYPE_STANDARD, HID_DT_REPORT, hid_descriptor_report]]
	HID_DT_HID	ptr[in, vusb_descriptor_t[USB_TYPE_STANDARD, HID_DT_HID, usb_hid_descriptor_hid]]
} [packed]

vusb_responses_hid {
	len				len[parent, int32]
	generic				ptr[in, vusb_response_generic]

	USB_REQ_GET_INTERFACE		ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_INTERFACE, int8]]
	USB_REQ_GET_CONFIGURATION	ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_CONFIGURATION, int8]]

	HID_REQ_GET_REPORT		ptr[in, vusb_response_t[USB_TYPE_CLASS, HID_REQ_GET_REPORT, array[int8, 0:256]]]
	HID_REQ_GET_PROTOCOL		ptr[in, vusb_response_t[USB_TYPE_CLASS, HID_REQ_GET_PROTOCOL, int8]]
} [packed]

# USB HID specifications allows for multiple report and physical descriptors
# to be present, but I don't see any support for them in the Linux kernel,
# except for a single report descriptor.
usb_hid_descriptor_hid {
	bLength		len[parent, int8]
	bDescriptorType	const[HID_DT_HID, int8]

	bcdHID		int16
	bCountryCode	int8
	bNumDescriptors	const[1, int8]

	report_desc	usb_hid_class_descriptor_report
} [packed]

usb_hid_class_descriptor_report {
	bDescriptorType		const[HID_DT_REPORT, int8]
	wDescriptorLength	int16[0:HID_MAX_DESCRIPTOR_SIZE]
} [packed]

# TODO: it's hard to describe the REPORT descriptor structure via syzkaller
# descriptions, so consider generating it in Go code.
# TODO: the length of REPORT descriptor must match the value in HID descriptor.
# TODO: there are vendor specific REPORT descriptor formats (Logitech HID++).

# Linux HID stack doesn't support long items.
hid_descriptor_report {
	items	array[hid_report_item_short]
} [packed]

type hid_report_item_short_012_t[TYPE, TAGS] {
	bSize	len[data, int8:2]
	bType	const[TYPE, int8:2]
	bTag	flags[TAGS, int8:4]
	data	array[int8, 0:2]
} [packed]

type hid_report_item_short_4_t[TYPE, TAGS] {
	bSize	const[3, int8:2]
	bType	const[TYPE, int8:2]
	bTag	flags[TAGS, int8:4]
	data	array[int8, 4]
} [packed]

type hid_report_item_short_t[TYPE, TAGS] [
	item_012	hid_report_item_short_012_t[TYPE, TAGS]
	item_4		hid_report_item_short_4_t[TYPE, TAGS]
] [varlen]

hid_report_item_short [
	main	hid_report_item_short_t[HID_ITEM_TYPE_MAIN, hid_report_item_main_tags]
	global	hid_report_item_short_t[HID_ITEM_TYPE_GLOBAL, hid_report_item_global_tags]
	local	hid_report_item_short_t[HID_ITEM_TYPE_LOCAL, hid_report_item_local_tags]
] [varlen]

hid_report_item_main_tags = HID_MAIN_ITEM_TAG_INPUT, HID_MAIN_ITEM_TAG_OUTPUT, HID_MAIN_ITEM_TAG_FEATURE, HID_MAIN_ITEM_TAG_BEGIN_COLLECTION, HID_MAIN_ITEM_TAG_END_COLLECTION
hid_report_item_global_tags = HID_GLOBAL_ITEM_TAG_USAGE_PAGE, HID_GLOBAL_ITEM_TAG_LOGICAL_MINIMUM, HID_GLOBAL_ITEM_TAG_LOGICAL_MAXIMUM, HID_GLOBAL_ITEM_TAG_PHYSICAL_MINIMUM, HID_GLOBAL_ITEM_TAG_PHYSICAL_MAXIMUM, HID_GLOBAL_ITEM_TAG_UNIT_EXPONENT, HID_GLOBAL_ITEM_TAG_UNIT, HID_GLOBAL_ITEM_TAG_REPORT_SIZE, HID_GLOBAL_ITEM_TAG_REPORT_ID, HID_GLOBAL_ITEM_TAG_REPORT_COUNT, HID_GLOBAL_ITEM_TAG_PUSH, HID_GLOBAL_ITEM_TAG_POP
hid_report_item_local_tags = HID_LOCAL_ITEM_TAG_USAGE, HID_LOCAL_ITEM_TAG_USAGE_MINIMUM, HID_LOCAL_ITEM_TAG_USAGE_MAXIMUM, HID_LOCAL_ITEM_TAG_DESIGNATOR_INDEX, HID_LOCAL_ITEM_TAG_DESIGNATOR_MINIMUM, HID_LOCAL_ITEM_TAG_DESIGNATOR_MAXIMUM, HID_LOCAL_ITEM_TAG_STRING_INDEX, HID_LOCAL_ITEM_TAG_STRING_MINIMUM, HID_LOCAL_ITEM_TAG_STRING_MAXIMUM, HID_LOCAL_ITEM_TAG_DELIMITER

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# PRINTER device class specific descriptions.
# https://www.usb.org/sites/default/files/usbprint11a021811.pdf
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/class/usblp.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/legacy/printer.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/function/f_printer.c

# Connected PRINTER devices are known to create the following /dev/ files:
# /dev/usb/lp#.
# TODO: write descriptions for those.

# drivers/usb/class/usblp.c
define USBLP_REQ_GET_ID	0x00
define USBLP_REQ_GET_STATUS	0x01
define USBLP_REQ_RESET	0x02
define USBLP_REQ_HP_CHANNEL_CHANGE_REQUEST	0x00
define USBLP_FIRST_PROTOCOL	1
define USBLP_LAST_PROTOCOL	3

resource fd_usb_printer[fd_usb]

syz_usb_connect$printer(speed flags[usb_device_speed], dev_len len[dev], dev ptr[in, usb_device_descriptor_printer], conn_descs ptr[in, vusb_connect_descriptors]) fd_usb_printer (timeout[3000], prog_timeout[3000], remote_cover)
syz_usb_control_io$printer(fd fd_usb_printer, descs ptr[in, vusb_descriptors_printer], resps ptr[in, vusb_responses_printer]) (timeout[300], remote_cover)

usb_device_descriptor_printer {
	inner	usb_device_descriptor_t[0, 0, 0, 0x525, 0xa4a8, 64, array[usb_config_descriptor_printer, 1]]
} [packed]

usb_config_descriptor_printer {
	inner	usb_config_descriptor_ifaces_array_t[const[1, int8], array[usb_interface_descriptor_printer, 1]]
} [packed]

usb_interface_descriptor_printer {
	inner	usb_interface_descriptor_t[const[0, int8], int8, int8[1:2], const[USB_CLASS_PRINTER, int8], const[1, int8], int8[USBLP_FIRST_PROTOCOL:USBLP_LAST_PROTOCOL], void, usb_endpoint_descriptors_printer]
} [packed]

usb_endpoint_descriptors_printer {
	in	usb_endpoint_descriptor_printer_out
	out	array[usb_endpoint_descriptor_printer_in, 0:1]
} [packed]

usb_endpoint_descriptor_printer_out {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_PRINTER_OUT_ADDRESS, int8], const[USB_ENDPOINT_PRINTER_ATTRIBUTES, int8], void]
} [packed]

usb_endpoint_descriptor_printer_in {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_PRINTER_IN_ADDRESS, int8], const[USB_ENDPOINT_PRINTER_ATTRIBUTES, int8], void]
} [packed]

define USB_ENDPOINT_PRINTER_ATTRIBUTES	(USB_ENDPOINT_XFER_BULK)
define USB_ENDPOINT_PRINTER_OUT_ADDRESS	(1)
define USB_ENDPOINT_PRINTER_IN_ADDRESS	(2 | USB_DIR_IN)

vusb_descriptors_printer {
	len		len[parent, int32]
	generic		ptr[in, vusb_descriptor_generic]

	USB_DT_STRING	ptr[in, vusb_descriptor_t[USB_TYPE_STANDARD, USB_DT_STRING, usb_string_descriptor]]
} [packed]

vusb_responses_printer {
	len					len[parent, int32]
	generic					ptr[in, vusb_response_generic]

	USB_REQ_GET_INTERFACE			ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_INTERFACE, int8]]
	USB_REQ_GET_CONFIGURATION		ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_CONFIGURATION, int8]]

	USBLP_REQ_GET_ID			ptr[in, vusb_response_t[USB_TYPE_CLASS, USBLP_REQ_GET_ID, usb_printer_get_id_response]]
	USBLP_REQ_GET_STATUS			ptr[in, vusb_response_t[USB_TYPE_CLASS, USBLP_REQ_GET_STATUS, int8]]
	USBLP_REQ_HP_CHANNEL_CHANGE_REQUEST	ptr[in, vusb_response_t[USB_TYPE_CLASS, USBLP_REQ_HP_CHANNEL_CHANGE_REQUEST, int8]]
} [packed]

usb_printer_get_id_response {
	length	len[id, int16be]
	id	array[int8, 0:256]
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# CDC ECM (Ethernet) device class specific descriptions.
# https://www.usb.org/document-library/class-definitions-communication-devices-12
# https://elixir.bootlin.com/linux/latest/source/drivers/net/usb/cdc_ether.c
# https://elixir.bootlin.com/linux/latest/source/drivers/net/usb/usbnet.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/legacy/ether.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/function/f_ecm.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/function/u_ether.c

# Connected CDC ECM devices are known to create usbN network interfaces.
# TODO: write descriptions for those.

resource fd_usb_cdc_ecm[fd_usb]

syz_usb_connect$cdc_ecm(speed flags[usb_device_speed], dev_len len[dev], dev ptr[in, usb_device_descriptor_cdc_ecm], conn_descs ptr[in, vusb_connect_descriptors]) fd_usb_cdc_ecm (timeout[3000], prog_timeout[3000], remote_cover)
syz_usb_control_io$cdc_ecm(fd fd_usb_cdc_ecm, descs ptr[in, vusb_descriptors_cdc_ecm], resps ptr[in, vusb_responses_cdc_ecm]) (timeout[300], remote_cover)

usb_device_descriptor_cdc_ecm {
	inner	usb_device_descriptor_t[USB_CLASS_COMM, 0, 0, 0x525, 0xa4a1, 64, array[usb_config_descriptor_cdc_ecm, 1]]
} [packed]

usb_config_descriptor_cdc_ecm {
	inner	usb_config_descriptor_ifaces_array_t[const[1, int8], array[usb_interface_descriptor_cdc_ecm, 1]]
} [packed]

# Per specification CDC ECM devices have two interfaces (control and data),
# but here we're merging them into one for simplicity since Linux supports that.
usb_interface_descriptor_cdc_ecm {
	inner	usb_interface_descriptor_t[const[0, int8], int8, int8[2:3], const[USB_CLASS_COMM, int8], const[USB_CDC_SUBCLASS_ETHERNET, int8], const[USB_CDC_PROTO_NONE, int8], usb_cdc_header_ecm, usb_endpoint_descriptors_cdc_ecm]
} [packed]

usb_endpoint_descriptors_cdc_ecm {
	notify	array[usb_endpoint_descriptor_cdc_ecm_notify, 0:1]
	in	usb_endpoint_descriptor_cdc_ecm_in
	out	usb_endpoint_descriptor_cdc_ecm_out
} [packed]

usb_endpoint_descriptor_cdc_ecm_notify {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_CDC_ECM_NOTIFY_ADDRESS, int8], const[USB_ENDPOINT_CDC_ECM_NOTIFY_ATTRIBUTES, int8], void]
} [packed]

usb_endpoint_descriptor_cdc_ecm_in {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_CDC_ECM_IN_ADDRESS, int8], const[USB_ENDPOINT_CDC_ECM_DATA_ATTRIBUTES, int8], void]
} [packed]

usb_endpoint_descriptor_cdc_ecm_out {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_CDC_ECM_OUT_ADDRESS, int8], const[USB_ENDPOINT_CDC_ECM_DATA_ATTRIBUTES, int8], void]
} [packed]

define USB_ENDPOINT_CDC_ECM_NOTIFY_ATTRIBUTES	(USB_ENDPOINT_XFER_INT)
define USB_ENDPOINT_CDC_ECM_DATA_ATTRIBUTES	(USB_ENDPOINT_XFER_BULK)
define USB_ENDPOINT_CDC_ECM_NOTIFY_ADDRESS	(1 | USB_DIR_IN)
define USB_ENDPOINT_CDC_ECM_IN_ADDRESS	(2 | USB_DIR_IN)
define USB_ENDPOINT_CDC_ECM_OUT_ADDRESS	(3)

# https://elixir.bootlin.com/linux/v5.2.7/source/drivers/usb/core/message.c#L2137
# https://elixir.bootlin.com/linux/v5.2.7/source/drivers/net/usb/cdc_ether.c#L155
usb_cdc_header_ecm {
	union	usb_cdc_union_desc_t[0, 0]
	header	usb_cdc_header_desc
	ether	usb_cdc_ether_desc

	other	array[usb_cdc_header_ecm_other, 0:6]
} [packed]

usb_cdc_header_ecm_other [
	call_mgmt		usb_cdc_call_mgmt_descriptor
	acm			usb_cdc_acm_descriptor
	country_functional	usb_cdc_country_functional_desc
	network_terminal	usb_cdc_network_terminal_desc
	dmm			usb_cdc_dmm_desc
	mdlm			usb_cdc_mdlm_desc
	mdlm_detail		usb_cdc_mdlm_detail_desc
	obex			usb_cdc_obex_desc
	ncm			usb_cdc_ncm_desc
	mbim			usb_cdc_mbim_desc
	mbim_extended		usb_cdc_mbim_extended_desc
] [varlen]

usb_cdc_header_desc {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_HEADER_TYPE, int8]

	bcdCDC			int16
} [packed]

usb_cdc_call_mgmt_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_CALL_MANAGEMENT_TYPE, int8]

	bmCapabilities		flags[usb_cdc_call_mgmt_caps, int8]
	bDataInterface		int8
} [packed]

usb_cdc_call_mgmt_caps = USB_CDC_CALL_MGMT_CAP_CALL_MGMT, USB_CDC_CALL_MGMT_CAP_DATA_INTF

usb_cdc_acm_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_ACM_TYPE, int8]

	bmCapabilities		flags[usb_cdc_acm_caps, int8]
} [packed]

usb_cdc_acm_caps = USB_CDC_COMM_FEATURE, USB_CDC_CAP_LINE, USB_CDC_CAP_BRK, USB_CDC_CAP_NOTIFY

type usb_cdc_union_desc_t[MASTER, SLAVE] {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_UNION_TYPE, int8]

	bMasterInterface0	const[MASTER, int8]
	bSlaveInterface0	const[SLAVE, int8]
	slave_interfaces	array[int8, 0:6]
} [packed]

usb_cdc_country_functional_desc {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_COUNTRY_TYPE, int8]

	iCountryCodeRelDate	int8
	wCountyCode0		int16
	country_codes		array[int16, 0:6]
} [packed]

usb_cdc_network_terminal_desc {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_NETWORK_TERMINAL_TYPE, int8]

	bEntityId		int8
	iName			int8
	bChannelIndex		int8
	bPhysicalInterface	int8
} [packed]

usb_cdc_ether_desc {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_ETHERNET_TYPE, int8]

	iMACAddress		const[1, int8]
	bmEthernetStatistics	int32
	wMaxSegmentSize		int16
	wNumberMCFilters	int16
	bNumberPowerFilters	int8
} [packed]

usb_cdc_dmm_desc {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_DMM_TYPE, int8]

	bcdVersion		int16
	wMaxCommand		int16
} [packed]

usb_cdc_mdlm_desc {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_MDLM_TYPE, int8]

	bcdVersion		int16
	bGUID			usb_cdc_ecm_mbm_guid
} [packed]

# https://elixir.bootlin.com/linux/v5.2.7/source/drivers/net/usb/cdc_ether.c#L61
usb_cdc_ecm_mbm_guid {
	id0	const[0x14f5e048ba817a3, int64]
	id1	const[0x2a397ecbffc007a6, int64]
} [packed]

usb_cdc_mdlm_detail_desc {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_MDLM_DETAIL_TYPE, int8]

	bGuidDescriptorType	int8
	bDetailData		array[int8, 0:256]
} [packed]

usb_cdc_obex_desc {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_OBEX_TYPE, int8]

	bcdVersion		int16
} [packed]

usb_cdc_ncm_desc {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_NCM_TYPE, int8]

	bcdNcmVersion		int16
	bmNetworkCapabilities	flags[usb_cdc_ncm_ncaps, int8]
} [packed]

usb_cdc_ncm_ncaps = USB_CDC_NCM_NCAP_ETH_FILTER, USB_CDC_NCM_NCAP_NET_ADDRESS, USB_CDC_NCM_NCAP_ENCAP_COMMAND, USB_CDC_NCM_NCAP_MAX_DATAGRAM_SIZE, USB_CDC_NCM_NCAP_CRC_MODE, USB_CDC_NCM_NCAP_NTB_INPUT_SIZE

usb_cdc_mbim_desc {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[USB_CDC_MBIM_TYPE, int8]

	bcdMBIMVersion		int16
	wMaxControlMessage	int16
	bNumberFilters		int8
	bMaxFilterSize		int8
	wMaxSegmentSize		int16
	bmNetworkCapabilities	int8
} [packed]

usb_cdc_mbim_extended_desc {
	bLength				len[parent, int8]
	bDescriptorType			const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType		const[USB_CDC_MBIM_EXTENDED_TYPE, int8]

	bcdMBIMExtendedVersion		int16
	bMaxOutstandingCommandMessages	int8
	wMTU				int16
} [packed]

vusb_descriptors_cdc_ecm {
	len		len[parent, int32]
	generic		ptr[in, vusb_descriptor_generic]

# https://elixir.bootlin.com/linux/v5.2.7/source/drivers/net/usb/usbnet.c#L147
	USB_DT_STRING	ptr[in, vusb_descriptor_t[USB_TYPE_STANDARD, USB_DT_STRING, usb_string_descriptor_t[usb_cdc_ecm_mac]]]
} [packed]

usb_cdc_ecm_mac {
# This is a UTF16 encoded string "424242424242".
	data0	const[0x3400320034003200, int64be]
	data1	const[0x3400320034003200, int64be]
	data2	const[0x3400320034003200, int64be]
} [packed]

vusb_responses_cdc_ecm {
	len				len[parent, int32]
	generic				ptr[in, vusb_response_generic]

	USB_REQ_GET_INTERFACE		ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_INTERFACE, int8]]
	USB_REQ_GET_CONFIGURATION	ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_CONFIGURATION, int8]]
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# CDC NCM class specific descriptions.
# CDC NCM is based on CDC ECM, so some of the descriptions are reused.
# https://www.usb.org/document-library/network-control-model-devices-specification-v10-and-errata-and-adopters-agreement
# https://elixir.bootlin.com/linux/latest/source/drivers/net/usb/cdc_ncm.c
# https://elixir.bootlin.com/linux/latest/source/drivers/net/usb/usbnet.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/legacy/ncm.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/function/f_ncm.c

resource fd_usb_cdc_ncm[fd_usb]

syz_usb_connect$cdc_ncm(speed flags[usb_device_speed], dev_len len[dev], dev ptr[in, usb_device_descriptor_cdc_ncm], conn_descs ptr[in, vusb_connect_descriptors]) fd_usb_cdc_ncm (timeout[3000], prog_timeout[3000], remote_cover)
syz_usb_control_io$cdc_ncm(fd fd_usb_cdc_ncm, descs ptr[in, vusb_descriptors_cdc_ncm], resps ptr[in, vusb_responses_cdc_ncm]) (timeout[300], remote_cover)

usb_device_descriptor_cdc_ncm {
	inner	usb_device_descriptor_t[USB_CLASS_COMM, 0, 0, 0x525, 0xa4a1, 64, array[usb_config_descriptor_cdc_ncm, 1]]
} [packed]

usb_config_descriptor_cdc_ncm {
	inner	usb_config_descriptor_t[const[1, int8], const[2, int8], usb_interface_descriptors_cdc_ncm]
} [packed]

usb_interface_descriptors_cdc_ncm {
	control		usb_interface_descriptor_fixed_t[0, CDC_NCM_COMM_ALTSETTING_NCM, 1, USB_CLASS_COMM, USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE, usb_cdc_header_ncm, usb_endpoint_descriptor_cdc_ecm_notify]
	data_nop	usb_interface_descriptor_fixed_t[1, 0, 0, USB_CLASS_COMM, USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE, void, void]
	data		usb_interface_descriptor_fixed_t[1, CDC_NCM_DATA_ALTSETTING_NCM, 2, USB_CLASS_COMM, USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE, void, usb_endpoint_descriptors_cdc_ncm_data]
} [packed]

usb_endpoint_descriptors_cdc_ncm_data {
	in	usb_endpoint_descriptor_cdc_ecm_in
	out	usb_endpoint_descriptor_cdc_ecm_out
} [packed]

# https://elixir.bootlin.com/linux/v5.2.7/source/drivers/usb/core/message.c#L2137
# https://elixir.bootlin.com/linux/v5.2.7/source/drivers/net/usb/cdc_ncm.c#L798
usb_cdc_header_ncm {
	union	usb_cdc_union_desc_t[0, 1]
	header	usb_cdc_header_desc
	ether	usb_cdc_ether_desc
	ncm	usb_cdc_ncm_desc

	other	array[usb_cdc_header_ncm_other, 0:6]
} [packed]

usb_cdc_header_ncm_other [
	call_mgmt		usb_cdc_call_mgmt_descriptor
	acm			usb_cdc_acm_descriptor
	country_functional	usb_cdc_country_functional_desc
	network_terminal	usb_cdc_network_terminal_desc
	dmm			usb_cdc_dmm_desc
	mdlm			usb_cdc_mdlm_desc
	mdlm_detail		usb_cdc_mdlm_detail_desc
	obex			usb_cdc_obex_desc
	mbim			usb_cdc_mbim_desc
	mbim_extended		usb_cdc_mbim_extended_desc
] [varlen]

vusb_descriptors_cdc_ncm {
	len		len[parent, int32]
	generic		ptr[in, vusb_descriptor_generic]

# https://elixir.bootlin.com/linux/v5.2.7/source/drivers/net/usb/usbnet.c#L147
	USB_DT_STRING	ptr[in, vusb_descriptor_t[USB_TYPE_STANDARD, USB_DT_STRING, usb_string_descriptor_t[usb_cdc_ecm_mac]]]
} [packed]

vusb_responses_cdc_ncm {
	len				len[parent, int32]
	generic				ptr[in, vusb_response_generic]

	USB_REQ_GET_INTERFACE		ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_INTERFACE, int8]]
	USB_REQ_GET_CONFIGURATION	ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_CONFIGURATION, int8]]

	USB_CDC_GET_NTB_PARAMETERS	ptr[in, vusb_response_t[USB_TYPE_CLASS, USB_CDC_GET_NTB_PARAMETERS, usb_cdc_ncm_ntb_parameters]]
	USB_CDC_GET_NTB_INPUT_SIZE	ptr[in, vusb_response_t[USB_TYPE_CLASS, USB_CDC_GET_NTB_INPUT_SIZE, int32]]
	USB_CDC_GET_NTB_FORMAT		ptr[in, vusb_response_t[USB_TYPE_CLASS, USB_CDC_GET_NTB_FORMAT, int16[0:1]]]
	USB_CDC_GET_MAX_DATAGRAM_SIZE	ptr[in, vusb_response_t[USB_TYPE_CLASS, USB_CDC_GET_MAX_DATAGRAM_SIZE, int16]]
	USB_CDC_GET_CRC_MODE		ptr[in, vusb_response_t[USB_TYPE_CLASS, USB_CDC_GET_CRC_MODE, int16[0:1]]]
} [packed]

usb_cdc_ncm_ntb_parameters {
	wLength			int16
	bmNtbFormatsSupported	int16
	dwNtbInMaxSize		int32
	wNdpInDivisor		int16
	wNdpInPayloadRemainder	int16
	wNdpInAlignment		int16
	wPadding1		int16
	dwNtbOutMaxSize		int32
	wNdpOutDivisor		int16
	wNdpOutPayloadRemainder	int16
	wNdpOutAlignment	int16
	wNtbOutMaxDatagrams	int16
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# UAC1 device class specific descriptions.
# https://www.usb.org/sites/default/files/audio10.pdf
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/legacy/audio.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/function/f_uac1.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/function/f_uac1_legacy.c
# https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/usb/audio.h

# TODO: find out which /dev/ files are created by connected UAC1 devices and add descriptions for those.

resource fd_usb_uac1[fd_usb]

syz_usb_connect$uac1(speed flags[usb_device_speed], dev_len len[dev], dev ptr[in, usb_device_descriptor_uac1], conn_descs ptr[in, vusb_connect_descriptors]) fd_usb_uac1 (timeout[3000], prog_timeout[3000], remote_cover)
syz_usb_control_io$uac1(fd fd_usb_uac1, descs ptr[in, vusb_descriptors_uac1], resps ptr[in, vusb_responses_uac1]) (timeout[300], remote_cover)

usb_device_descriptor_uac1 {
	inner	usb_device_descriptor_t[0, 0, 0, 0x1d6b, 0x101, 64, array[usb_config_descriptor_uac1, 1]]
} [packed]

usb_config_descriptor_uac1 {
	inner	usb_config_descriptor_t[const[1, int8], const[3, int8], usb_interface_descriptors_uac1]
} [packed]

# TODO: control interface might have and optional interrupt endpoint.
usb_interface_descriptors_uac1 {
	inner	usb_interface_descriptors_uac1_inner
} [packed]

# Define folded-in structure to match layout expected by USB ID patching code.
usb_interface_descriptors_uac1_inner {
	control		usb_interface_descriptor_fixed_t[0, 0, 0, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOCONTROL, 0, uac_control_iface_extra_descriptors, void]
	as_out_alt_0	usb_interface_descriptor_fixed_t[1, 0, 0, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOSTREAMING, 0, void, void]
	as_out_alt_1	usb_interface_descriptor_fixed_t[1, 1, 1, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOSTREAMING, 0, uac_as_iface_extra_descriptors, uac_as_out_endpoint_descriptor]
	as_in_alt_0	usb_interface_descriptor_fixed_t[2, 0, 0, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOSTREAMING, 0, void, void]
	as_in_alt_1	usb_interface_descriptor_fixed_t[2, 1, 1, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOSTREAMING, 0, uac_as_iface_extra_descriptors, uac_as_in_endpoint_descriptor]
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# UAC uses IDs to make it possible for terminals and units to refer to each other.
# We don't have a way to describe this, so just use a limited number of ids.
type uac_id int8[1:6]

uac_control_iface_extra_descriptors {
	header	uac1_ac_header_descriptor
	others	array[uac_control_iface_extra_descriptor, 0:6]
} [packed]

uac1_ac_header_descriptor {
	bLength			const[UAC_DT_AC_HEADER_LENGTH, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_HEADER, int8]

	bcdADC			int16
	wTotalLength		len[uac_control_iface_extra_descriptors, int16]
	bInCollection		const[F_AUDIO_NUM_INTERFACES, int8]

# These must match interfaces numbers.
	baInterfaceNr0		const[1, int8]
	baInterfaceNr1		const[2, int8]
} [packed]

uac_control_iface_extra_descriptor [
	input_terminal	uac_input_terminal_descriptor
	output_terminal	uac1_output_terminal_descriptor
	mixer_unit	uac_mixer_unit_descriptor
	selector_unit	uac_selector_unit_descriptor
	feature_unit	uac_feature_unit_descriptor
	processing_unit	uac_processing_unit_descriptor
	extension_unit	uac_extension_unit_descriptor
] [varlen]

define F_AUDIO_NUM_INTERFACES	2
define UAC_DT_AC_HEADER_LENGTH	UAC_DT_AC_HEADER_SIZE(F_AUDIO_NUM_INTERFACES)

uac_input_terminal_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_INPUT_TERMINAL, int8]

	bTerminalID		uac_id
	wTerminalType		flags[uac_input_terminal_types, int16]
	bAssocTerminal		uac_id
	bNrChannels		int8
	wChannelConfig		int16
	iChannelNames		int8
	iTerminal		int8
} [packed]

# The following list contains input terminal types and inout terminal types.
uac_input_terminal_types = UAC_TERMINAL_UNDEFINED, UAC_TERMINAL_STREAMING, UAC_TERMINAL_VENDOR_SPEC, UAC_INPUT_TERMINAL_UNDEFINED, UAC_INPUT_TERMINAL_MICROPHONE, UAC_INPUT_TERMINAL_DESKTOP_MICROPHONE, UAC_INPUT_TERMINAL_PERSONAL_MICROPHONE, UAC_INPUT_TERMINAL_OMNI_DIR_MICROPHONE, UAC_INPUT_TERMINAL_MICROPHONE_ARRAY, UAC_INPUT_TERMINAL_PROC_MICROPHONE_ARRAY, UAC_BIDIR_TERMINAL_UNDEFINED, UAC_BIDIR_TERMINAL_HANDSET, UAC_BIDIR_TERMINAL_HEADSET, UAC_BIDIR_TERMINAL_SPEAKER_PHONE, UAC_BIDIR_TERMINAL_ECHO_SUPPRESSING, UAC_BIDIR_TERMINAL_ECHO_CANCELING
# The following list contains output terminal types and inout terminal types.
uac_output_terminal_types = UAC_TERMINAL_UNDEFINED, UAC_TERMINAL_STREAMING, UAC_TERMINAL_VENDOR_SPEC, UAC_OUTPUT_TERMINAL_UNDEFINED, UAC_OUTPUT_TERMINAL_SPEAKER, UAC_OUTPUT_TERMINAL_HEADPHONES, UAC_OUTPUT_TERMINAL_HEAD_MOUNTED_DISPLAY_AUDIO, UAC_OUTPUT_TERMINAL_DESKTOP_SPEAKER, UAC_OUTPUT_TERMINAL_ROOM_SPEAKER, UAC_OUTPUT_TERMINAL_COMMUNICATION_SPEAKER, UAC_OUTPUT_TERMINAL_LOW_FREQ_EFFECTS_SPEAKER, UAC_BIDIR_TERMINAL_UNDEFINED, UAC_BIDIR_TERMINAL_HANDSET, UAC_BIDIR_TERMINAL_HEADSET, UAC_BIDIR_TERMINAL_SPEAKER_PHONE, UAC_BIDIR_TERMINAL_ECHO_SUPPRESSING, UAC_BIDIR_TERMINAL_ECHO_CANCELING

uac1_output_terminal_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_OUTPUT_TERMINAL, int8]

	bTerminalID		uac_id
	wTerminalType		flags[uac_output_terminal_types, int16]
	bAssocTerminal		uac_id
	bSourceID		uac_id
	iTerminal		int8
} [packed]

uac_mixer_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_MIXER_UNIT, int8]

	bUnitID			uac_id
	bNrInPins		int8
	baSourceID		array[int8, 0:6]
} [packed]

uac_selector_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_SELECTOR_UNIT, int8]

	bUnitID			uac_id
	bNrInPins		int8
	baSourceID		array[int8, 0:6]
} [packed]

uac_feature_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_FEATURE_UNIT, int8]

	bUnitID			uac_id
	bSourceID		uac_id
	bControlSize		len[bmaControls, int8]
	bmaControls		array[flags[uac_feature_unit_controls, int16], 1:6]
	iFeature		int8
} [packed]

uac_feature_unit_controls = UAC_FU_MUTE, UAC_FU_VOLUME, UAC_FU_BASS, UAC_FU_MID, UAC_FU_TREBLE, UAC_FU_GRAPHIC_EQUALIZER, UAC_FU_AUTOMATIC_GAIN, UAC_FU_DELAY, UAC_FU_BASS_BOOST, UAC_FU_LOUDNESS

uac_processing_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC1_PROCESSING_UNIT, int8]

	bUnitID			uac_id
	wProcessType		flags[uac_processing_unit_types, int16]
	bNrInPins		int8
	baSourceID		array[int8, 0:6]
} [packed]

uac_processing_unit_types = UAC_PROCESS_UNDEFINED, UAC_PROCESS_UP_DOWNMIX, UAC_PROCESS_DOLBY_PROLOGIC, UAC_PROCESS_STEREO_EXTENDER, UAC_PROCESS_REVERB, UAC_PROCESS_CHORUS, UAC_PROCESS_DYN_RANGE_COMP

uac_extension_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC1_EXTENSION_UNIT, int8]

	bUnitID			uac_id
	wProcessType		int16
	bNrInPins		int8
	baSourceID		array[int8, 0:6]
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

uac_as_iface_extra_descriptors {
	others	array[uac_as_iface_extra_descriptor, 0:6]
} [packed]

uac_as_iface_extra_descriptor [
	as_header			uac1_as_header_descriptor
	format_type_i_continuous	uac_format_type_i_continuous_descriptor
	format_type_i_discrete		uac_format_type_i_discrete_descriptor
	format_type_ii_discrete		uac_format_type_ii_discrete_descriptor
	format_type_ii_ext		uac_format_type_ii_ext_descriptor
	format_type_i_ext		uac_format_type_i_ext_descriptor
] [varlen]

uac1_as_header_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_AS_GENERAL, int8]

	bTerminalLink		int8
	bDelay			int8
	wFormatTag		flags[uac_format_tags, int16]
} [packed]

uac_format_tags = UAC_FORMAT_TYPE_I_UNDEFINED, UAC_FORMAT_TYPE_I_PCM, UAC_FORMAT_TYPE_I_PCM8, UAC_FORMAT_TYPE_I_IEEE_FLOAT, UAC_FORMAT_TYPE_I_ALAW, UAC_FORMAT_TYPE_I_MULAW, UAC_FORMAT_TYPE_II_MPEG, UAC_FORMAT_TYPE_II_AC3
uac_usb_format_types_i = UAC_FORMAT_TYPE_I, UAC_FORMAT_TYPE_II, UAC_FORMAT_TYPE_III, UAC_FORMAT_TYPE_UNDEFINED

uac_format_type_i_continuous_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_FORMAT_TYPE, int8]

	bFormatType		const[UAC_FORMAT_TYPE_I, int8]
	bNrChannels		int8
	bSubframeSize		int8[1:4]
	bBitResolution		int8
	bSamFreqType		int8
	tLowerSamFreq		array[int8, 0:3]
	tUpperSamFreq		array[int8, 0:3]
} [packed]

uac_format_type_i_discrete_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_FORMAT_TYPE, int8]

	bFormatType		const[UAC_FORMAT_TYPE_I, int8]
	bNrChannels		int8
	bSubframeSize		int8[1:4]
	bBitResolution		int8
	bSamFreqType		int8
	tSamFreq		array[int8, 0:9]
} [packed]

uac_format_type_ii_discrete_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_FORMAT_TYPE, int8]

	bFormatType		const[UAC_FORMAT_TYPE_II, int8]
	wMaxBitRate		int16
	wSamplesPerFrame	int16
	bSamFreqType		int8
	tSamFreq		array[int8, 0:9]
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

uac_as_out_endpoint_descriptor {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_UAC1_AS_OUT_ADDRESS, int8], const[USB_ENDPOINT_UAC1_AS_ATTRIBUTES, int8], uac_iso_endpoint_descriptor]
} [packed]

uac_as_in_endpoint_descriptor {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_UAC1_AS_IN_ADDRESS, int8], const[USB_ENDPOINT_UAC1_AS_ATTRIBUTES, int8], uac_iso_endpoint_descriptor]
} [packed]

define USB_ENDPOINT_UAC1_AS_OUT_ADDRESS	(1 | USB_DIR_OUT)
define USB_ENDPOINT_UAC1_AS_IN_ADDRESS	(2 | USB_DIR_IN)
define USB_ENDPOINT_UAC1_AS_ATTRIBUTES	(USB_ENDPOINT_SYNC_ADAPTIVE | USB_ENDPOINT_XFER_ISOC)

uac_iso_ep_attributes = USB_ENDPOINT_SYNCTYPE, USB_ENDPOINT_SYNC_NONE, USB_ENDPOINT_SYNC_ASYNC, USB_ENDPOINT_SYNC_ADAPTIVE, USB_ENDPOINT_SYNC_SYNC

uac_iso_endpoint_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_ENDPOINT, int8]
	bDescriptorSubType	const[UAC_EP_GENERAL, int8]

	bmAttributes		flags[uac_iso_ep_attributes, int8]
	bLockDelayUnits		int8
	wLockDelay		int16
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

vusb_descriptors_uac1 {
	len		len[parent, int32]
	generic		ptr[in, vusb_descriptor_generic]

	USB_DT_STRING	ptr[in, vusb_descriptor_t[USB_TYPE_STANDARD, USB_DT_STRING, usb_string_descriptor]]
} [packed]

vusb_responses_uac1 {
	len				len[parent, int32]
	generic				ptr[in, vusb_response_generic]

	USB_REQ_GET_INTERFACE		ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_INTERFACE, int8]]
	USB_REQ_GET_CONFIGURATION	ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_CONFIGURATION, int8]]

	audio_UAC_GET_CUR		ptr[in, vusb_response_t[USB_TYPE_CLASS, UAC_GET_CUR, array[int8, 1:3]]]
	audio_UAC_GET_MIN		ptr[in, vusb_response_t[USB_TYPE_CLASS, UAC_GET_MIN, array[int8, 1:3]]]
	audio_UAC_GET_MAX		ptr[in, vusb_response_t[USB_TYPE_CLASS, UAC_GET_MAX, array[int8, 1:3]]]
	audio_UAC_GET_RES		ptr[in, vusb_response_t[USB_TYPE_CLASS, UAC_GET_RES, array[int8, 1:4]]]
	audio_UAC_GET_MEM		ptr[in, vusb_response_t[USB_TYPE_CLASS, UAC_GET_MEM, array[int8, 3]]]
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# UAC2 device class specific descriptions.
# https://www.usb.org/sites/default/files/audio10.pdf
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/legacy/audio.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/function/f_uac2.c
# https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/usb/audio.h

resource fd_usb_uac2[fd_usb]

syz_usb_connect$uac2(speed flags[usb_device_speed], dev_len len[dev], dev ptr[in, usb_device_descriptor_uac2], conn_descs ptr[in, vusb_connect_descriptors]) fd_usb_uac2 (timeout[3000], prog_timeout[3000], remote_cover)
syz_usb_control_io$uac2(fd fd_usb_uac2, descs ptr[in, vusb_descriptors_uac1], resps ptr[in, vusb_responses_uac1]) (timeout[300], remote_cover)

usb_device_descriptor_uac2 {
	inner	usb_device_descriptor_t[0, 0, 0, 0x41e, 0x3000, 64, array[usb_config_descriptor_uac2, 1]]
} [packed]

usb_config_descriptor_uac2 {
	inner	usb_config_descriptor_extra_t[const[1, int8], const[3, int8], uac2_interface_assoc_descriptor, usb_interface_descriptors_uac2]
} [packed]

uac2_interface_assoc_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_INTERFACE_ASSOCIATION, int8]

	bFirstInterface		int8[0:2]
	bInterfaceCount		int8[0:2]
	bFunctionClass		const[USB_CLASS_AUDIO, int8]
	bFunctionSubClass	flags[audio_function_category_types, int8]
	bFunctionProtocol	const[UAC_VERSION_2, int8]
	iFunction		int8
} [packed]

audio_function_category_types = UAC2_FUNCTION_SUBCLASS_UNDEFINED, UAC2_FUNCTION_DESKTOP_SPEAKER, UAC2_FUNCTION_HOME_THEATER, UAC2_FUNCTION_MICROPHONE, UAC2_FUNCTION_HEADSET, UAC2_FUNCTION_TELEPHONE, UAC2_FUNCTION_CONVERTER, UAC2_FUNCTION_SOUND_RECORDER, UAC2_FUNCTION_IO_BOX, UAC2_FUNCTION_MUSICAL_INSTRUMENT, UAC2_FUNCTION_PRO_AUDIO, UAC2_FUNCTION_AUDIO_VIDEO, UAC2_FUNCTION_CONTROL_PANEL, UAC2_FUNCTION_OTHER

usb_interface_descriptors_uac2 {
	inner	usb_interface_descriptors_uac2_inner
} [packed]

# Define folded-in structure to match layout expected by USB ID patching code.
usb_interface_descriptors_uac2_inner {
	control		usb_interface_descriptor_fixed_t[0, 0, 0, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOCONTROL, UAC_VERSION_2, uac2_control_iface_extra_descriptors, void]
	as_out_alt_0	usb_interface_descriptor_fixed_t[1, 0, 0, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOSTREAMING, UAC_VERSION_2, void, void]
	as_out_alt_1	usb_interface_descriptor_fixed_t[1, 1, 1, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOSTREAMING, UAC_VERSION_2, uac2_as_iface_extra_descriptors, uac2_as_out_endpoint_descriptor]
	as_in_alt_0	usb_interface_descriptor_fixed_t[2, 0, 0, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOSTREAMING, UAC_VERSION_2, void, void]
	as_in_alt_1	usb_interface_descriptor_fixed_t[2, 1, 1, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOSTREAMING, UAC_VERSION_2, uac2_as_iface_extra_descriptors, uac2_as_in_endpoint_descriptor]
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

uac2_control_iface_extra_descriptors {
	header	uac2_ac_header_descriptor
	others	array[uac2_control_iface_extra_descriptor, 0:6]
} [packed]

uac2_ac_header_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_MS_HEADER, int8]
	bcdADC			int16
	bCategory		flags[uac2_feature_unit_controls, int8]
	wTotalLength		len[uac2_control_iface_extra_descriptors, int16]
	bmControls		int8
} [packed]

uac2_feature_unit_controls = UAC2_FUNCTION_SUBCLASS_UNDEFINED, UAC2_FUNCTION_DESKTOP_SPEAKER, UAC2_FUNCTION_HOME_THEATER, UAC2_FUNCTION_MICROPHONE, UAC2_FUNCTION_HEADSET, UAC2_FUNCTION_TELEPHONE, UAC2_FUNCTION_CONVERTER, UAC2_FUNCTION_SOUND_RECORDER, UAC2_FUNCTION_IO_BOX, UAC2_FUNCTION_MUSICAL_INSTRUMENT, UAC2_FUNCTION_PRO_AUDIO, UAC2_FUNCTION_AUDIO_VIDEO, UAC2_FUNCTION_CONTROL_PANEL, UAC2_FUNCTION_OTHER, uac_feature_unit_controls

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

uac2_as_iface_extra_descriptors {
	others	array[uac2_as_iface_extra_descriptor, 0:6]
} [packed]

uac2_as_iface_extra_descriptor [
	as_header			uac2_as_header_descriptor
	format_type_i_descriptor	uac2_format_type_i_descriptor
	format_type_i_continuous	uac_format_type_i_continuous_descriptor
	format_type_i_discrete		uac_format_type_i_discrete_descriptor
	format_type_ii_discrete		uac_format_type_ii_discrete_descriptor
	format_type_i_ext		uac2_format_type_i_ext_descriptor
	format_type_ii_ext		uac_format_type_ii_ext_descriptor
] [varlen]

uac2_as_header_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_AS_GENERAL, int8]
	bTerminalLink		int8
	bmControls		int8
	bFormatType		flags[uac_usb_format_types_i, int8]
	bmFormats		flags[uac_format_tags, int32]
	bNrChannels		int8
	bmChannelConfig		int32
	iChannelNames		int8
} [packed]

b_sub_slot_sizes = 1, 2, 3, 4

uac2_format_type_i_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_FORMAT_TYPE, int8]
	bFormatType		const[UAC_FORMAT_TYPE_I, int8]
	bSubslotSize		flags[b_sub_slot_sizes, int8]
	bBitResolution		int8
} [packed]

uac2_format_type_i_ext_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_FORMAT_TYPE, int8]

	bFormatType		const[UAC_FORMAT_TYPE_I, int8]
	bSubslotSize		int8
	bBitResolution		int8
	bHeaderLength		int8
	bControlSize		int8
	bSideBandProtocol	int8
} [packed]

uac_format_type_ii_ext_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_FORMAT_TYPE, int8]
	bFormatType		const[UAC_FORMAT_TYPE_II, int8]
	wMaxBitRate		int16
	wSamplesPerFrame	int16
	bHeaderLength		int8
	bSideBandProtocol	int8
} [packed]

uac_format_type_i_ext_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_FORMAT_TYPE, int8]
	bFormatType		const[UAC_FORMAT_TYPE_I, int8]
	bSubslotSize		int8
	bBitResolution		int8
	bHeaderLength		int8
	bControlSize		int8
	bSideBandProtocol	int8
} [packed]

uac2_as_out_endpoint_descriptor {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_UAC1_AS_OUT_ADDRESS, int8], const[USB_ENDPOINT_UAC1_AS_ATTRIBUTES, int8], uac2_iso_endpoint_descriptor]
} [packed]

uac2_as_in_endpoint_descriptor {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_UAC1_AS_IN_ADDRESS, int8], const[USB_ENDPOINT_UAC1_AS_ATTRIBUTES, int8], uac2_iso_endpoint_descriptor]
} [packed]

uac2_iso_endpoint_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_ENDPOINT, int8]
	bDescriptorSubtype	const[UAC_EP_GENERAL, int8]

	bmAttributes		flags[csep_bm_attributes, int8]
	bmControls		flags[csep_bm_controls, int8]
	bLockDelayUnits		int8
	wLockDelay		int16
} [packed]

csep_bm_attributes = UAC_EP_CS_ATTR_SAMPLE_RATE, UAC_EP_CS_ATTR_PITCH_CONTROL, UAC_EP_CS_ATTR_FILL_MAX
csep_bm_controls = UAC2_CONTROL_PITCH, UAC2_CONTROL_DATA_OVERRUN, UAC2_CONTROL_DATA_UNDERRUN

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

uac2_control_iface_extra_descriptor [
	input_terminal	uac2_input_terminal_descriptor
	output_terminal	uac2_output_terminal_descriptor
	mixer_unit	uac2_mixer_unit_descriptor
	selector_unit	uac2_clock_selector_descriptor

	feature_unit	uac2_feature_unit_descriptor
	processing_unit	uac2_processing_unit_descriptor
	extension_unit	uac2_extension_unit_descriptor

	effect_unit	uac2_effect_unit_descriptor
	sample_rate	uac2_sample_rate_descriptor
	source_unit	uac2_clock_source_descriptor
	multiply_unit	uac2_clock_multiplier_descriptor
] [varlen]

uac2_input_terminal_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubtype	const[UAC_INPUT_TERMINAL, int8]

	bTerminalID		uac_id
	wTerminalType		flags[uac_input_terminal_types, int16]
	bAssocTerminal		uac_id
	bCSourceID		int8
	bNrChannels		int8
	bmChannelConfig		int32
	iChannelNames		int8
	bmControls		int8
	iTerminal		int8
} [packed]

uac2_output_terminal_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubtype	const[UAC_OUTPUT_TERMINAL, int8]
	bTerminalID		uac_id
	wTerminalType		flags[uac_output_terminal_types, int16]
	bAssocTerminal		int8
	bSourceID		uac_id
	bCSourceID		int8
	bmControls		int16
	iTerminal		int8
} [packed]

uac2_mixer_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_MIXER_UNIT, int8]

	bUnitID			uac_id
	bNrInPins		int8
	baSourceID		array[int8, 0:6]
} [packed]

# TODO: Figure out if bmControls and iClockSelector should be a part of this structure.
uac2_clock_selector_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC2_CLOCK_SELECTOR, int8]
	bClockID		int8
	bNrInPins		len[baCSourceID, int8]
	baCSourceID		array[int8, 0:8]
} [packed]

# TODO: Verify coverage.
uac2_processing_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubtype	const[UAC2_PROCESSING_UNIT_V2, int8]
	bUnitID			uac_id
	bSourceID		uac_id
	bmaControls		array[flags[uac2_processing_unit_types, int16], 1:6]
} [packed]

uac2_processing_unit_types = UAC2_PROCESS_UNDEFINED, UAC2_PROCESS_UP_DOWNMIX, UAC2_PROCESS_DOLBY_PROLOCIC, UAC2_PROCESS_STEREO_EXTENDER

uac2_extension_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC2_EXTENSION_UNIT_V2, int8]

	bUnitID			uac_id
	wProcessType		int16
	bNrInPins		int8
	baSourceID		array[int8, 0:6]
} [packed]

# TODO: Verify coverage.
uac2_effect_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubtype	const[UAC2_EFFECT_UNIT, int8]
	bUnitID			uac_id
	wEffectType		flags[uac2_effect_unit_types, int16]
	bSourceID		uac_id
	bmaControls		array[flags[uac2_processing_unit_types, int16], 1:6]
} [packed]

uac2_effect_unit_types = UAC2_EFFECT_UNDEFINED, UAC2_EFFECT_PARAM_EQ, UAC2_EFFECT_REVERB, UAC2_EFFECT_MOD_DELAY, UAC2_EFFECT_DYN_RANGE_COMP

uac2_sample_rate_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubtype	const[UAC2_SAMPLE_RATE_CONVERTER, int8]
	bUnitID			uac_id
	wProcessType		flags[uac2_processing_unit_types, int16]
	bSourceID		uac_id
	bmaControls		array[flags[uac2_processing_unit_types, int16], 1:6]
} [packed]

uac2_feature_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubtype	const[UAC_FEATURE_UNIT, int8]
	bUnitID			uac_id
	bSourceID		uac_id
	bmaControls		array[flags[uac2_feature_unit_controls, int16], 1:6]
} [packed]

uac2_clock_source_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC2_CLOCK_SOURCE, int8]
	bClockID		int8
	bmAttributes		flags[uac2_clock_bmattribute_types, int8]
	bmControls		int8
	bAssocTerminal		int8
	iClockSource		flags[uac2_clock_source_types, int8]
} [packed]

uac2_clock_bmattribute_types = UAC_CLOCK_SOURCE_TYPE_EXT, UAC_CLOCK_SOURCE_TYPE_INT_FIXED, UAC_CLOCK_SOURCE_TYPE_INT_VAR, UAC_CLOCK_SOURCE_TYPE_INT_PROG, UAC_CLOCK_SOURCE_SYNCED_TO_SOF
uac2_clock_source_types = UAC_CLOCK_SOURCE_TYPE_EXT, UAC_CLOCK_SOURCE_TYPE_INT_FIXED, UAC_CLOCK_SOURCE_TYPE_INT_VAR, UAC_CLOCK_SOURCE_TYPE_INT_PROG, UAC_CLOCK_SOURCE_SYNCED_TO_SOF

uac2_clock_multiplier_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC2_CLOCK_MULTIPLIER, int8]
	bClockID		int8
	bCSourceID		int8
	bmControls		int8
	iClockMultiplier	int8
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# UAC3 device class specific descriptions.
# https://www.usb.org/sites/default/files/audio10.pdf
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/legacy/audio.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/function/f_uac3.c
# https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/usb/audio.h

resource fd_usb_uac3[fd_usb]

syz_usb_connect$uac3(speed flags[usb_device_speed], dev_len len[dev], dev ptr[in, usb_device_descriptor_uac3], conn_descs ptr[in, vusb_connect_descriptors]) fd_usb_uac3 (timeout[3000], prog_timeout[3000], remote_cover)
syz_usb_control_io$uac3(fd fd_usb_uac3, descs ptr[in, vusb_descriptors_uac1], resps ptr[in, vusb_responses_uac1]) (timeout[300], remote_cover)

usb_device_descriptor_uac3 {
	inner	usb_device_descriptor_t[0, 0, 0, 0x582, 0x582, 64, array[usb_config_descriptor_uac3, 1]]
} [packed]

usb_config_descriptor_uac3 {
	inner	usb_config_descriptor_extra_t[const[1, int8], const[3, int8], uac3_interface_assoc_descriptor, usb_interface_descriptors_uac3]
} [packed]

uac3_interface_assoc_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_INTERFACE_ASSOCIATION, int8]

	bFirstInterface		int8[0:2]
	bInterfaceCount		int8[0:2]
	bFunctionClass		const[USB_CLASS_AUDIO, int8]
	bFunctionSubClass	flags[uac3_all_subclasses, int8]
	bFunctionProtocol	const[UAC_VERSION_3, int8]
	iFunction		int8
} [packed]

usb_interface_descriptors_uac3 {
	inner	usb_interface_descriptors_uac3_inner
} [packed]

# Define folded-in structure to match layout expected by USB ID patching code.
usb_interface_descriptors_uac3_inner {
	control		usb_interface_descriptor_fixed_t[0, 0, 0, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOCONTROL, UAC_VERSION_3, uac3_control_iface_extra_descriptors, void]
	as_out_alt_0	usb_interface_descriptor_fixed_t[1, 0, 0, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOSTREAMING, UAC_VERSION_3, void, void]
	as_out_alt_1	usb_interface_descriptor_fixed_t[1, 1, 1, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOSTREAMING, UAC_VERSION_3, uac3_as_iface_extra_descriptors, uac3_as_out_endpoint_descriptor]
	as_in_alt_0	usb_interface_descriptor_fixed_t[2, 0, 0, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOSTREAMING, UAC_VERSION_3, void, void]
	as_in_alt_1	usb_interface_descriptor_fixed_t[2, 1, 1, USB_CLASS_AUDIO, USB_SUBCLASS_AUDIOSTREAMING, UAC_VERSION_3, uac3_as_iface_extra_descriptors, uac3_as_in_endpoint_descriptor]
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

uac3_control_iface_extra_descriptors {
	header	uac3_ac_header_descriptor
	others	array[uac3_control_iface_extra_descriptor, 0:6]
} [packed]

uac3_ac_header_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_MS_HEADER, int8]

	bCategory		flags[uac3_feature_unit_controls, int8]
	wTotalLength		len[uac3_control_iface_extra_descriptors, int16]
	bmControls		int32
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

uac3_as_iface_extra_descriptors {
	others	array[uac3_as_iface_extra_descriptor, 0:6]
} [packed]

uac3_as_iface_extra_descriptor [
	as_header			uac3_as_header_descriptor
	format_type_i_descriptor	uac2_format_type_i_descriptor
	format_type_i_continuous	uac_format_type_i_continuous_descriptor
	format_type_i_discrete		uac_format_type_i_discrete_descriptor
	format_type_ii_discrete		uac_format_type_ii_discrete_descriptor
	format_type_i_ext		uac2_format_type_i_ext_descriptor
	format_type_ii_ext		uac_format_type_ii_ext_descriptor
] [varlen]

# TODO: Figure out how wClusterDescrID is used in the kernel.
uac3_as_header_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_AS_GENERAL, int8]
	bTerminalLink		int8

	bmControls		int32
	wClusterDescrID		int16

	bmFormats		flags[uac_format_tags, int64]

	bSubslotSize		int8
	bBitResolution		int8
	bmAuxProtocols		int16
	bControlSize		int8
} [packed]

uac3_as_out_endpoint_descriptor {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_UAC1_AS_OUT_ADDRESS, int8], const[USB_ENDPOINT_UAC1_AS_ATTRIBUTES, int8], uac3_iso_endpoint_descriptor]
} [packed]

uac3_as_in_endpoint_descriptor {
	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_UAC1_AS_IN_ADDRESS, int8], const[USB_ENDPOINT_UAC1_AS_ATTRIBUTES, int8], uac3_iso_endpoint_descriptor]
} [packed]

uac3_iso_endpoint_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_ENDPOINT, int8]
	bDescriptorSubType	const[UAC3_CS_ENDPOINT, int8]
	bmControls		int32
	bLockDelayUnits		int8
	wLockDelay		int16
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

uac3_control_iface_extra_descriptor [
	input_terminal		uac3_input_terminal_descriptor
	output_terminal		uac3_output_terminal_descriptor
	mixer_unit		uac3_mixer_unit_descriptor
	selector_unit		uac3_clock_selector_descriptor
	source_unit		uac3_clock_source_descriptor
	multiply_unit		uac3_clock_multiplier_descriptor
	feature_unit		uac3_feature_unit_descriptor
	processing_unit		uac3_processing_unit_descriptor
	extension_unit		uac3_extension_unit_descriptor
	power_domain		uac3_power_domain_descriptor
	cluster_info_segment	uac3_cluster_information_segment_descriptor
# Only cluster information segment is currently used in the kernel.See: sound/usb/stream.c
# cluster_segment 		uac3_cluster_segment_descriptor
# cluster_end_segment		uac3_cluster_end_segment_descriptor
# The following units are not yet supported by the kernel.
# See audio_validators[] in sound/usb/validate.c:
#	effect_unit 		uac3_effect_unit_descriptor
#	sample_rate			uac3_sample_rate_descriptor
#	connectors_unit		uac3_connectors_unit_descriptor
#	extended_term_unit	uac3_extended_terminal_unit
] [varlen]

uac3_input_terminal_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubtype	const[UAC_INPUT_TERMINAL, int8]

	bTerminalID		uac_id
	wTerminalType		flags[uac_input_terminal_types, int16]
	bAssocTerminal		uac_id
	bCSourceID		int8

	bmControls		int32
	wClusterDescrID		int16
	wExTerminalDescrID	int16
	wConnectorsDescrID	int16
	wTerminalDescrStr	int16
} [packed]

uac3_output_terminal_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubtype	const[UAC_OUTPUT_TERMINAL, int8]

	bTerminalID		uac_id
	wTerminalType		flags[uac_output_terminal_types, int16]
	bAssocTerminal		uac_id
	bSourceID		uac_id
	bCSourceID		int8

	bmControls		int32
	wExTerminalDescrID	int16
	wConnectorsDescrID	int16
	wTerminalDescrStr	int16
} [packed]

uac3_mixer_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC3_MIXER_UNIT, int8]

	bUnitID			uac_id
	bNrInPins		int8
	baSourceID		array[int8, 0:6]
} [packed]

uac3_clock_selector_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC3_CLOCK_SELECTOR, int8]
	bClockID		int8
	bNrInPins		len[baCSourceID, int8]
	baCSourceID		array[int8, 0:8]
} [packed]

uac3_clock_source_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC3_CLOCK_SOURCE, int8]
	bClockID		int8
	bmAttributes		flags[uac3_clock_bmattribute_types, int8]
	bmControls		int32
	bReferenceTerminal	int8
	wClockSourceStr		int16
} [packed]

uac3_clock_bmattribute_types = UAC3_CLOCK_SOURCE_TYPE_EXT, UAC3_CLOCK_SOURCE_TYPE_INT, UAC3_CLOCK_SOURCE_ASYNC, UAC3_CLOCK_SOURCE_SYNCED_TO_SOF

uac3_clock_multiplier_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC3_CLOCK_MULTIPLIER, int8]
	bClockID		int8
	bCSourceID		int8
	bmControls		int32
	wCMultiplierDescrStr	int16
} [packed]

uac3_feature_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubtype	const[UAC3_FEATURE_UNIT, int8]
	bUnitID			uac_id
	bSourceID		uac_id
	bmaControls		array[flags[uac3_feature_unit_controls, int32], 1:6]
} [packed]

uac3_processing_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubtype	const[UAC3_PROCESSING_UNIT, int8]
	bUnitID			uac_id
	bSourceID		uac_id
	bmaControls		array[flags[uac3_processing_unit_types, int32], 1:6]
} [packed]

uac3_processing_unit_types = UAC3_PROCESS_UNDEFINED, UAC3_PROCESS_UP_DOWNMIX, UAC3_PROCESS_STEREO_EXTENDER, UAC3_PROCESS_MULTI_FUNCTION

uac3_extension_unit_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubtype	const[UAC3_EXTENSION_UNIT, int8]
	bUnitID			uac_id
	bSourceID		uac_id
	bmaControls		array[flags[uac3_processing_unit_types, int32], 1:6]
} [packed]

uac3_power_domain_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC3_POWER_DOMAIN, int8]

	bPowerDomainID		int8
	waRecoveryTime1		int16
	waRecoveryTime2		int16
	bNrEntities		int8
	baEntityID		array[int8, 0:8]
} [packed]

uac3_cluster_information_segment_descriptor {
	bLength		len[parent, int16]
	bSegmentType	const[UAC3_CHANNEL_INFORMATION, int8]
	bChPurpose	flags[uac3_cluster_channel_purposes, int8]
	bChRelationship	flags[uac3_cluster_channel_relationships, int8]
	bChGroupID	int8
} [packed]

uac3_cluster_channel_purposes = UAC3_PURPOSE_UNDEFINED, UAC3_PURPOSE_GENERIC_AUDIO, UAC3_PURPOSE_VOICE, UAC3_PURPOSE_SPEECH, UAC3_PURPOSE_AMBIENT, UAC3_PURPOSE_REFERENCE, UAC3_PURPOSE_ULTRASONIC, UAC3_PURPOSE_VIBROKINETIC, UAC3_PURPOSE_NON_AUDIO
uac3_cluster_channel_relationships = UAC3_CH_RELATIONSHIP_UNDEFINED, UAC3_CH_MONO, UAC3_CH_LEFT, UAC3_CH_RIGHT, UAC3_CH_ARRAY, UAC3_CH_PATTERN_X, UAC3_CH_PATTERN_Y, UAC3_CH_PATTERN_A, UAC3_CH_PATTERN_B, UAC3_CH_PATTERN_M, UAC3_CH_PATTERN_S, UAC3_CH_FRONT_LEFT, UAC3_CH_FRONT_RIGHT, UAC3_CH_FRONT_CENTER, UAC3_CH_FRONT_LEFT_OF_CENTER, UAC3_CH_FRONT_RIGHT_OF_CENTER, UAC3_CH_FRONT_WIDE_LEFT, UAC3_CH_FRONT_WIDE_RIGHT, UAC3_CH_SIDE_LEFT, UAC3_CH_SIDE_RIGHT, UAC3_CH_SURROUND_ARRAY_LEFT, UAC3_CH_SURROUND_ARRAY_RIGHT, UAC3_CH_BACK_LEFT, UAC3_CH_BACK_RIGHT, UAC3_CH_BACK_CENTER, UAC3_CH_BACK_LEFT_OF_CENTER, UAC3_CH_BACK_RIGHT_OF_CENTER, UAC3_CH_BACK_WIDE_LEFT, UAC3_CH_BACK_WIDE_RIGHT, UAC3_CH_TOP_CENTER, UAC3_CH_TOP_FRONT_LEFT, UAC3_CH_TOP_FRONT_RIGHT, UAC3_CH_TOP_FRONT_CENTER, UAC3_CH_TOP_FRONT_LOC, UAC3_CH_TOP_FRONT_ROC, UAC3_CH_TOP_FRONT_WIDE_LEFT, UAC3_CH_TOP_FRONT_WIDE_RIGHT, UAC3_CH_TOP_SIDE_LEFT, UAC3_CH_TOP_SIDE_RIGHT, UAC3_CH_TOP_SURR_ARRAY_LEFT, UAC3_CH_TOP_SURR_ARRAY_RIGHT, UAC3_CH_TOP_BACK_LEFT, UAC3_CH_TOP_BACK_RIGHT, UAC3_CH_TOP_BACK_CENTER, UAC3_CH_TOP_BACK_LOC, UAC3_CH_TOP_BACK_ROC, UAC3_CH_TOP_BACK_WIDE_LEFT, UAC3_CH_TOP_BACK_WIDE_RIGHT, UAC3_CH_BOTTOM_CENTER, UAC3_CH_BOTTOM_FRONT_LEFT, UAC3_CH_BOTTOM_FRONT_RIGHT, UAC3_CH_BOTTOM_FRONT_CENTER, UAC3_CH_BOTTOM_FRONT_LOC, UAC3_CH_BOTTOM_FRONT_ROC, UAC3_CH_BOTTOM_FRONT_WIDE_LEFT, UAC3_CH_BOTTOM_FRONT_WIDE_RIGHT, UAC3_CH_BOTTOM_SIDE_LEFT, UAC3_CH_BOTTOM_SIDE_RIGHT, UAC3_CH_BOTTOM_SURR_ARRAY_LEFT, UAC3_CH_BOTTOM_SURR_ARRAY_RIGHT, UAC3_CH_BOTTOM_BACK_LEFT, UAC3_CH_BOTTOM_BACK_RIGHT, UAC3_CH_BOTTOM_BACK_CENTER, UAC3_CH_BOTTOM_BACK_LOC, UAC3_CH_BOTTOM_BACK_ROC, UAC3_CH_BOTTOM_BACK_WIDE_LEFT, UAC3_CH_BOTTOM_BACK_WIDE_RIGHT, UAC3_CH_LOW_FREQUENCY_EFFECTS, UAC3_CH_LFE_LEFT, UAC3_CH_LFE_RIGHT, UAC3_CH_HEADPHONE_LEFT, UAC3_CH_HEADPHONE_RIGHT

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# This list consists of uac3_func_subclasses + uac3_badd_classes.
uac3_all_subclasses = UAC3_FUNCTION_SUBCLASS_UNDEFINED, UAC3_FUNCTION_SUBCLASS_FULL_ADC_3_0, UAC3_FUNCTION_SUBCLASS_GENERIC_IO, UAC3_FUNCTION_SUBCLASS_HEADPHONE, UAC3_FUNCTION_SUBCLASS_SPEAKER, UAC3_FUNCTION_SUBCLASS_MICROPHONE, UAC3_FUNCTION_SUBCLASS_HEADSET, UAC3_FUNCTION_SUBCLASS_HEADSET_ADAPTER, UAC3_FUNCTION_SUBCLASS_SPEAKERPHONE

uac3_feature_unit_controls = UAC3_FUNCTION_SUBCLASS_UNDEFINED, UAC3_FUNCTION_DESKTOP_SPEAKER, UAC3_FUNCTION_HOME_THEATER, UAC3_FUNCTION_MICROPHONE, UAC3_FUNCTION_HEADSET, UAC3_FUNCTION_TELEPHONE, UAC3_FUNCTION_CONVERTER, UAC3_FUNCTION_SOUND_RECORDER, UAC3_FUNCTION_IO_BOX, UAC3_FUNCTION_MUSICAL_INSTRUMENT, UAC3_FUNCTION_PRO_AUDIO, UAC3_FUNCTION_AUDIO_VIDEO, UAC3_FUNCTION_CONTROL_PANEL, UAC3_FUNCTION_HEADPHONE, UAC3_FUNCTION_GENERIC_SPEAKER, UAC3_FUNCTION_HEADSET_ADAPTER, UAC3_FUNCTION_SPEAKERPHONE, UAC3_FUNCTION_OTHER

# TODO: Support uac3 badd profiles. See sound/usb/mixer.c: snd_usb_mixer_controls_badd()
# uac3_badd_endpoint_descriptor {
# 	inner	usb_endpoint_descriptor_t[const[USB_ENDPOINT_UAC1_AS_OUT_ADDRESS, int8], const[USB_ENDPOINT_UAC1_AS_ATTRIBUTES, int8], uac3_iso_endpoint_descriptor]
# } [packed]

#uac3_badd_maxsizes = UAC3_BADD_EP_MAXPSIZE_SYNC_MONO_16,UAC3_BADD_EP_MAXPSIZE_ASYNC_MONO_16,UAC3_BADD_EP_MAXPSIZE_SYNC_MONO_24,UAC3_BADD_EP_MAXPSIZE_ASYNC_MONO_24,UAC3_BADD_EP_MAXPSIZE_SYNC_STEREO_16,UAC3_BADD_EP_MAXPSIZE_ASYNC_STEREO_16,UAC3_BADD_EP_MAXPSIZE_SYNC_STEREO_24,UAC3_BADD_EP_MAXPSIZE_ASYNC_STEREO_24

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# MIDI device class specific descriptions.
# https://www.usb.org/sites/default/files/midi10.pdf
# https://elixir.bootlin.com/linux/latest/source/sound/usb/midi.c
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/function/f_midi.c

syz_usb_connect$midi(speed flags[usb_device_speed], dev_len len[dev], dev ptr[in, usb_device_descriptor_midi], conn_descs ptr[in, vusb_connect_descriptors]) fd_usb (timeout[3000], prog_timeout[3000], remote_cover)

usb_device_descriptor_midi {
	inner	usb_device_descriptor_t[0, 0, 0, 0x1430, 0x474b, 64, array[usb_config_descriptor_midi, 1]]
} [packed]

usb_config_descriptor_midi {
	inner	usb_config_descriptor_t[const[1, int8], const[1, int8], usb_interface_descriptors_midi]
} [packed]

usb_interface_descriptors_midi {
	inner	usb_interface_descriptors_midi_inner
} [packed]

# Define folded-in structure to match layout expected by USB ID patching code.
usb_interface_descriptors_midi_inner {
	control	usb_interface_descriptor_eps_array_t[const[0, int8], const[0, int8], const[USB_CLASS_AUDIO, int8], const[USB_SUBCLASS_MIDISTREAMING, int8], flags[uac_version_types, int8], array[usb_midi_iface_extra], array[usb_endpoint_descriptor_midi, 0:8]]
} [packed]

usb_endpoint_descriptor_midi {
	inner	usb_endpoint_descriptor_t[flags[usb_endpoint_addresses, int8], flags[usb_endpoint_attributes, int8], usb_ms_endpoint_descriptor]
} [packed]

midi_jack_type = USB_MS_EMBEDDED, USB_MS_EXTERNAL
uac_version_types = UAC_VERSION_1, UAC_VERSION_2, UAC_VERSION_3

usb_ms_endpoint_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_ENDPOINT, int8]
	bDescriptorSubType	const[USB_MS_GENERAL, int8]
	bNumEmbMIDIJack		len[baAssocJackID, int8]
	baAssocJackID		array[int8, 0:16]
} [packed]

usb_midi_iface_extra [
	ms_header	usb_ms_header_descriptor
	midi_in_jack	usb_midi_in_jack_descriptor
	midi_out_jack	usb_midi_out_jack_descriptor
] [varlen]

usb_ms_header_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_HEADER, int8]
	bcdMSC			int16
	wTotalLength		len[parent, int16]
} [packed]

usb_midi_in_jack_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_MIDI_IN_JACK, int8]
	bJackType		flags[midi_jack_type, int8]
	bJackID			int8
	iJack			int8
} [packed]

usb_midi_out_jack_descriptor {
	bLength			len[parent, int8]
	bDescriptorType		const[USB_DT_CS_INTERFACE, int8]
	bDescriptorSubType	const[UAC_MIDI_OUT_JACK, int8]
	bJackType		flags[midi_jack_type, int8]
	bJackID			int8
	bNrInputPins		len[pins, int8]
	pins			array[usb_midi_source_pin]
	iJack			int8
} [packed]

usb_midi_source_pin {
	baSourceID	int8
	baSourcePin	int8
} [packed]

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# ath9k driver specific descriptions.

include <drivers/net/wireless/ath/ath9k/htc_hst.h>
include <drivers/net/wireless/ath/ath9k/hif_usb.h>

define USB_ENDPOINT_ATH9K_BULK_OUT_ADDRESS	(1)
define USB_ENDPOINT_ATH9K_BULK_IN_ADDRESS	(2 | USB_DIR_IN)
define USB_ENDPOINT_ATH9K_INT_IN_ADDRESS	(3 | USB_DIR_IN)
define USB_ENDPOINT_ATH9K_INT_OUT_ADDRESS	(4)
define USB_ENDPOINT_ATH9K_BULK_EXTRA1_ADDRESS	(5)
define USB_ENDPOINT_ATH9K_BULK_EXTRA2_ADDRESS	(6)

resource fd_usb_ath9k[fd_usb]

syz_usb_connect_ath9k(speed const[USB_SPEED_HIGH], dev_len len[dev], dev ptr[in, usb_device_descriptor_ath9k], conn_descs const[0]) fd_usb_ath9k (timeout[3000], prog_timeout[3000], remote_cover)
syz_usb_ep_write$ath9k_ep1(fd fd_usb_ath9k, ep const[USB_ENDPOINT_ATH9K_BULK_IN_ADDRESS], len bytesize[data], data ptr[in, ath9k_bulk_frame]) (timeout[300], remote_cover)
syz_usb_ep_write$ath9k_ep2(fd fd_usb_ath9k, ep const[USB_ENDPOINT_ATH9K_INT_IN_ADDRESS], len bytesize[data], data ptr[in, htc_frame]) (timeout[300], remote_cover)

usb_device_descriptor_ath9k {
	inner	usb_device_descriptor_fixed_t[0x200, USB_CLASS_VENDOR_SPEC, USB_SUBCLASS_VENDOR_SPEC, 0xff, 64, 0xcf3, 0x9271, 0x108, array[usb_config_descriptor_ath9k, 1]]
} [packed]

usb_config_descriptor_ath9k {
	inner	usb_config_descriptor_fixed_t[1, 1, USB_CONFIG_ATT_ONE, 250, usb_interface_descriptor_ath9k]
} [packed]

usb_interface_descriptor_ath9k {
	iface	usb_interface_descriptor_fixed_t[0, 0, 6, USB_CLASS_VENDOR_SPEC, 0, 0, void, usb_endpoint_descriptors_ath9k]
} [packed]

usb_endpoint_descriptors_ath9k {
	bulk_out	usb_endpoint_descriptor_fixed_t[USB_ENDPOINT_ATH9K_BULK_OUT_ADDRESS, USB_ENDPOINT_ATH9K_BULK_ATTRIBUTES, 512, 0, void]
	bulk_in		usb_endpoint_descriptor_fixed_t[USB_ENDPOINT_ATH9K_BULK_IN_ADDRESS, USB_ENDPOINT_ATH9K_BULK_ATTRIBUTES, 512, 0, void]
	int_in		usb_endpoint_descriptor_fixed_t[USB_ENDPOINT_ATH9K_INT_IN_ADDRESS, USB_ENDPOINT_ATH9K_INT_ATTRIBUTES, 64, 1, void]
	int_out		usb_endpoint_descriptor_fixed_t[USB_ENDPOINT_ATH9K_INT_OUT_ADDRESS, USB_ENDPOINT_ATH9K_INT_ATTRIBUTES, 64, 1, void]
	bulk_extra1	usb_endpoint_descriptor_fixed_t[USB_ENDPOINT_ATH9K_BULK_EXTRA1_ADDRESS, USB_ENDPOINT_ATH9K_BULK_ATTRIBUTES, 512, 0, void]
	bulk_extra2	usb_endpoint_descriptor_fixed_t[USB_ENDPOINT_ATH9K_BULK_EXTRA2_ADDRESS, USB_ENDPOINT_ATH9K_BULK_ATTRIBUTES, 512, 0, void]
} [packed]

define USB_ENDPOINT_ATH9K_BULK_ATTRIBUTES	(USB_ENDPOINT_XFER_BULK)
define USB_ENDPOINT_ATH9K_INT_ATTRIBUTES	(USB_ENDPOINT_XFER_INT)

ath9k_bulk_frame {
	packets	array[ath9k_bulk_packet]
} [packed]

ath9k_bulk_packet {
	pkt_len	len[data, int16]
	pkt_tag	const[ATH_USB_RX_STREAM_MODE_TAG, int16]
	data	array[int8]
} [packed, align[4]]

htc_frame [
	ready		htc_ready_frame
	conn_svc_rsp	htc_conn_svc_rsp_frame
	generic		htc_generic_frame
] [varlen]

# This is actually wrong, as the driver is buggy and doesn't skip the header
# before processing the frame payload, but let's leave it like thise for now.
htc_ready_frame {
	endpoint_id	const[0, int8]
	flags		const[0, int8]
	payload_len	len[payload, int16be]
	control		array[int8, 4]
	payload		htc_ready_msg
} [packed]

htc_ready_msg {
	message_id	const[HTC_MSG_READY_ID, int16be]
	credits		int16be
	credit_size	int16be
	max_endpoints	int8
	pad		int8
} [packed]

htc_conn_svc_rsp_frame {
	endpoint_id	const[0, int8]
	flags		const[0, int8]
	payload_len	len[payload, int16be]
	control		array[int8, 4]
	payload		htc_conn_svc_rspmsg
} [packed]

htc_conn_svc_rspmsg {
	message_id	const[HTC_MSG_CONNECT_SERVICE_RESPONSE_ID, int16be]
	service_id	flags[htc_svcs, int16be]
	status		const[HTC_SERVICE_SUCCESS, int8]
	endpoint_id	int8
	max_msg_len	int16be
	svc_meta_len	int8
	pad		int8
} [packed]

htc_svcs = HTC_CTRL_RSVD_SVC, HTC_LOOPBACK_RSVD_SVC, WMI_CONTROL_SVC, WMI_BEACON_SVC, WMI_CAB_SVC, WMI_UAPSD_SVC, WMI_MGMT_SVC, WMI_DATA_VO_SVC, WMI_DATA_VI_SVC, WMI_DATA_BE_SVC, WMI_DATA_BE_SVC

htc_generic_frame {
	endpoint_id	int8[0:8]
	flags		flags[htc_frame_flags, int8]
	payload_len	len[payload, int16be]
	control		array[int8, 4]
	payload		array[int8, 0:256]
} [packed]

htc_frame_flags = HTC_FLAGS_RECV_TRAILER

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# Assorted driver-specific descriptions of generic syz_* calls' variants.

# Generic calls such as syz_usb_connect() and syz_usb_control_io() should be enough
# (in theory) to emulate a proper device and finish driver probes without a hitch.
# However, there are cases when syzkaller fails to come up with correct inputs to achieve it.
# Use fixed descriptors to quickly pass through probe() to access select drivers' post-probe functionality.

# It is important to note that, one way or another, drivers in question require multiple control requests
# between a driver and a device processed during probe(). Descriptions below do not deal with specific
# CTRL requests as such (except for basic information included in vusb_responses_XXX). Instead, rely on
# seeds, created both manually and with syzkaller's help. For examples, see sys/linux/test/vusb_XXX.

# Common constants for endpoint descriptors.
define USB_ENDPOINT_BULK_ATTR	(USB_ENDPOINT_XFER_BULK)
define USB_ENDPOINT_INT_ATTR	(USB_ENDPOINT_XFER_INT)

define USB_FIXED_ENDPOINT_BULK_IN_ADDR	(1 | USB_DIR_IN)
define USB_FIXED_ENDPOINT_BULK_OUT_ADDR	(2)
define USB_FIXED_ENDPOINT_INT_IN_ADDR	(3 | USB_DIR_IN)

define USB_RECIP_DEVICE	0x00

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# rtl8150 driver specific descriptions.

resource fd_usb_rtl8150[fd_usb]

syz_usb_connect$rtl8150(speed flags[usb_device_speed], dev_len len[dev], dev ptr[in, usb_device_descriptor_rtl8150], conn_descs const[0]) fd_usb_rtl8150 (timeout[3000], prog_timeout[3000], remote_cover)
syz_usb_control_io$rtl8150(fd fd_usb_rtl8150, descs ptr[in, vusb_descriptors_rtl8150], resps ptr[in, vusb_responses_rtl8150]) (timeout[300], remote_cover)

usb_device_descriptor_rtl8150 {
	inner	usb_device_descriptor_fixed_t[0x200, USB_CLASS_VENDOR_SPEC, USB_SUBCLASS_VENDOR_SPEC, 0xff, 64, 0xbda, 0x8150, 0, array[usb_config_descriptor_rtl8150, 1]]
} [packed]

usb_config_descriptor_rtl8150 {
	inner	usb_config_descriptor_fixed_t[1, 1, USB_CONFIG_ATT_ONE, 250, usb_interface_descriptor_rtl8150]
} [packed]

usb_interface_descriptor_rtl8150 {
	iface	usb_interface_descriptor_fixed_t[0, 0, 3, USB_CLASS_VENDOR_SPEC, 0, 0, void, usb_endpoint_descriptors_rtl8150]
} [packed]

usb_endpoint_descriptors_rtl8150 {
	bulk_in		usb_endpoint_descriptor_fixed_t[USB_FIXED_ENDPOINT_BULK_IN_ADDR, USB_ENDPOINT_BULK_ATTR, 512, 0, void]
	bulk_out	usb_endpoint_descriptor_fixed_t[USB_FIXED_ENDPOINT_BULK_OUT_ADDR, USB_ENDPOINT_BULK_ATTR, 512, 0, void]
	int_in		usb_endpoint_descriptor_fixed_t[USB_FIXED_ENDPOINT_INT_IN_ADDR, USB_ENDPOINT_INT_ATTR, 64, 1, void]
} [packed]

vusb_descriptors_rtl8150 {
	len		len[parent, int32]
	generic		ptr[in, vusb_descriptor_generic]

	USB_DT_STRING	ptr[in, vusb_descriptor_t[USB_TYPE_STANDARD, USB_DT_STRING, usb_string_descriptor]]
} [packed]

vusb_responses_rtl8150 {
	len				len[parent, int32]
	generic				ptr[in, vusb_response_generic]

	USB_REQ_GET_INTERFACE		ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_INTERFACE, int8]]
	USB_REQ_GET_CONFIGURATION	ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_CONFIGURATION, int8]]

	RTL8150_REQ_GET_REGS		ptr[in, vusb_response_t[RTL8150_REQT_READ, RTL8150_REQ_GET_REGS, array[int8, 0:6]]]
	RTL8150_REQ_SET_REGS		ptr[in, vusb_response_t[RTL8150_REQT_WRITE, RTL8150_REQ_SET_REGS, array[int8, 0:6]]]
} [packed]

define RTL8150_REQ_GET_REGS	0x05
define RTL8150_REQ_SET_REGS	0x05
define RTL8150_REQT_READ	0xc0
define RTL8150_REQT_WRITE	0x40

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# sierra_net driver specific descriptions.

resource fd_usb_sierra_net[fd_usb]

syz_usb_connect$sierra_net(speed flags[usb_device_speed], dev_len len[dev], dev ptr[in, usb_device_descriptor_sierra_net], conn_descs const[0]) fd_usb_sierra_net (timeout[3000], prog_timeout[3000], remote_cover)
syz_usb_control_io$sierra_net(fd fd_usb_sierra_net, descs ptr[in, vusb_descriptors_sierra_net], resps ptr[in, vusb_responses_sierra_net]) (timeout[300], remote_cover)

usb_device_descriptor_sierra_net {
	inner	usb_device_descriptor_fixed_t[0x200, USB_CLASS_VENDOR_SPEC, USB_SUBCLASS_VENDOR_SPEC, 0xff, 64, 0x1199, 0x68a3, 0, array[usb_config_descriptor_sierra_net, 1]]
} [packed]

usb_config_descriptor_sierra_net {
	inner	usb_config_descriptor_fixed_t[1, 1, USB_CONFIG_ATT_ONE, 250, usb_interface_descriptor_sierra_net]
} [packed]

usb_interface_descriptor_sierra_net {
	iface	usb_interface_descriptor_fixed_t[7, 0, 3, USB_CLASS_VENDOR_SPEC, 0, 0, void, usb_endpoint_descriptors_sierra_net]
} [packed]

# sierra_net driver does not expect fixed ep addresses, so refrain from being too specific here.
# As long as we ensure there are 3 endpoints, 2 bulk and 1 int, syzkaller should figure it out.
usb_endpoint_descriptors_sierra_net {
	bulk_in		usb_endpoint_descriptor_t[flags[usb_endpoint_addresses, int8], const[USB_ENDPOINT_BULK_ATTR, int8], void]
	bulk_out	usb_endpoint_descriptor_t[flags[usb_endpoint_addresses, int8], const[USB_ENDPOINT_BULK_ATTR, int8], void]
	status		usb_endpoint_descriptor_t[flags[usb_endpoint_addresses, int8], const[USB_ENDPOINT_INT_ATTR, int8], void]
} [packed]

vusb_descriptors_sierra_net {
	len		len[parent, int32]
	generic		ptr[in, vusb_descriptor_generic]

	USB_DT_STRING	ptr[in, vusb_descriptor_t[USB_TYPE_STANDARD, USB_DT_STRING, usb_string_descriptor]]
} [packed]

vusb_responses_sierra_net {
	len					len[parent, int32]
	generic					ptr[in, vusb_response_generic]

	USB_CDC_GET_ENCAPSULATED_RESPONSE	ptr[in, vusb_response_t[SIERRA_CMD_TYPE_IN, USB_CDC_GET_ENCAPSULATED_RESPONSE, array[int8, 1024]]]
	USB_CDC_SEND_ENCAPSULATED_COMMANDT	ptr[in, vusb_response_t[SIERRA_CMD_TYPE_OUT, USB_CDC_SEND_ENCAPSULATED_COMMAND, array[int8, 0:4]]]
} [packed]

define SIERRA_CMD_TYPE_IN	(USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE)
define SIERRA_CMD_TYPE_OUT	(USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE)

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #

# lan78xx driver specific descriptions.
# While these syz_* variants noticably help with the probe() process, they are not enough.
# This is due to a high number of control requests expected between the driver and the device.

include <drivers/net/usb/smsc95xx.h>

resource fd_usb_lan78xx[fd_usb]

syz_usb_connect$lan78xx(speed flags[usb_device_speed], dev_len len[dev], dev ptr[in, usb_device_descriptor_lan78xx], conn_descs const[0]) fd_usb_lan78xx (timeout[3000], prog_timeout[3000], remote_cover)
syz_usb_control_io$lan78xx(fd fd_usb_lan78xx, descs ptr[in, vusb_descriptors_lan78xx], resps ptr[in, vusb_responses_lan78xx]) (timeout[300], remote_cover)

usb_device_descriptor_lan78xx {
	inner	usb_device_descriptor_fixed_t[0x200, USB_CLASS_VENDOR_SPEC, USB_SUBCLASS_VENDOR_SPEC, 0xff, 64, 0x424, 0x7850, 0, array[usb_config_descriptor_lan78xx, 1]]
} [packed]

usb_config_descriptor_lan78xx {
	inner	usb_config_descriptor_fixed_t[1, 1, USB_CONFIG_ATT_ONE, 250, usb_interface_descriptor_lan78xx]
} [packed]

usb_interface_descriptor_lan78xx {
	iface	usb_interface_descriptor_fixed_t[0, 0, 3, USB_CLASS_VENDOR_SPEC, 0, 0, void, usb_endpoint_descriptors_lan78xx]
} [packed]

usb_endpoint_descriptors_lan78xx {
	bulk_in		usb_endpoint_descriptor_fixed_t[USB_FIXED_ENDPOINT_BULK_IN_ADDR, USB_ENDPOINT_BULK_ATTR, 512, 0, void]
	bulk_out	usb_endpoint_descriptor_fixed_t[USB_FIXED_ENDPOINT_BULK_OUT_ADDR, USB_ENDPOINT_BULK_ATTR, 512, 0, void]
	int_in		usb_endpoint_descriptor_fixed_t[USB_FIXED_ENDPOINT_INT_IN_ADDR, USB_ENDPOINT_INT_ATTR, 64, 1, void]
} [packed]

vusb_descriptors_lan78xx {
	len		len[parent, int32]
	generic		ptr[in, vusb_descriptor_generic]

	USB_DT_STRING	ptr[in, vusb_descriptor_t[USB_TYPE_STANDARD, USB_DT_STRING, usb_string_descriptor]]
} [packed]

vusb_responses_lan78xx {
	len					len[parent, int32]
	generic					ptr[in, vusb_response_generic]

	USB_REQ_GET_INTERFACE			ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_INTERFACE, int8]]
	USB_REQ_GET_CONFIGURATION		ptr[in, vusb_response_t[USB_TYPE_STANDARD, USB_REQ_GET_CONFIGURATION, int8]]

	USB_VENDOR_REQUEST_READ_REGISTER	ptr[in, vusb_response_t[LAN78XX_REG_TYPE_IN, USB_VENDOR_REQUEST_READ_REGISTER, int32]]
	USB_VENDOR_REQUEST_WRITE_REGISTER	ptr[in, vusb_response_t[LAN78XX_REG_TYPE_OUT, USB_VENDOR_REQUEST_WRITE_REGISTER, int32]]
	USB_VENDOR_REQUEST_GET_STATS		ptr[in, vusb_response_t[LAN78XX_REG_TYPE_IN, USB_VENDOR_REQUEST_GET_STATS, array[int8, 47]]]
} [packed]

define LAN78XX_REG_TYPE_IN	(USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE)
define LAN78XX_REG_TYPE_OUT	(USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE)
]

gemini-3.1-pro-preview

							input: 128557
							output: 312
							thoughts: 4672
						

**Crafting a Reproducer for a USB Race Condition**

Okay, so I'm diving into this `vusb` stuff and trying to understand how to make a reproducer for a potential race condition in the `xpad` driver.  The initial idea was to leverage `syz_usb_connect`, but it seems that `init_vusb.go` is going to automatically patch the vendor and product IDs in the device descriptor if I use `syz_usb_connect`.  This means I can't directly specify the Xbox controller (0x045e, 0x028e) values in the syzlang program. I need to get around that patching and control the device descriptor bytes directly.

I realized I can bypass the struct and feed the raw bytes, since syzlang is flexible.  I can use `&AUTO` or a specific address like `&(0x7f0000000000)` and put the descriptor bytes there. I construct the device and configuration descriptors, carefully laying out the bytes to match the Xbox 360 wireless controller. I'm focusing on the `XTYPE_XBOX360W` type because the initial `irq_in` submission seems relevant here, and then it is time to write the program.

I'm aiming for a race condition between the device disconnection and the completion of data transfers initiated by the driver. I need `syz_usb_disconnect` to be called when xpad is doing something, which is a key part of the race.

The program will involve `syz_usb_connect`, followed by simulating the device sending data to the host (in other words, the emulator to the OS) using `syz_usb_ep_write`. Then, a `syz_usb_disconnect` is called right after.

Specifically, I’ll connect as an Xbox 360 wireless controller, emulate sending a 'presence' packet, and then immediately disconnect.  The presence packet triggers work queue tasks and calls into `xpad_presence_work`.  This calls `xpad_init_input`, and submits an `irq_out` URB. Now this is good because if the URB is submitted but NOT completed, and then `xpad_disconnect` is called, we might have a use-after-free.  This means by disconnecting right after sending the "presence" packet, I may be able to hit the race condition between `xpad_irq_out` (which can complete) and `syz_usb_disconnect` if I'm lucky.

The key is that the "presence" packet causes the driver to submit `irq_out` asynchronously.  `syz_usb_disconnect` then attempts to clean up the URB, if it's still pending.  This is a big race window. The goal is to make these two operations happen at the same time to induce a use-after-free!

wrong string arg
line #1:50: r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=<<<!!ERROR!!>>>'\x12\x01\x00\x02\xff\xff\xff\x40\x5e\x04\x91\x02\x14\x01\x01\x02\x03\x01\x09\x02\x20\x00\x01\x01\x00\x80\xfa\x09\x04\x00\x00\x02\xff\x5d\x81\x00\x07\x05\x81\x03\x20\x00\x04\x07\x05\x02\x03\x20\x00\x04', 0x0)

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)='\x12\x01\x00\x02\xff\xff\xff\x40\x5e\x04\x91\x02\x14\x01\x01\x02\x03\x01\x09\x02\x20\x00\x01\x01\x00\x80\xfa\x09\x04\x00\x00\x02\xff\x5d\x81\x00\x07\x05\x81\x03\x20\x00\x04\x07\x05\x02\x03\x20\x00\x04', 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 134435
							output: 314
							thoughts: 130
						

**String Literal Syntax in syzlang**

Okay, so I'm refreshing my memory on syzlang's string literal syntax. It's that `ANY="..."` or `ANY='...'` format, right? Let me double-check the documentation. Aha! It's actually a bit more nuanced than I initially thought. The documentation specifies: `pointer-arg = "&" pointer-arg-addr ["=ANY"] "=" arg` and `string-arg = "'" escaped-string "'" | "\"" escaped-string "\"" | "\"$" escaped-string "\""`.

So, if I'm interpreting this correctly, a pointer argument containing a string might look something like `&(0x7f0000000000)=ANY='\x12...'` or even `&(0x7f0000000000)=ANY="\x12..."`. I think that's the key. Let's try the latter one and see if it works as expected.

wrong string arg
line #1:54: r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=<<<!!ERROR!!>>>"\x12\x01\x00\x02\xff\xff\xff\x40\x5e\x04\x91\x02\x14\x01\x01\x02\x03\x01\x09\x02\x20\x00\x01\x01\x00\x80\xfa\x09\x04\x00\x00\x02\xff\x5d\x81\x00\x07\x05\x81\x03\x20\x00\x04\x07\x05\x02\x03\x20\x00\x04", 0x0)

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY="\x12\x01\x00\x02\xff\xff\xff\x40\x5e\x04\x91\x02\x14\x01\x01\x02\x03\x01\x09\x02\x20\x00\x01\x01\x00\x80\xfa\x09\x04\x00\x00\x02\xff\x5d\x81\x00\x07\x05\x81\x03\x20\x00\x04\x07\x05\x02\x03\x20\x00\x04", 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)=ANY="\x08\x80")
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 135357
							output: 284
							thoughts: 107
						

**Exploring Syzkaller's AUTO Keyword for Data Control**

Okay, so the documentation suggests that using the `AUTO` keyword in Syzkaller gives me, as the program, complete control over how data is stored. That's interesting. I see an example here:

```
r0 = openat(0xffffffffffffff9c, &AUTO='./file1\x00', 0x42, 0x1ff)
write(r0, &AUTO="01010101", 0x4)
```

Right, it's using `&AUTO` to specify the data directly. The first example opens a file. So, I need to figure out how `&AUTO` works and what I can do with it. My instinct is, instead of using a string constant, let's explore if I can influence the value that is stored. Let's try something different with that `&AUTO` syntax. Instead of `&AUTO="./file1\x00"`, I'll try `&AUTO="\x12..."` and experiment with a binary value there. I bet I can control the content of the data directly. Let's see if this gives me more control.

wrong string arg
line #1:38: r0 = syz_usb_connect(0x0, 0x32, &AUTO=<<<!!ERROR!!>>>"\x12\x01\x00\x02\xff\xff\xff\x40\x5e\x04\x91\x02\x14\x01\x01\x02\x03\x01\x09\x02\x20\x00\x01\x01\x00\x80\xfa\x09\x04\x00\x00\x02\xff\x5d\x81\x00\x07\x05\x81\x03\x20\x00\x04\x07\x05\x02\x03\x20\x00\x04", 0x0)

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &AUTO="\x12\x01\x00\x02\xff\xff\xff\x40\x5e\x04\x91\x02\x14\x01\x01\x02\x03\x01\x09\x02\x20\x00\x01\x01\x00\x80\xfa\x09\x04\x00\x00\x02\xff\x5d\x81\x00\x07\x05\x81\x03\x20\x00\x04\x07\x05\x02\x03\x20\x00\x04", 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &AUTO="\x08\x80")
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 136262
							output: 288
							thoughts: 104
						

**Analyzing the syz_usb_connect Function Call**

Okay, so I'm looking at `syz_usb_connect`. The function signature says it accepts a `dev ptr[in, usb_device_descriptor]`. My immediate thought is, if I'm trying to inject a string, can I just directly pass it as a struct pointer? That seems... incorrect.

Hold on, the documentation is key here. It explicitly states how to handle pointer arguments: `pointer-arg = "&" pointer-arg-addr ["=ANY"] "=" arg`. So, if I'm understanding this correctly, the correct format for passing a string to a pointer like this is `&AUTO=ANY="..."`.

Therefore, my best approach is to try `&AUTO=ANY="\x12..."` and see if that works.

wrong string arg
line #1:42: r0 = syz_usb_connect(0x0, 0x32, &AUTO=ANY=<<<!!ERROR!!>>>"\x12\x01\x00\x02\xff\xff\xff\x40\x5e\x04\x91\x02\x14\x01\x01\x02\x03\x01\x09\x02\x20\x00\x01\x01\x00\x80\xfa\x09\x04\x00\x00\x02\xff\x5d\x81\x00\x07\x05\x81\x03\x20\x00\x04\x07\x05\x02\x03\x20\x00\x04", 0x0)

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &AUTO=ANY="\x12\x01\x00\x02\xff\xff\xff\x40\x5e\x04\x91\x02\x14\x01\x01\x02\x03\x01\x09\x02\x20\x00\x01\x01\x00\x80\xfa\x09\x04\x00\x00\x02\xff\x5d\x81\x00\x07\x05\x81\x03\x20\x00\x04\x07\x05\x02\x03\x20\x00\x04", 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &AUTO=ANY="\x08\x80")
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 137081
							output: 316
							thoughts: 2280
						

**Analyzing USB Device Descriptor Initialization in Syzlang**

Okay, so I'm trying to figure out the most effective way to trigger a specific USB driver, xpad in this case, using syzlang and `syz_usb_connect`. My initial thought was to leverage the struct syntax directly, bypassing any potential random assignment, but I need to make sure I am following the structure correctly. The current approach involves the manual specification of the `usb_device_descriptor`.

Looking at the structure definition, I realized `CLASS`, `SUBCLASS`, `PROTOCOL`, `VENDOR`, `PRODUCT`, and `DEVICE` are defined as `const[0]`. This implies I *must* provide `0` for these fields. This poses a challenge, however, since providing `0` in the current configuration allows `init_vusb.go` to patch them randomly when the generic `syz_usb_connect` is called. Specifically, I'm trying to force `0x045e` and `0x0291` as the `idVendor` and `idProduct` respectively. This is associated with the xpad driver.

I considered `syz_usb_connect$xpad` which seems like the ideal solution, however it does not exist. Similarly, `usbfs` interactions via `dev_bus_usb.txt` are not useful, as they are for user-space drivers.

The current strategy involves crafting the raw byte representation of the descriptor and passing it as a string to the `syz_usb_connect` call. I first tried using the `&AUTO="..."` syntax, thinking the raw bytes would be a straightforward way to pass the data, however, the error "wrong string arg" appeared. A review of the documentation confirms that `\x` escapes are supported in syzlang strings, so the error must be elsewhere.

Looking at the `vusb.txt` signature, it seems that `usb_device_descriptor` is of type `struct`, therefore, can't be assigned a string literal in this way, which explains the `wrong string arg` error.

I've determined that due to the `const[0]` definitions of `idVendor` and `idProduct`, the parser requires the values to be zero. Providing anything other than `0` results in a parsing error. This makes it impossible to explicitly set the Vendor and Product IDs using a raw struct definition directly.

This is a key hurdle. The goal is to craft the descriptor, force the specific `idVendor` and `idProduct` for xpad, and guarantee that the correct USB driver will be triggered.

wrong int arg *prog.StructType
line #1:125: r0 = syz_usb_connect(0x0, 0x32, &AUTO={{0x12, 0x1, 0x200, 0x0, 0x0, 0x0, 0x40, 0x045e, 0x0291, 0x0, 0x1, 0x2, 0x3, 0x1, [{0x9<<<!!ERROR!!>>>, 0x2, 0x20, 0x1, 0x1, 0x0, 0x80, 0xfa, {0x9, 0x4, 0x0, 0x0, 0x2, 0xff, 0x5d, 0x81, 0x0, [], [{0x7, 0x5, 0x81, 0x3, 0x20, 0x4, 0x0, 0x0, []}, {0x7, 0x5, 0x02, 0x3, 0x20, 0x4, 0x0, 0x0, []}]}}]}}, 0x0)

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &AUTO={{0x12, 0x1, 0x200, 0x0, 0x0, 0x0, 0x40, 0x045e, 0x0291, 0x0, 0x1, 0x2, 0x3, 0x1, [{0x9, 0x2, 0x20, 0x1, 0x1, 0x0, 0x80, 0xfa, {0x9, 0x4, 0x0, 0x0, 0x2, 0xff, 0x5d, 0x81, 0x0, [], [{0x7, 0x5, 0x81, 0x3, 0x20, 0x4, 0x0, 0x0, []}, {0x7, 0x5, 0x02, 0x3, 0x20, 0x4, 0x0, 0x0, []}]}}]}}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 140552
							output: 314
							thoughts: 683
						

**Debugging a USB Configuration Descriptor**

Okay, the error's showing up at `0x9`. Let's break this down. Right, `usb_device_descriptor` contains an array of `usb_config_descriptor` instances.  And within that, the `usb_config_descriptor` has this `inner usb_config_descriptor_ifaces_array_t` structure.  That one's built on a few other types; `usb_config_descriptor_ifaces_array_t` expands to `usb_config_descriptor_t[NUM, len[interfaces, int8], IFS]`, which in turn, is a `usb_config_descriptor_verbose_t` instance with several fields: `bLength`, `bDescriptorType`, `wTotalLength`, `bNumInterfaces`, `bConfigurationValue`, `iConfiguration`, `bmAttributes`, `bMaxPower`, `extra`, and `interfaces`.

So, based on the structure, the correct initialization should look like this: `{0x9, 0x2, 0x20, 0x1, 0x1, 0x0, 0x80, 0xfa, @void, [...]}`. But wait, what's with the `void`? Ah, right! In syzlang, `void` fields are *omitted* in struct literals. Okay, so we check the `usb_config_descriptor_verbose_t` definition again to be sure: `bLength`, `bDescriptorType`, `wTotalLength`, `bNumInterfaces`, `bConfigurationValue`, `iConfiguration`, `bmAttributes`, `bMaxPower`, `extra`, and `interfaces`. If `extra` is `void`, it's not present. That means my initial thought, without the `@void`, is correct! `{0x9, 0x2, 0x20, 0x1, 0x1, 0x0, 0x80, 0xfa, [...]}`.

But the debugger's complaining about `0x9` – that's `bLength`. Why is it saying there's a problem with an integer argument there?  It's because `configs` is declared as an `array[usb_config_descriptor, 1]`. So that `usb_config_descriptor` I'm constructing needs to be wrapped inside an array literal. That means it should look like this: `[ { {0x9, 0x2, ...} } ]`. It *does* need to be an array, because of the `usb_config_descriptor`'s `inner usb_config_descriptor_ifaces_array_t`. So the array-wrapped structure is the way forward.  Let's try that!

wrong array arg *prog.BufferType
line #1:161: r0 = syz_usb_connect(0x0, 0x32, &AUTO={{0x12, 0x1, 0x200, 0x0, 0x0, 0x0, 0x40, 0x0, 0x0, 0x0, 0x1, 0x2, 0x3, 0x1, [{{0x9, 0x2, 0x20, 0x1, 0x1, 0x0, 0x80, 0xfa, [<<<!!ERROR!!>>>{{0x9, 0x4, 0x0, 0x0, 0x2, 0xff, 0x5d, 0x81, 0x0, [], [{{0x7, 0x5, 0x81, 0x3, 0x20, 0x4, 0x0, 0x0, []}}, {{0x7, 0x5, 0x02, 0x3, 0x20, 0x4, 0x0, 0x0, []}}]}}]}}]}}, 0x0)

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &AUTO={{0x12, 0x1, 0x200, 0x0, 0x0, 0x0, 0x40, 0x0, 0x0, 0x0, 0x1, 0x2, 0x3, 0x1, [{{0x9, 0x2, 0x20, 0x1, 0x1, 0x0, 0x80, 0xfa, [{{0x9, 0x4, 0x0, 0x0, 0x2, 0xff, 0x5d, 0x81, 0x0, [], [{{0x7, 0x5, 0x81, 0x3, 0x20, 0x4, 0x0, 0x0, []}}, {{0x7, 0x5, 0x02, 0x3, 0x20, 0x4, 0x0, 0x0, []}}]}}]}}]}}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 142470
							output: 416
							thoughts: 1578
						

**Dissecting USB Configuration and Targeting the xpad Driver**

Okay, let's break this down. I'm looking at `usb_config_descriptor_ifaces_array_t` and specifically the `IFS` field, which I know is an array of `usb_interface_descriptor` instances, ranging from 1 to 4 elements. So `[ { {0x9, 0x4, ...} } ]` seems correct at first glance. However, there's an error: "wrong array arg *prog.BufferType." I'm diving deeper into the definitions.

The `extra` field, which looks like `void` in some contexts, is defined as `void` in `usb_config_descriptor_t`, but in `usb_interface_descriptor_t`, it seems to be defined as `int8`, which then gets passed as `EXTRA` to the verbose type. Confusing! Let's verify... yes, `usb_interface_descriptor_t` really does have `EXTRA` as `int8`, but when looking at the `usb_interface_descriptor_verbose_t`, it then receives this as an `EXTRA` which is an `int8`. Then I look at `inner` and `extra` is an `array[usb_interface_extra_descriptor, 0:2]`. So, okay, `[]` *is* correct for the `extra` field. I was initially thrown by the apparent inconsistency in how `EXTRA` is being treated.

Now, focusing on `usb_config_descriptor_t`, `EXTRA` is indeed `void`, and the `interfaces` array comes directly after `bMaxPower` as expected. `bMaxPower` is an `int8`, so `0xfa` is correct for that. And that means the `interfaces` part, `array[usb_interface_descriptor, 1:4]`, and its contents should be properly structured as I have described above. But why that array error still?

Aha! `usb_device_descriptor` has an `inner usb_device_descriptor_t` which includes an `array[usb_config_descriptor, 1]`. But I remember `init_vusb.go` patches `idVendor` and `idProduct` *only* if they're zero. That's a problem, because if I hardcode these values, I can't force `xpad`. `init_vusb.go` just randomly picks.

Is there a workaround? Can I bypass `init_vusb.go`? If I can use `syz_usb_connect$xpad` it doesn't exist.

Wait... `init_vusb.go` *patches* the `dev` argument. The question is, can I use `syz_usb_connect` and let it patch what it needs, but *provide* the correct `bInterfaceClass`, `bInterfaceSubClass`, and `bInterfaceProtocol`? Yes! `init_vusb.go` changes the `idVendor` and `idProduct` based on `usb_device_id` tables.

So, if I give it `bInterfaceClass = 0xff`, `bInterfaceSubClass = 0x5d`, `bInterfaceProtocol = 0x81`, maybe `init_vusb.go` will find a driver that matches *those*! But wait, `xpad` actually matches based on `idVendor` and `idProduct`, NOT the interface class! The code confirms this, looping through the `xpad_device` table and matching Vendor and Product IDs.

So, if `init_vusb.go` picks random `idVendor` and `idProduct`, there is a chance it might pick one from `xpad_device`. But it could pick from another driver!

Now I remember syzkaller has a way to specify raw bytes for a struct! If I use `&AUTO=""`, it failed, likely because the type is `ptr[in, usb_device_descriptor]`. But maybe I can use `ANY` for `syz_usb_connect`? No, that signature is fixed.

But wait, syzkaller supports `ANY` for structs! The syntax is something like `pointer-arg = "&" pointer-arg-addr ["=ANY"] "=" arg`. Let's retry `&(0x7f0000000000)=ANY="\x12..."` but make sure I get the syntax *exactly* right.

And yes! if I use `ANY`, the argument must be a valid `ANY` type. In syzlang, `ANY` is just a blob of bytes. Let's try to assemble the correct blob and use the hex value: `&(0x7

wrong int arg *prog.UnionType
line #1:59: r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[0x12<<<!!ERROR!!>>>, 0x01, 0x00, 0x02, 0xff, 0xff, 0xff, 0x40, 0x5e, 0x04, 0x91, 0x02, 0x14, 0x01, 0x01, 0x02, 0x03, 0x01, 0x09, 0x02, 0x20, 0x00, 0x01, 0x01, 0x00, 0x80, 0xfa, 0x09, 0x04, 0x00, 0x00, 0x02, 0xff, 0x5d, 0x81, 0x00, 0x07, 0x05, 0x81, 0x03, 0x20, 0x00, 0x04, 0x07, 0x05, 0x02, 0x03, 0x20, 0x00, 0x04], 0x0)

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[0x12, 0x01, 0x00, 0x02, 0xff, 0xff, 0xff, 0x40, 0x5e, 0x04, 0x91, 0x02, 0x14, 0x01, 0x01, 0x02, 0x03, 0x01, 0x09, 0x02, 0x20, 0x00, 0x01, 0x01, 0x00, 0x80, 0xfa, 0x09, 0x04, 0x00, 0x00, 0x02, 0xff, 0x5d, 0x81, 0x00, 0x07, 0x05, 0x81, 0x03, 0x20, 0x00, 0x04, 0x07, 0x05, 0x02, 0x03, 0x20, 0x00, 0x04], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)=ANY=[0x08, 0x80])
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 145857
							output: 324
							thoughts: 1189
						

**Navigating the USB Device Descriptor Conundrum**

Okay, so I'm trying to figure out how to specify a USB device descriptor with specific vendor and product IDs, specifically for an xpad device, using syzkaller's `syz_usb_connect` function. It looks like `ANY` is the key. But wait, is `ANY` a union, or a special type? Right, the documentation mentions that `ANY` can be a union. If it's a union, I need to specify which option. The current approach uses a struct and sets the vendor/product IDs to 0.

But, if the struct definition *requires* them to be zero, passing explicit values won't work. The function `syz_usb_connect` takes `usb_device_descriptor`, and I need to figure out how to provide a custom one. Let's see... are there other versions of `syz_usb_connect` for specific device types? No, the existing variants don't cover xpad.

Aha! `init_vusb.go` in the fuzzing framework *patches* those IDs if they are zero! So, if I pass zero for vendor and product, the system will patch it. But how does `init_vusb.go` know the *correct* values? It picks a random entry from the kernel's `usb_device_id` tables! That's a problem, it might or might not pick xpad. Is there a way to force it? No, if using `syz_usb_connect`, I can't directly force the choice.

Could I use `dev_bus_usb.txt`? No, that's for user-space drivers, not device emulation. What if I let it pick a random driver, but provide xpad endpoints? No, most drivers use a matching `idVendor` and `idProduct` in `probe` to decide if they should bind to a device! So, it looks like I *must* set those IDs to `0x045e` and `0x0291`.

Okay, back to `syz_usb_connect`. Can I write a raw byte array? Yes, syzkaller allows type casting to `ANY` with `ANY` as the type, but I remember it's a union type. Initial attempts using `&AUTO=ANY=[...]` didn't work. Wait, let's try a string.

That didn't work either. Wrong string argument! Okay, I need to check how `ANY` is *actually* used in syzkaller.

Let's look at `bpf$PROG_LOAD`. Ah! The key is a union! `@ANYBLOB` is one of the options. So, the syntax should be `&(0x7f0000000000)=ANY=[@ANYBLOB="\x12\x01..."]`. That is, specifying the type as `ANY`, but using `@ANYBLOB` as the concrete value. That makes sense, I should try this now.

failed to parse identifier at pos 65
line #1:65: r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="<<<!!ERROR!!>>>\x12\x01\x00\x02\xff\xff\xff\x40\x5e\x04\x91\x02\x14\x01\x01\x02\x03\x01\x09\x02\x20\x00\x01\x01\x00\x80\xfa\x09\x04\x00\x00\x02\xff\x5d\x81\x00\x07\x05\x81\x03\x20\x00\x04\x07\x05\x02\x03\x20\x00\x04"], 0x0)

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="\x12\x01\x00\x02\xff\xff\xff\x40\x5e\x04\x91\x02\x14\x01\x01\x02\x03\x01\x09\x02\x20\x00\x01\x01\x00\x80\xfa\x09\x04\x00\x00\x02\xff\x5d\x81\x00\x07\x05\x81\x03\x20\x00\x04\x07\x05\x02\x03\x20\x00\x04"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)=ANY=[@ANYBLOB="\x08\x80"])
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 148309
							output: 224
							thoughts: 61
						

Okay, here's the summary, tailored for an expert audience:

**Hex String Format for ANYBLOB**

Hold on a second, I need to recalibrate my mental model for this `ANYBLOB` field. I was initially thinking about how I'd typically represent binary data, but I've got to remember, this specific implementation appears to want a hex string, *specifically* without that `\x` prefix. So, instead of thinking about the internal binary representation, I need to feed it a pure hexadecimal representation. I should format it as something like `"18010000000000000000000000000000"`. Right, let's give that a shot and see if that resolves the issue I'm running into.

wrong array arg *prog.BufferType
line #2:55: syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)=ANY=[<<<!!ERROR!!>>>@ANYBLOB="0880"])

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)=ANY=[@ANYBLOB="0880"])
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 148856
							output: 221
							thoughts: 87
						

Okay, let me break this down.

**USB Endpoint Write Analysis**

Right, so I'm looking at this `syz_usb_ep_write` function. The signature clearly indicates that it takes a `data ptr[in, array[int8, 0:256]]` argument. Okay, so that's an input pointer to an array of bytes, up to 256 bytes in length. The good news is, that being an array, I should be able to just use a string literal to feed in the data! Makes life so much easier.

Let's see… I was initially thinking I could just directly assign a hex string, something like `&(0x7f0000000100)="0880"` but that is not correct. I need to encode the data as a literal string. So, it should be `"\x08\x80"`. That seems right. Let's give that a shot and see how it works!

failed to parse identifier at pos 51
line #2:51: syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)="<<<!!ERROR!!>>>\x08\x80")

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)="\x08\x80")
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 149465
							output: 222
							thoughts: 351
						

**Debugging Syzlang String Literals and Array Arguments**

Okay, so I'm wrestling with how to represent byte sequences in syzlang. It hits me – string literals can be single-quoted or double-quoted, right? But the immediate issue is that `\x` escapes don't seem to be supported. Let's consult the documentation to be sure. Ah, there it is: `'` followed by an escaped string, `"` followed by an escaped string, or `"$` followed by an escaped string, then a closing `"`. If `\x` is out, how do I actually define bytes?

Could I use something like `ANY=[@ANYBLOB="0880"]`? Thinking about it, no. I'm trying to feed bytes to a function that needs `data ptr[in, array[int8, 0:256]]` for its argument. So, maybe something like `&(0x7f0000000100)=ANY=[@ANYBLOB="0880"]`? Hold on, I'm getting a compiler error: `wrong array arg *prog.BufferType`.

Right, `ANY` is a union, but the argument is a simple `array[int8]`! It's not a struct, so I can't just pass any arbitrary blob and expect it to magically work. If the argument is an `array[int8]`, can I try just `&(0x7f0000000100)="0880"`? Hang on, if it's hex, is there maybe some kind of `ANYBLOB` syntax for literal strings? No, `ANYBLOB` is specific to the `ANY` union, which is a different animal.

Okay, I've got it. I'm passing a simple `array[int8]`. The way to pass `array[int8]` is just to pass it as an array literal. So, the correct way to specify the data would just be `[0x08, 0x80]`. Time to try `&(0x7f0000000100)=[0x08, 0x80]`. Fingers crossed!

wrong array arg *prog.BufferType
line #2:51: syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)=[<<<!!ERROR!!>>>0x8, 0x80])

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)=[0x8, 0x80])
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 150608
							output: 221
							thoughts: 167
						

**My Line of Reasoning**

Okay, let's see. The function `syz_usb_ep_write` takes a `data ptr[in, array[int8, 0:256]]` argument. Right, an `array[int8]` is essentially a buffer. And for buffers, I can often just use string literals, that's convenient. But hang on, I tried passing `"\x08\x80"` and it choked with a "failed to parse identifier" error. Hmm, what am I missing?

Right, in syzlang, string literals have their own specific syntax, it's either single or double quotes, or the special `"$"` form. I'm used to C and other languages. Okay, so `"..."` or `'...'`, got it. So, can I use an `ANYBLOB` or hex string directly? No, that's not the right tool for this.

Let me double-check the documentation... Aha! The grammar specifies: `string-arg = "'" escaped-string "'" | "\"" escaped-string "\"" | "\"$" escaped-string "\""`. Okay, so, what about `'\\x08\\x80'` then? Yes, that might just work, and I should try it.

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 151298
							output: 224
							thoughts: 585
						

**Analyzing a Subtle USB Race Condition**

Okay, so the code compiled, which is great, but the crash didn't happen. That's the real puzzle. Why isn't the expected race condition manifesting? I'm thinking through the sequence of events... It seems the key lies in the interaction between `syz_usb_disconnect` and `syz_usb_ep_write`. I remember `syz_usb_ep_write` is synchronous; it immediately sends the packet. This triggers the host-side processing, specifically `xpad_irq_in`. That, in turn, calls `xpad360w_process_packet` and schedules the `xpad->work` workqueue. That queue runs *asynchronously*, which is the crux of the problem.

`syz_usb_disconnect` is called *immediately* after `syz_usb_ep_write` returns. If `syz_usb_disconnect` preempts the execution of `xpad->work`, then we have a potential problem. `xpad_init_input` might not even be called, or if it *is* called, the interrupt `irq_out` might not yet be submitted!

So, what we need is a controlled delay. We need to wait a *little bit* to allow `xpad->work` to kick off and submit `irq_out`, but *not* so long that the race becomes moot because everything has finished before `xpad_disconnect` is called. Ah, hold on. I'm remembering that `irq_out` is actually submitted by `xpad_led_probe` and completed by `dummy_hcd` in a timer.

The solution then is to make `syz_usb_ep_write` and `syz_usb_disconnect` run concurrently!

Therefore, let's craft a Syzlang program that exploits this condition:

```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80') (async)
syz_usb_disconnect(r0)
```

The `(async)` directive is what we need to force this concurrent execution and trigger the intended race condition. Let's give it a shot.

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80') (async)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 152791
							output: 172
							thoughts: 897
						

**Analyzing a Potential USB Race Condition**

Okay, still no crash, which is frustrating. I'm wondering if `syz_usb_disconnect` is simply running *too* quickly? If it executes before `syz_usb_ep_write` even *begins*, then `xpad_disconnect` will kill `irq_in`, and importantly, `xpad->work` will be flushed! Specifically, the `xpad360w_stop_input` function, called during disconnect, kills the interrupt and flushes the workqueue:

```c
xpad360w_stop_input(xpad);
```

```c
static void xpad360w_stop_input(struct usb_xpad *xpad)
{
	usb_kill_urb(xpad->irq_in);

	/* Make sure we are done with presence work if it was scheduled */
	flush_work(&xpad->work);
}
```

If `flush_work` is called, that means it waits for `xpad_presence_work` to complete. Crucially, if `xpad_presence_work` *finishes*, it has ALREADY submitted `irq_out`. Then, `xpad_disconnect` continues and calls `xpad_stop_output`.

But wait… If `xpad_presence_work` submits `irq_out` *before* the disconnect calls `xpad_stop_output`, then `irq_out` is *still active*! In which case, `xpad_stop_output` has to wait for completion!

```c
		if (!usb_wait_anchor_empty_timeout(&xpad->irq_out_anchor,
						   5000)) {
```

When it waits, it will wake up when `usb_unanchor_urb` is called. So then `xpad_disconnect` frees `xpad`! Then `xpad_irq_out` accesses `xpad->odata_lock`! THAT'S the race! That should be the bug!

So why hasn't it crashed? Maybe `syz_usb_ep_write` didn't even run because the program exited? If the program exits, `syz_usb_disconnect` is implicitly called. However, using the `(async)` flag, the main thread may exit before the async thread completes. Let's try adding a delay or running the disconnect multiple times.

Wait, what if I use `XTYPE_XBOX360` instead of `XTYPE_XBOX360W`? Because, for `XTYPE_XBOX360`, `irq_out` is submitted DURING PROBE! I don't even *need* `syz_usb_ep_write`! I just need connect and disconnect! This might be simpler. Let's check the descriptor for `XTYPE_XBOX360`. `idVendor = 0x045e`, `idProduct = 0x028e`. Interface class is `0xff`, subclass is `0x5d`, and protocol is `0x01`.

Now, I'll construct the descriptor and confirm:

```
12 01 00 02 ff ff ff 40 5e 04 8e 02 14 01 01 02 03 01
09 02 20 00 01 01 00 80 fa
09 04 00 00 02 ff 5d 01 00
07 05 81 03 20 00 04
07 05 02 03 20 00 04
```

In hex, it is:
`12010002ffffff405e048e021401010203010902200001010080fa0904000002ff5d01000705810320000407050203200004`

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e048e021401010203010902200001010080fa0904000002ff5d01000705810320000407050203200004"], 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 154840
							output: 268
							thoughts: 719
						

**Debugging a USB Driver Race Condition**

Okay, still no crash, which is frustrating. Why isn't this reproducing? I need to understand the timing here. My current theory is that `syz_usb_connect` is somehow waiting for `xpad_probe` to finish. During `xpad_probe`, `xpad_init_input` gets called, which in turn calls `xpad_led_probe`. This is where it gets interesting, because `xpad_led_probe` submits `irq_out`. Then, and only then, does `xpad_probe` complete and `syz_usb_connect` returns. Following that, `syz_usb_disconnect` is called.

The key is `irq_out`! I need to figure out the timing of this critical section. `irq_out` is submitted during `xpad_probe`, but how long does it take for `irq_out` to actually complete? Ah, `dummy_hcd` completes it with a timer, usually within 1ms! If `syz_usb_connect` takes longer than 1ms to return—because it's waiting for udev events or whatever — then `irq_out` has likely already completed by the time `syz_usb_disconnect` is called!

If `irq_out` is already done, that means `xpad->irq_out_active` is now false. In this scenario, `xpad_stop_output` returns immediately, and there is NO race. Damn! I need to ensure that `irq_out` is still active when `xpad_disconnect` is called! How do I force this?

Aha! I can send an LED command! If I write to the LED sysfs file, this will call `xpad_led_set`, which then *also* submits `irq_out`! If I can do this right before `syz_usb_disconnect`, I should have my race.

Now, how do I actually send an LED command from syzkaller? It doesn't have a direct pseudo-syscall for writing to sysfs, of course. But I can use `openat` and `write`! Perfect. I can create a syzlang program.

```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e048e021401010203010902200001010080fa0904000002ff5d01000705810320000407050203200004"], 0x0)
r1 = openat(0xffffffffffffff9c, &(0x7f0000000100)='/sys/class/leds/xpad0/brightness\x00', 0x2, 0x0)
write(r1, &(0x7f0000000200)='1\x00', 0x1) (async)
syz_usb_disconnect(r0)
```

One slight snag: the LED name might not *always* be `xpad0`. That depends on the `xpad->pad_nr` value. If it's the first controller, then `xpad0` it is. Let's start with that assumption and give it a shot. I'm ready!

call #1 openat: escaping filename "/sys/class/leds/xpad0/brightness\x00"

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e048e021401010203010902200001010080fa0904000002ff5d01000705810320000407050203200004"], 0x0)
r1 = openat(0xffffffffffffff9c, &(0x7f0000000100)='/sys/class/leds/xpad0/brightness\x00', 0x2, 0x0)
write(r1, &(0x7f0000000200)='1\x00', 0x1) (async)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 156682
							output: 16
							thoughts: 94
						

**Navigating the `openat` Labyrinth in Syzkaller**

Okay, so it looks like syzkaller is being a bit fussy about `openat` and absolute paths – it's not letting me just throw them in, which is a common security precaution, of course. Hmm, but wait a minute… what about using `openat` with `AT_FDCWD` (that's `0xffffffffffffff9c` for the familiar shorthand) *and* an absolute path? That *should* work around some of the more basic restrictions... but I have a feeling syzkaller might be clever enough to catch that too.

The error message is pointing towards "escaping filename," which I interpret as a filtering mechanism. It's likely sanitizing the filename string to prevent path traversal vulnerabilities.

Okay, let's explore `openat$sysfs`. That's a good approach to access the sysfs file system, and is probably what I need to do.

Time to consult the definitive source: `sys.txt`. I'll confirm that `openat` is supported and check for any nuances related to its implementation in this context.

map[Expression:openat]

map[Output:
Full output is too long, showing 500 out of 1988 lines.
Use more precise expression if possible.

[CREDITS=3610=D: /sys/fs/cgroup/pids
 CREDITS:3611:D: openat2(2)
 CREDITS-3612-S: Sydney, Australia
 --
 Documentation/admin-guide/workload-tracing.rst=327=times each system call is invoked, and the corresponding Linux subsystem.
 --
 Documentation/admin-guide/workload-tracing.rst-357-+-------------------+-----------+-----------------+-------------------------+
 Documentation/admin-guide/workload-tracing.rst:358:| openat            | 48560     | Filesystem      | sys_opennat()           |
 Documentation/admin-guide/workload-tracing.rst-359-+-------------------+-----------+-----------------+-------------------------+
 --
 Documentation/admin-guide/workload-tracing.rst=437=times each system call is invoked, and the corresponding Linux subsystem.
 --
 Documentation/admin-guide/workload-tracing.rst-441-+===================+===========+=================+=========================+
 Documentation/admin-guide/workload-tracing.rst:442:| openat            | 74        | Filesystem      | sys_openat()            |
 Documentation/admin-guide/workload-tracing.rst-443-+-------------------+-----------+-----------------+-------------------------+
 --
 Documentation/admin-guide/workload-tracing.rst=531=times each system call is invoked, and the corresponding Linux subsystem.
 --
 Documentation/admin-guide/workload-tracing.rst-557-+-------------------+-----------+-----------------+----------------------+
 Documentation/admin-guide/workload-tracing.rst:558:| openat            | 14        | Filesystem      | sys_openat()         |
 Documentation/admin-guide/workload-tracing.rst-559-+-------------------+-----------+-----------------+----------------------+
 --
 Documentation/filesystems/caching/cachefiles.rst=69=available in the system and in the cache filesystem:
 --
 Documentation/filesystems/caching/cachefiles.rst-74-
 Documentation/filesystems/caching/cachefiles.rst:75:	- openat() and friends.
 Documentation/filesystems/caching/cachefiles.rst-76-
 --
 Documentation/filesystems/path-lookup.rst=13=including:
 --
 Documentation/filesystems/path-lookup.rst-15-- per-directory parallel name lookup.
 Documentation/filesystems/path-lookup.rst:16:- ``openat2()`` resolution restriction flags.
 Documentation/filesystems/path-lookup.rst-17-
 --
 Documentation/filesystems/path-lookup.rst=34=There are two sorts of ...
 --
 Documentation/filesystems/path-lookup.rst-36-
 Documentation/filesystems/path-lookup.rst:37:.. _openat: http://man7.org/linux/man-pages/man2/openat.2.html
 Documentation/filesystems/path-lookup.rst-38-
 --
 Documentation/filesystems/path-lookup.rst=46=from some other location specified by a file descriptor given to
 Documentation/filesystems/path-lookup.rst:47:"``*at()``" system calls such as `openat() <openat_>`_.
 Documentation/filesystems/path-lookup.rst-48-
 --
 Documentation/filesystems/path-lookup.rst=420=It should be noted that in the case of ``LOOKUP_IN_ROOT`` or
 Documentation/filesystems/path-lookup.rst-421-``LOOKUP_BENEATH``, the effective root becomes the directory file descriptor
 Documentation/filesystems/path-lookup.rst:422:passed to ``openat2()`` (which exposes these ``LOOKUP_`` flags).
 Documentation/filesystems/path-lookup.rst-423-
 --
 Documentation/filesystems/path-lookup.rst=475=path_lookupat(), path_parentat() and
 Documentation/filesystems/path-lookup.rst:476:path_openat() each of which handles the differing requirements of
 Documentation/filesystems/path-lookup.rst-477-different system calls.
 --
 Documentation/filesystems/path-lookup.rst=495=one provided by a dead NFS server.
 Documentation/filesystems/path-lookup.rst-496-
 Documentation/filesystems/path-lookup.rst:497:Finally ``path_openat()`` is used for the ``open()`` system call; it
 Documentation/filesystems/path-lookup.rst-498-contains, in support functions starting with "open_last_lookups()", all the
 --
 Documentation/filesystems/path-lookup.rst=1180=This case is handled by relevant callers of link_path_walk(), such as
 Documentation/filesystems/path-lookup.rst:1181:path_lookupat(), path_openat() using a loop that calls link_path_walk(),
 Documentation/filesystems/path-lookup.rst-1182-and then handles the final component by calling open_last_lookups() or
 --
 Documentation/filesystems/path-lookup.rst=1319=available which apply restrictions to all path components encountered during
 Documentation/filesystems/path-lookup.rst:1320:path lookup. These flags are exposed through ``openat2()``'s ``resolve`` field.
 Documentation/filesystems/path-lookup.rst-1321-
 --
 Documentation/process/adding-syscalls.rst=141=giving an fxyzzy(3) operation for free::
 --
 Documentation/process/adding-syscalls.rst-146-(For more details on the rationale of the \*at() calls, see the
 Documentation/process/adding-syscalls.rst:147::manpage:`openat(2)` man page; for an example of AT_EMPTY_PATH, see the
 Documentation/process/adding-syscalls.rst-148-:manpage:`fstatat(2)` man page.)
 --
 Documentation/process/adding-syscalls.rst=528=functions that classify some special types of system call -- specifically
 Documentation/process/adding-syscalls.rst:529:file open (``open``/``openat``), program execution (``execve``/``exeveat``) or
 Documentation/process/adding-syscalls.rst-530-socket multiplexor (``socketcall``) operations. If your new system call is
 --
 Documentation/trace/coresight/coresight-perf.rst=102=Example for triggering AUX pause and resume with ftrace tracepoints::
 Documentation/trace/coresight/coresight-perf.rst-103-
 Documentation/trace/coresight/coresight-perf.rst:104:  perf record -e cs_etm/aux-action=start-paused/k,syscalls:sys_enter_openat/aux-action=resume/,syscalls:sys_exit_openat/aux-action=pause/ ls
 Documentation/trace/coresight/coresight-perf.rst-105-
 --
 Documentation/trace/eprobetrace.rst=144=events are not normal events, but are created from the raw_syscalls events
 Documentation/trace/eprobetrace.rst:145:within the kernel). In order to trace the openat system call, one can create
 Documentation/trace/eprobetrace.rst-146-an event probe on top of the raw_syscalls event:
 --
 Documentation/trace/eprobetrace.rst-163-
 Documentation/trace/eprobetrace.rst:164:From the source code, the sys_openat() has:
 Documentation/trace/eprobetrace.rst-165-::
 Documentation/trace/eprobetrace.rst-166-
 Documentation/trace/eprobetrace.rst:167: int sys_openat(int dirfd, const char *path, int flags, mode_t mode)
 Documentation/trace/eprobetrace.rst-168- {
 Documentation/trace/eprobetrace.rst:169:	return my_syscall4(__NR_openat, dirfd, path, flags, mode);
 Documentation/trace/eprobetrace.rst-170- }
 --
 Documentation/trace/eprobetrace.rst=172=The path is the second parameter, and that is what is wanted.
 --
 Documentation/trace/eprobetrace.rst-174-
 Documentation/trace/eprobetrace.rst:175: # echo 'e:openat raw_syscalls.sys_enter nr=$id filename=+8($args):ustring' >> dynamic_events
 Documentation/trace/eprobetrace.rst-176-
 Documentation/trace/eprobetrace.rst:177:This is being run on x86_64 where the word size is 8 bytes and the openat
 Documentation/trace/eprobetrace.rst:178:system call __NR_openat is set at 257.
 Documentation/trace/eprobetrace.rst-179-::
 Documentation/trace/eprobetrace.rst-180-
 Documentation/trace/eprobetrace.rst:181: # echo 'nr == 257' > events/eprobes/openat/filter
 Documentation/trace/eprobetrace.rst-182-
 Documentation/trace/eprobetrace.rst=183=Now enable the event and look at the trace.
 --
 Documentation/trace/eprobetrace.rst-185-
 Documentation/trace/eprobetrace.rst:186: # echo 1 > events/eprobes/openat/enable
 Documentation/trace/eprobetrace.rst-187- # cat trace
 --
 Documentation/trace/eprobetrace.rst-200- #              | |         |   |||||     |         |
 Documentation/trace/eprobetrace.rst:201:              cat-1298    [003] ...2.  2060.875970: openat: (raw_syscalls.sys_enter) nr=0x101 filename=(fault)
 Documentation/trace/eprobetrace.rst:202:              cat-1298    [003] ...2.  2060.876197: openat: (raw_syscalls.sys_enter) nr=0x101 filename=(fault)
 Documentation/trace/eprobetrace.rst:203:              cat-1298    [003] ...2.  2060.879126: openat: (raw_syscalls.sys_enter) nr=0x101 filename=(fault)
 Documentation/trace/eprobetrace.rst:204:              cat-1298    [003] ...2.  2060.879639: openat: (raw_syscalls.sys_enter) nr=0x101 filename=(fault)
 Documentation/trace/eprobetrace.rst-205-
 --
 Documentation/trace/eprobetrace.rst=216=Remove the old eprobe::
 Documentation/trace/eprobetrace.rst-217-
 Documentation/trace/eprobetrace.rst:218: # echo 1 > events/eprobes/openat/enable
 Documentation/trace/eprobetrace.rst:219: # echo '-:openat' >> dynamic_events
 Documentation/trace/eprobetrace.rst-220-
 Documentation/trace/eprobetrace.rst=221=This time make an eprobe where the address of the filename is saved::
 Documentation/trace/eprobetrace.rst-222-
 Documentation/trace/eprobetrace.rst:223: # echo 'e:openat_start raw_syscalls.sys_enter nr=$id filename=+8($args):x64' >> dynamic_events
 Documentation/trace/eprobetrace.rst-224-
 --
 Documentation/trace/eprobetrace.rst=226=end of the event::
 --
 Documentation/trace/eprobetrace.rst-228- # echo 's:filename u64 file' >> dynamic_events
 Documentation/trace/eprobetrace.rst:229: # echo 'hist:keys=common_pid:f=filename if nr == 257' > events/eprobes/openat_start/trigger
 Documentation/trace/eprobetrace.rst:230: # echo 'hist:keys=common_pid:file=$f:onmatch(eprobes.openat_start).trace(filename,$file) if id == 257' > events/raw_syscalls/sys_exit/trigger
 Documentation/trace/eprobetrace.rst-231-
 --
 Documentation/trace/eprobetrace.rst=234=string::
 Documentation/trace/eprobetrace.rst-235-
 Documentation/trace/eprobetrace.rst:236: # echo 'e:openat synthetic.filename filename=+0($file):ustring' >> dynamic_events
 Documentation/trace/eprobetrace.rst:237: # echo 1 > events/eprobes/openat/enable
 Documentation/trace/eprobetrace.rst-238- # cat trace
 --
 Documentation/trace/eprobetrace.rst-251- #              | |         |   |||||     |         |
 Documentation/trace/eprobetrace.rst:252:              cat-1331    [001] ...5.  2944.787977: openat: (synthetic.filename) filename="/etc/ld.so.cache"
 Documentation/trace/eprobetrace.rst:253:              cat-1331    [001] ...5.  2944.788480: openat: (synthetic.filename) filename="/lib/x86_64-linux-gnu/libc.so.6"
 Documentation/trace/eprobetrace.rst:254:              cat-1331    [001] ...5.  2944.793426: openat: (synthetic.filename) filename="/usr/lib/locale/locale-archive"
 Documentation/trace/eprobetrace.rst:255:              cat-1331    [001] ...5.  2944.831362: openat: (synthetic.filename) filename="trace"
 Documentation/trace/eprobetrace.rst-256-
 --
 Documentation/trace/eprobetrace.rst=261=eprobe, but it would still need the last one::
 --
 Documentation/trace/eprobetrace.rst-263- # echo 's:filename u64 file' >> dynamic_events
 Documentation/trace/eprobetrace.rst:264: # echo 'hist:keys=common_pid:f=filename' > events/syscalls/sys_enter_openat/trigger
 Documentation/trace/eprobetrace.rst:265: # echo 'hist:keys=common_pid:file=$f:onmatch(syscalls.sys_enter_openat).trace(filename,$file)' > events/syscalls/sys_exit_openat/trigger
 Documentation/trace/eprobetrace.rst:266: # echo 'e:openat synthetic.filename filename=+0($file):ustring' >> dynamic_events
 Documentation/trace/eprobetrace.rst:267: # echo 1 > events/eprobes/openat/enable
 Documentation/trace/eprobetrace.rst-268-
 --
 Documentation/trace/events.rst=225=If the field is a pointer that points into user space (for example
 Documentation/trace/events.rst:226:"filename" from sys_enter_openat), then you have to append ".ustring" to the
 Documentation/trace/events.rst-227-field name::
 --
 Documentation/trace/histogram.rst=5=Documentation written by Tom Zanussi
 --
 Documentation/trace/histogram.rst-632-         get_empty_filp+0x93/0x1c0
 Documentation/trace/histogram.rst:633:         path_openat+0x31/0x5f0
 Documentation/trace/histogram.rst-634-         do_filp_open+0x3a/0x90
 --
 Documentation/trace/histogram.rst-790-    { id: sys_inotify_add_watch         [254], common_pid: gmain           [      3196] } hitcount:          6
 Documentation/trace/histogram.rst:791:    { id: sys_openat                    [257], common_pid: java            [      2623] } hitcount:          2
 Documentation/trace/histogram.rst-792-    { id: sys_eventfd2                  [290], common_pid: ibus-ui-gtk3    [      2760] } hitcount:          4
 --
 Documentation/trace/kprobetrace.rst=267=And you can see the traced information via /sys/kernel/tracing/trace.
 --
 Documentation/trace/kprobetrace.rst-275-             <...>-1447  [001] 1038282.286875: myprobe: (do_sys_open+0x0/0xd6) dfd=3 filename=7fffd1ec4440 flags=8000 mode=0
 Documentation/trace/kprobetrace.rst:276:             <...>-1447  [001] 1038282.286878: myretprobe: (sys_openat+0xc/0xe <- do_sys_open) $retval=fffffffffffffffe
 Documentation/trace/kprobetrace.rst-277-             <...>-1447  [001] 1038282.286885: myprobe: (do_sys_open+0x0/0xd6) dfd=ffffff9c filename=40413c flags=8000 mode=1b6
 --
 Documentation/translations/it_IT/process/adding-syscalls.rst=157=fxyzzy(3)::
 --
 Documentation/translations/it_IT/process/adding-syscalls.rst-162-(Per maggiori dettagli sulla logica delle chiamate \*at(), leggete la pagina
 Documentation/translations/it_IT/process/adding-syscalls.rst:163:man :manpage:`openat(2)`; per un esempio di AT_EMPTY_PATH, leggere la pagina
 Documentation/translations/it_IT/process/adding-syscalls.rst-164-man :manpage:`fstatat(2)`).
 --
 Documentation/translations/it_IT/process/adding-syscalls.rst=502=tipi di chiamate di sistema -- in particolare apertura dei file
 Documentation/translations/it_IT/process/adding-syscalls.rst:503:(``open``/``openat``), esecuzione dei programmi (``execve``/``exeveat``)
 Documentation/translations/it_IT/process/adding-syscalls.rst-504-oppure multiplatori di socket (``socketcall``). Se la vostra nuova chiamata
 --
 Documentation/translations/sp_SP/process/adding-syscalls.rst=161=efectivamente dando una operación fxyzzy(3) gratis::
 --
 Documentation/translations/sp_SP/process/adding-syscalls.rst-166-(Para más detalles sobre la explicación racional de las llamadas \*at(),
 Documentation/translations/sp_SP/process/adding-syscalls.rst:167:revise el man page :manpage:`openat(2)`; para un ejemplo de AT_EMPTY_PATH,
 Documentation/translations/sp_SP/process/adding-syscalls.rst-168-mire el man page :manpage:`fstatat(2)` manpage.)
 --
 Documentation/translations/sp_SP/process/adding-syscalls.rst=491=El subsistema de auditoría es un caso especial; este incluye funciones
 Documentation/translations/sp_SP/process/adding-syscalls.rst-492-(arch-specific) que clasifican algunos tipos especiales de llamadas al
 Documentation/translations/sp_SP/process/adding-syscalls.rst:493:sistema -- específicamente file open (``open``/``openat``), program
 Documentation/translations/sp_SP/process/adding-syscalls.rst-494-execution (``execve`` /``execveat``) o operaciones multiplexores de socket
 --
 MAINTAINERS=9841=F:	include/uapi/linux/fs.h
 MAINTAINERS:9842:F:	include/uapi/linux/openat2.h
 MAINTAINERS-9843-F:	rust/kernel/fs.rs
 --
 arch/alpha/kernel/audit.c=36=int audit_classify_syscall(int abi, unsigned syscall)
 --
 arch/alpha/kernel/audit.c-40-		return AUDITSC_OPEN;
 arch/alpha/kernel/audit.c:41:	case __NR_openat:
 arch/alpha/kernel/audit.c-42-		return AUDITSC_OPENAT;
 --
 arch/alpha/kernel/audit.c-44-		return AUDITSC_EXECVE;
 arch/alpha/kernel/audit.c:45:	case __NR_openat2:
 arch/alpha/kernel/audit.c-46-		return AUDITSC_OPENAT2;
 --
 arch/alpha/kernel/syscalls/syscall.tbl-380-449	common	migrate_pages			sys_migrate_pages
 arch/alpha/kernel/syscalls/syscall.tbl:381:450	common	openat				sys_openat
 arch/alpha/kernel/syscalls/syscall.tbl-382-451	common	mkdirat				sys_mkdirat
 --
 arch/alpha/kernel/syscalls/syscall.tbl-478-546	common	close_range			sys_close_range
 arch/alpha/kernel/syscalls/syscall.tbl:479:547	common	openat2				sys_openat2
 arch/alpha/kernel/syscalls/syscall.tbl-480-548	common	pidfd_getfd			sys_pidfd_getfd
 --
 arch/arm/tools/syscall.tbl-339-321	common	set_mempolicy		sys_set_mempolicy
 arch/arm/tools/syscall.tbl:340:322	common	openat			sys_openat
 arch/arm/tools/syscall.tbl-341-323	common	mkdirat			sys_mkdirat
 --
 arch/arm/tools/syscall.tbl-453-436	common	close_range			sys_close_range
 arch/arm/tools/syscall.tbl:454:437	common	openat2				sys_openat2
 arch/arm/tools/syscall.tbl-455-438	common	pidfd_getfd			sys_pidfd_getfd
 --
 arch/arm64/tools/syscall_32.tbl-336-321	common	set_mempolicy		sys_set_mempolicy
 arch/arm64/tools/syscall_32.tbl:337:322	common	openat			sys_openat		compat_sys_openat
 arch/arm64/tools/syscall_32.tbl-338-323	common	mkdirat			sys_mkdirat
 --
 arch/arm64/tools/syscall_32.tbl-450-436	common	close_range			sys_close_range
 arch/arm64/tools/syscall_32.tbl:451:437	common	openat2				sys_openat2
 arch/arm64/tools/syscall_32.tbl-452-438	common	pidfd_getfd			sys_pidfd_getfd
 --
 arch/m68k/kernel/syscalls/syscall.tbl-297-287	common	migrate_pages			sys_migrate_pages
 arch/m68k/kernel/syscalls/syscall.tbl:298:288	common	openat				sys_openat
 arch/m68k/kernel/syscalls/syscall.tbl-299-289	common	mkdirat				sys_mkdirat
 --
 arch/m68k/kernel/syscalls/syscall.tbl-438-436	common	close_range			sys_close_range
 arch/m68k/kernel/syscalls/syscall.tbl:439:437	common	openat2				sys_openat2
 arch/m68k/kernel/syscalls/syscall.tbl-440-438	common	pidfd_getfd			sys_pidfd_getfd
 --
 arch/microblaze/kernel/syscalls/syscall.tbl-304-294	common	migrate_pages			sys_ni_syscall
 arch/microblaze/kernel/syscalls/syscall.tbl:305:295	common	openat				sys_openat
 arch/microblaze/kernel/syscalls/syscall.tbl-306-296	common	mkdirat				sys_mkdirat
 --
 arch/microblaze/kernel/syscalls/syscall.tbl-444-436	common	close_range			sys_close_range
 arch/microblaze/kernel/syscalls/syscall.tbl:445:437	common	openat2				sys_openat2
 arch/microblaze/kernel/syscalls/syscall.tbl-446-438	common	pidfd_getfd			sys_pidfd_getfd
 --
 arch/mips/kernel/syscalls/syscall_n32.tbl-261-250	n32	migrate_pages			sys_migrate_pages
 arch/mips/kernel/syscalls/syscall_n32.tbl:262:251	n32	openat				sys_openat
 arch/mips/kernel/syscalls/syscall_n32.tbl-263-252	n32	mkdirat				sys_mkdirat
 --
 arch/mips/kernel/syscalls/syscall_n32.tbl-377-436	n32	close_range			sys_close_range
 arch/mips/kernel/syscalls/syscall_n32.tbl:378:437	n32	openat2				sys_openat2
 arch/mips/kernel/syscalls/syscall_n32.tbl-379-438	n32	pidfd_getfd			sys_pidfd_getfd
 --
 arch/mips/kernel/syscalls/syscall_n64.tbl-257-246	n64	migrate_pages			sys_migrate_pages
 arch/mips/kernel/syscalls/syscall_n64.tbl:258:247	n64	openat				sys_openat
 arch/mips/kernel/syscalls/syscall_n64.tbl-259-248	n64	mkdirat				sys_mkdirat
 --
 arch/mips/kernel/syscalls/syscall_n64.tbl-353-436	n64	close_range			sys_close_range
 arch/mips/kernel/syscalls/syscall_n64.tbl:354:437	n64	openat2				sys_openat2
 arch/mips/kernel/syscalls/syscall_n64.tbl-355-438	n64	pidfd_getfd			sys_pidfd_getfd
 --
 arch/mips/kernel/syscalls/syscall_o32.tbl-301-287	o32	migrate_pages			sys_migrate_pages
 arch/mips/kernel/syscalls/syscall_o32.tbl:302:288	o32	openat				sys_openat			compat_sys_openat
 arch/mips/kernel/syscalls/syscall_o32.tbl-303-289	o32	mkdirat				sys_mkdirat
 --
 arch/mips/kernel/syscalls/syscall_o32.tbl-426-436	o32	close_range			sys_close_range
 arch/mips/kernel/syscalls/syscall_o32.tbl:427:437	o32	openat2				sys_openat2
 arch/mips/kernel/syscalls/syscall_o32.tbl-428-438	o32	pidfd_getfd			sys_pidfd_getfd
 --
 arch/parisc/kernel/audit.c=41=int audit_classify_syscall(int abi, unsigned syscall)
 --
 arch/parisc/kernel/audit.c-45-		return AUDITSC_OPEN;
 arch/parisc/kernel/audit.c:46:	case __NR_openat:
 arch/parisc/kernel/audit.c-47-		return AUDITSC_OPENAT;
 --
 arch/parisc/kernel/audit.c-49-		return AUDITSC_EXECVE;
 arch/parisc/kernel/audit.c:50:	case __NR_openat2:
 arch/parisc/kernel/audit.c-51-		return AUDITSC_OPENAT2;
 --
 arch/parisc/kernel/syscalls/syscall.tbl-311-274	64	ppoll			sys_ppoll
 arch/parisc/kernel/syscalls/syscall.tbl:312:275	common	openat			sys_openat			compat_sys_openat
 arch/parisc/kernel/syscalls/syscall.tbl-313-276	common	mkdirat			sys_mkdirat
 --
 arch/parisc/kernel/syscalls/syscall.tbl-437-436	common	close_range			sys_close_range
 arch/parisc/kernel/syscalls/syscall.tbl:438:437	common	openat2				sys_openat2
 arch/parisc/kernel/syscalls/syscall.tbl-439-438	common	pidfd_getfd			sys_pidfd_getfd
 --
 arch/powerpc/kernel/audit.c=43=int audit_classify_syscall(int abi, unsigned syscall)
 --
 arch/powerpc/kernel/audit.c-51-		return AUDITSC_OPEN;
 arch/powerpc/kernel/audit.c:52:	case __NR_openat:
 arch/powerpc/kernel/audit.c-53-		return AUDITSC_OPENAT;
 --
 arch/powerpc/kernel/audit.c-57-		return AUDITSC_EXECVE;
 arch/powerpc/kernel/audit.c:58:	case __NR_openat2:
 arch/powerpc/kernel/audit.c-59-		return AUDITSC_OPENAT2;
 --
 arch/powerpc/kernel/compat_audit.c=33=int ppc32_classify_syscall(unsigned syscall)
 --
 arch/powerpc/kernel/compat_audit.c-37-		return AUDITSC_OPEN;
 arch/powerpc/kernel/compat_audit.c:38:	case __NR_openat:
 arch/powerpc/kernel/compat_audit.c-39-		return AUDITSC_OPENAT;
 --
 arch/powerpc/kernel/compat_audit.c-43-		return AUDITSC_EXECVE;
 arch/powerpc/kernel/compat_audit.c:44:	case __NR_openat2:
 arch/powerpc/kernel/compat_audit.c-45-		return AUDITSC_OPENAT2;
 --
 arch/powerpc/kernel/syscalls/syscall.tbl-372-285	common	vmsplice			sys_vmsplice
 arch/powerpc/kernel/syscalls/syscall.tbl:373:286	common	openat				sys_openat			compat_sys_openat
 arch/powerpc/kernel/syscalls/syscall.tbl-374-287	common	mkdirat				sys_mkdirat
 --
 arch/powerpc/kernel/syscalls/syscall.tbl-529-436	common	close_range			sys_close_range
 arch/powerpc/kernel/syscalls/syscall.tbl:530:437	common	openat2				sys_openat2
 arch/powerpc/kernel/syscalls/syscall.tbl-531-438	common	pidfd_getfd			sys_pidfd_getfd
 --
 arch/s390/kernel/audit.c=37=int audit_classify_syscall(int abi, unsigned syscall)
 --
 arch/s390/kernel/audit.c-41-		return AUDITSC_OPEN;
 arch/s390/kernel/audit.c:42:	case __NR_openat:
 arch/s390/kernel/audit.c-43-		return AUDITSC_OPENAT;
 --
 arch/s390/kernel/audit.c-47-		return AUDITSC_EXECVE;
 arch/s390/kernel/audit.c:48:	case __NR_openat2:
 arch/s390/kernel/audit.c-49-		return AUDITSC_OPENAT2;
 --
 arch/s390/kernel/syscalls/syscall.tbl-241-287	common	migrate_pages			sys_migrate_pages
 arch/s390/kernel/syscalls/syscall.tbl:242:288	common	openat				sys_openat
 arch/s390/kernel/syscalls/syscall.tbl-243-289	common	mkdirat				sys_mkdirat
 --
 arch/s390/kernel/syscalls/syscall.tbl-365-436	common	close_range			sys_close_range
 arch/s390/kernel/syscalls/syscall.tbl:366:437	common	openat2				sys_openat2
 arch/s390/kernel/syscalls/syscall.tbl-367-438	common	pidfd_getfd			sys_pidfd_getfd
 --
 arch/sh/kernel/syscalls/syscall.tbl-304-294	common	migrate_pages			sys_migrate_pages
 arch/sh/kernel/syscalls/syscall.tbl:305:295	common	openat				sys_openat
 arch/sh/kernel/syscalls/syscall.tbl-306-296	common	mkdirat				sys_mkdirat
 --
 arch/sh/kernel/syscalls/syscall.tbl-442-436	common	close_range			sys_close_range
 arch/sh/kernel/syscalls/syscall.tbl:443:437	common	openat2				sys_openat2
 arch/sh/kernel/syscalls/syscall.tbl-444-438	common	pidfd_getfd			sys_pidfd_getfd
 --
 arch/sparc/kernel/audit.c=43=int audit_classify_syscall(int abi, unsigned int syscall)
 --
 arch/sparc/kernel/audit.c-51-		return AUDITSC_OPEN;
 arch/sparc/kernel/audit.c:52:	case __NR_openat:
 arch/sparc/kernel/audit.c-53-		return AUDITSC_OPENAT;
 --
 arch/sparc/kernel/audit.c-57-		return AUDITSC_EXECVE;
 arch/sparc/kernel/audit.c:58:	case __NR_openat2:
 arch/sparc/kernel/audit.c-59-		return AUDITSC_OPENAT2;
 --
 arch/sparc/kernel/compat_audit.c=32=int sparc32_classify_syscall(unsigned int syscall)
 --
 arch/sparc/kernel/compat_audit.c-36-		return AUDITSC_OPEN;
 arch/sparc/kernel/compat_audit.c:37:	case __NR_openat:
 arch/sparc/kernel/compat_audit.c-38-		return AUDITSC_OPENAT;
 --
 arch/sparc/kernel/compat_audit.c-42-		return AUDITSC_EXECVE;
 arch/sparc/kernel/compat_audit.c:43:	case __NR_openat2:
 arch/sparc/kernel/compat_audit.c-44-		return AUDITSC_OPENAT2;
 --
 arch/sparc/kernel/syscalls/syscall.tbl-346-283	common	keyctl			sys_keyctl			compat_sys_keyctl
 arch/sparc/kernel/syscalls/syscall.tbl:347:284	common	openat			sys_openat			compat_sys_openat
 arch/sparc/kernel/syscalls/syscall.tbl-348-285	common	mkdirat			sys_mkdirat
 --
 arch/sparc/kernel/syscalls/syscall.tbl-484-436	common	close_range			sys_close_range
 arch/sparc/kernel/syscalls/syscall.tbl:485:437	common	openat2			sys_openat2
 arch/sparc/kernel/syscalls/syscall.tbl-486-438	common	pidfd_getfd			sys_pidfd_getfd
 --
 arch/x86/entry/syscalls/syscall_32.tbl-309-294	i386	migrate_pages		sys_migrate_pages
 arch/x86/entry/syscalls/syscall_32.tbl:310:295	i386	openat			sys_openat			compat_sys_openat
 arch/x86/entry/syscalls/syscall_32.tbl-311-296	i386	mkdirat			sys_mkdirat
 --
 arch/x86/entry/syscalls/syscall_32.tbl-444-436	i386	close_range		sys_close_range
 arch/x86/entry/syscalls/syscall_32.tbl:445:437	i386	openat2			sys_openat2
 arch/x86/entry/syscalls/syscall_32.tbl-446-438	i386	pidfd_getfd		sys_pidfd_getfd
 --
 arch/x86/entry/syscalls/syscall_64.tbl-268-256	common	migrate_pages		sys_migrate_pages
 arch/x86/entry/syscalls/syscall_64.tbl:269:257	common	openat			sys_openat
 arch/x86/entry/syscalls/syscall_64.tbl-270-258	common	mkdirat			sys_mkdirat
 --
 arch/x86/entry/syscalls/syscall_64.tbl-363-436	common	close_range		sys_close_range
 arch/x86/entry/syscalls/syscall_64.tbl:364:437	common	openat2			sys_openat2
 arch/x86/entry/syscalls/syscall_64.tbl-365-438	common	pidfd_getfd		sys_pidfd_getfd
 --
 arch/x86/ia32/audit.c=31=int ia32_classify_syscall(unsigned syscall)
 --
 arch/x86/ia32/audit.c-35-		return AUDITSC_OPEN;
 arch/x86/ia32/audit.c:36:	case __NR_openat:
 arch/x86/ia32/audit.c-37-		return AUDITSC_OPENAT;
 --
 arch/x86/ia32/audit.c-42-		return AUDITSC_EXECVE;
 arch/x86/ia32/audit.c:43:	case __NR_openat2:
 arch/x86/ia32/audit.c-44-		return AUDITSC_OPENAT2;
 --
 arch/x86/kernel/audit_64.c=42=int audit_classify_syscall(int abi, unsigned syscall)
 --
 arch/x86/kernel/audit_64.c-50-		return AUDITSC_OPEN;
 arch/x86/kernel/audit_64.c:51:	case __NR_openat:
 arch/x86/kernel/audit_64.c-52-		return AUDITSC_OPENAT;
 --
 arch/x86/kernel/audit_64.c-55-		return AUDITSC_EXECVE;
 arch/x86/kernel/audit_64.c:56:	case __NR_openat2:
 arch/x86/kernel/audit_64.c-57-		return AUDITSC_OPENAT2;
 --
 arch/xtensa/kernel/syscalls/syscall.tbl-310-# Relative File Operations
 arch/xtensa/kernel/syscalls/syscall.tbl:311:288	common	openat				sys_openat
 arch/xtensa/kernel/syscalls/syscall.tbl-312-289	common	mkdirat				sys_mkdirat
 --
 arch/xtensa/kernel/syscalls/syscall.tbl-409-436	common	close_range			sys_close_range
 arch/xtensa/kernel/syscalls/syscall.tbl:410:437	common	openat2				sys_openat2
 arch/xtensa/kernel/syscalls/syscall.tbl-411-438	common	pidfd_getfd			sys_pidfd_getfd
 --
 drivers/misc/kgdbts.c=306=static int check_and_rewind_pc(char *put_str, char *arg)
 --
 drivers/misc/kgdbts.c-324-	    ip + offset == sstep_addr &&
 drivers/misc/kgdbts.c:325:	    ((!strcmp(arg, "do_sys_openat2") || !strcmp(arg, "kernel_clone")))) {
 drivers/misc/kgdbts.c-326-		/* This is special case for emulated single step */
 --
 drivers/misc/kgdbts.c=632=static struct test_struct sys_open_test[] = {
 drivers/misc/kgdbts.c-633-	{ "?", "S0*" }, /* Clear break points */
 drivers/misc/kgdbts.c:634:	{ "do_sys_openat2", "OK", sw_break, }, /* set sw breakpoint */
 drivers/misc/kgdbts.c-635-	{ "c", "T0*", NULL, get_thread_id_continue }, /* Continue */
 drivers/misc/kgdbts.c:636:	{ "do_sys_openat2", "OK", sw_rem_break }, /*remove breakpoint */
 drivers/misc/kgdbts.c:637:	{ "g", "do_sys_openat2", NULL, check_and_rewind_pc }, /* check location */
 drivers/misc/kgdbts.c-638-	{ "write", "OK", write_regs, emul_reset }, /* Write registers */
 drivers/misc/kgdbts.c-639-	{ "s", "T0*", emul_sstep_get, emul_sstep_put }, /* Single step */
 drivers/misc/kgdbts.c:640:	{ "g", "do_sys_openat2", NULL, check_single_step },
 drivers/misc/kgdbts.c:641:	{ "do_sys_openat2", "OK", sw_break, }, /* set sw breakpoint */
 drivers/misc/kgdbts.c-642-	{ "7", "T0*", skip_back_repeat_test }, /* Loop based on repeat_test */
 --
 fs/namei.c=4826=static int do_o_path(struct nameidata *nd, unsigned flags, struct file *file)
 --
 fs/namei.c-4837-
 fs/namei.c:4838:static struct file *path_openat(struct nameidata *nd,
 fs/namei.c-4839-			const struct open_flags *op, unsigned flags)
 --
 fs/namei.c=4877=struct file *do_file_open(int dfd, struct filename *pathname,
 --
 fs/namei.c-4886-	set_nameidata(&nd, dfd, pathname, NULL);
 fs/namei.c:4887:	filp = path_openat(&nd, op, flags | LOOKUP_RCU);
 fs/namei.c-4888-	if (unlikely(filp == ERR_PTR(-ECHILD)))
 fs/namei.c:4889:		filp = path_openat(&nd, op, flags);
 fs/namei.c-4890-	if (unlikely(filp == ERR_PTR(-ESTALE)))
 fs/namei.c:4891:		filp = path_openat(&nd, op, flags | LOOKUP_REVAL);
 fs/namei.c-4892-	restore_nameidata();
 --
 fs/namei.c=4896=struct file *do_file_open_root(const struct path *root,
 --
 fs/namei.c-4910-	set_nameidata(&nd, -1, filename, root);
 fs/namei.c:4911:	file = path_openat(&nd, op, flags | LOOKUP_RCU);
 fs/namei.c-4912-	if (unlikely(file == ERR_PTR(-ECHILD)))
 fs/namei.c:4913:		file = path_openat(&nd, op, flags);
 fs/namei.c-4914-	if (unlikely(file == ERR_PTR(-ESTALE)))
 fs/namei.c:4915:		file = path_openat(&nd, op, flags | LOOKUP_REVAL);
 fs/namei.c-4916-	restore_nameidata();
 --
 fs/open.c=1181=inline int build_open_flags(const struct open_how *how, struct open_flags *op)
 --
 fs/open.c-1197-	 * Older syscalls implicitly clear all of the invalid flags or argument
 fs/open.c:1198:	 * values before calling build_open_flags(), but openat2(2) checks all
 fs/open.c-1199-	 * of its arguments.
 --
 fs/open.c=1355=EXPORT_SYMBOL(file_open_root);
 fs/open.c-1356-
 fs/open.c:1357:static int do_sys_openat2(int dfd, const char __user *filename,
 fs/open.c-1358-			  struct open_how *how)
 --
 fs/open.c=1369=int do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
 --
 fs/open.c-1371-	struct open_how how = build_open_how(flags, mode);
 fs/open.c:1372:	return do_sys_openat2(dfd, filename, &how);
 fs/open.c-1373-}
 --
 fs/open.c=1376=SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode)
 --
 fs/open.c-1382-
 fs/open.c:1383:SYSCALL_DEFINE4(openat, int, dfd, const char __user *, filename, int, flags,
 fs/open.c-1384-		umode_t, mode)
 --
 fs/open.c-1390-
 fs/open.c:1391:SYSCALL_DEFINE4(openat2, int, dfd, const char __user *, filename,
 fs/open.c-1392-		struct open_how __user *, how, size_t, usize)
 --
 fs/open.c-1408-
 fs/open.c:1409:	audit_openat2_how(&tmp);
 fs/open.c-1410-
 --
 fs/open.c-1414-
 fs/open.c:1415:	return do_sys_openat2(dfd, filename, &tmp);
 fs/open.c-1416-}
 --
 fs/open.c=1423=COMPAT_SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode)
]
]

gemini-3.1-pro-preview

							input: 169045
							output: 368
							thoughts: 3040
						

**Exploiting a USB Disconnect Race Condition in xpad Driver**

Okay, so the goal is to trigger a use-after-free in the `xpad` driver, specifically for the Xbox 360 wireless controller. First, I need to understand how the driver interacts with the USB device and identify where a race condition could exist. The system calls available are key. `openat` seemed like a good starting point to reach sysfs, but it's restricted in this environment. Fortunately, `syz_open_dev` is available for device access, but unnecessary here.

I've learned that for `XTYPE_XBOX360W`, the `irq_in` is submitted during the probe, and a presence packet is then sent using `syz_usb_ep_write`. The problem lies in the disconnect sequence. `xpad_presence_work` calls `xpad_init_input` which submits `irq_out`, and the device is eventually disconnected with `syz_usb_disconnect`. The initial thought was that a concurrent execution with `syz_usb_ep_write` could lead to a race. The disconnect occurring *before* the USB write would cause the write to fail. The reverse order would be problematic.

My strategy needs to force `syz_usb_ep_write` to execute *before* `syz_usb_disconnect`, which can be achieved through synchronous calls. `syz_usb_ep_write`'s synchronicity allows the system to receive the response before calling `syz_usb_disconnect`. The challenge is, if the disconnect is *too* quick, the `irq_out` process may not be initiated, leaving the driver in a state where the work isn't fully started. However, `flush_work` ensures `xpad->work` is completed before `xpad_stop_output` occurs.

Then, there's `usb_wait_anchor_empty_timeout`, which should wait for `irq_out` to complete before freeing `xpad`. However, that's not what is happening. `xpad_irq_out` accesses `xpad->odata_lock` *after* the device has been disconnected. This should cause a crash! The actual crash occurs during spinlock access due to a slab-use-after-free, pointing to an access of freed memory.

Examining the provided reproducer, the crucial part is the `syz_usb_ep_write` call. I need to be careful with the endpoint address and the packet's contents. `syz_usb_ep_write` expects the endpoint *number*, but the implementation directly uses the given parameter.

The crux of the vulnerability centers around `xpad360w_process_packet`. It processes packets of 32 bytes, but isn't careful. Since `xpad->idata` is of size 64 bytes, and if the sent packet is smaller, the subsequent access to the `xpad` buffer's data may access uninitialized memory. The packet `\x08\x80` is sent, which is only 2 bytes and should be sufficient to trigger this.

However, the question is why the crash wasn't initially observed. The race window might be too narrow. `xpad_inquiry_pad_presence` submits `irq_out` *during* the probe! This makes `syz_usb_ep_write` even more important. Since `irq_out` completes fast, it reduces the race window. But by sending a stream of "presence" packets to toggle `pad_present`, I can make `irq_out` be submitted multiple times. This should create a longer window, and a crash should happen. So, I will need a program that sends a stream of packets: one presence, one absence, presence, absence.

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 173313
							output: 364
							thoughts: 226
						

**Debugging a USB Write Issue**

Okay, still no crash, which is odd. I'm starting to suspect that `syz_usb_ep_write` isn't behaving as I expect it to. First, I need to double-check the endpoint address we're using. Let's see... `0x81` - that should be IN endpoint 1, right? Hang on a second... `syz_usb_ep_write` is supposed to write to the IN endpoint, but `xpad_irq_in` seems to be listening on `ep_irq_in->bEndpointAddress`. And in the descriptor, that's indeed `0x81`. So, `0x81` is the correct address!

Wait... I think I just had a brainwave. Does `syz_usb_ep_write` expect the endpoint number *without* the direction bit? That's the likely issue. Let me quickly consult `vusb.txt` to confirm the function definition. Okay, here it is:

```
syz_usb_ep_write(fd fd_usb, ep int8, len len[data], data ptr[in, array[int8, 0:256]])
```

Yes, that `ep int8` parameter... it likely expects just the endpoint *number*, without the direction bit. In this case, that would be `0x1`. Alright, let's try changing the endpoint number in our code to `0x1` and see if that finally does the trick!

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x1, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_ep_write(r0, 0x1, 0x2, &(0x7f0000000100)='\x08\x00')
syz_usb_ep_write(r0, 0x1, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_ep_write(r0, 0x1, 0x2, &(0x7f0000000100)='\x08\x00')
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 174270
							output: 206
							thoughts: 2627
						

**Crash Analysis and Exploit Plan**

Okay, so the initial USB endpoint write attempt didn't trigger the expected crash. The endpoint address was correct, so there's no immediate issue there. But, I need to check the pseudo-syscall `syz_usb_ep_write` and confirm the endpoint direction, but that should be correct. Thinking further, the key seems to be in the device type and its interaction with the USB driver.  

The clue lies within the `XTYPE_XBOXONE` device type. I need to understand its initialization sequence.  `xpad_start_input` is crucial, and it looks like that's only called when a device is either explicitly opened or after an announce packet has been sent to the controller. The code hints at a `delay_init` flag. For Xbox One devices with the specific ID `0x366c, 0x0005`, `delay_init` will be true. If `xpad->delay_init` is true, then `xpad_init_input` isn't called during probe. However, `xpad_init_input` IS called! So `xpad_start_input` is called within the `xpad_open` function or when an announce packet is received!

The issue might be that `xpad_irq_in` is called if the interrupt in urb is submitted. However, the interrupt in urb is *only* submitted during probe for `XTYPE_XBOX360W`. For `XTYPE_XBOXONE`, this doesn't happen during probe. Then, how is `xpad_irq_in` called at all? That can only happen if `xpad_open` is executed, which calls `xpad_start_input`! And when `xpad_open` executes, `xpad_start_input` ALSO calls `xpad_start_xbox_one`, which submits `irq_out` immediately! So, `irq_out` is submitted when the device is opened.

The key to the crash, then, is that the disconnect race condition triggers a use-after-free situation with `irq_out`, when the device is disconnected. Syzkaller's background threads, as the crash report indicated, are key here: it automatically opens these devices. So if syzkaller opens a device, and immediately disconnects it, then `irq_out` is still running when the device is de-initialized, causing the race and the UAF!

The crash report confirms this – both `irq_in` and `irq_out` are running, and then fail due to -19 when the device is being de-initialized, but `irq_out` is still running. The key is in the timing between opening and disconnecting the device. If the disconnect is too fast, the background thread may not have time to open it, so we'll need a very short sleep or wait.

Thus, to trigger the vulnerability, I need to focus on using `XTYPE_XBOXONE`. The device descriptor needs to be constructed. The protocol needs to be `0xd0`.

Now I'll construct a device descriptor using `0x045e, 0x02d1` that will work to trigger this.

And, if syzkaller opens this, it might take a moment. The disconnection needs to occur AFTER syzkaller has a chance to open. A sleep of 1 second after device creation should allow the background thread time to open the device. The updated syzkaller program should then trigger the crash, if this is correct.

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 177910
							output: 353
							thoughts: 746
						

**Race Condition Debugging in USB Driver**

Okay, still no crash after running this test. Hmm, maybe the background thread from syzkaller didn't even manage to open the device. But if it *did* open the device, it would have submitted `irq_out`, right? And `irq_out` completes incredibly quickly. If it's done before `syz_usb_disconnect` gets called, there's no race condition at all!

The key is getting `irq_out` to be *active* when `xpad_disconnect` runs. If `irq_out` only gets submitted *once* when the device is opened, the window for a race is tiny, almost impossible. How can I make `irq_out` active multiple times? Ah! If I send that announce packet (`GIP_CMD_ANNOUNCE`), `xpadone_process_packet` calls `xpad_start_input` *again*! And if `xpad_start_input` is called again, it will resubmit `irq_out`! Bingo! So, a stream of announce packets should do the trick!

Now, let's look at the syzlang code again.

```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000200)='\x04\x00')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000200)='\x04\x00')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000200)='\x04\x00')
syz_usb_disconnect(r0)
```

Wait a second, `syz_usb_ep_write` takes `ep int8`. If the endpoint address is `0x81`, should `ep` be `0x81` or `0x1`? Let me double-check `vusb.txt`...

```
syz_usb_ep_write$ath9k_ep1(fd fd_usb_ath9k, ep const[USB_ENDPOINT_ATH9K_BULK_IN_ADDRESS], len bytesize[data], data ptr[in, ath9k_bulk_frame])
```

Okay, `USB_ENDPOINT_ATH9K_BULK_IN_ADDRESS` is `(2 | USB_DIR_IN)` which is `0x82`. That means `ep` should be `0x81`! Right, I will try sending the announce packets now.

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000200)='\x04\x00')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000200)='\x04\x00')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000200)='\x04\x00')
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 179837
							output: 466
							thoughts: 903
						

**Debugging the USB Driver**

Okay, still no crash. I'm starting to think maybe `syz_usb_ep_write` isn't behaving as expected. Let me re-examine the `syz_usb_ep_write` function's expected input. It takes a data pointer of `array[int8, 0:256]`, and I'm passing a string. But syzlang *should* allow that. It should correctly interpret the string as an `array[int8]`. Right?

Now, I'm going to shift gears and look at the `xpadone_process_packet` function and a specific check within:
```c
	} else if (data[0] == GIP_CMD_ANNOUNCE) {
		int error;

		if (xpad->delay_init && !xpad->delayed_init_done) {
			xpad->delayed_init_done = true;
			error = xpad_start_input(xpad);
```
So, if `xpad->delayed_init_done` is true, the `xpad_start_input` function is NOT called again. Which means the `irq_out` USB interrupt is only submitted ONCE, even when using announce packets! That's not what I want.

Wait, what about `XTYPE_XBOX360W`? I need to think outside the box a bit. The `xpad_presence_work` function calls `xpad_init_input` if `xpad->pad_present` is true:
```c
	if (xpad->pad_present) {
		error = xpad_init_input(xpad);
```
If I toggle `pad_present`, I can repeatedly call `xpad_init_input` and also `xpad_deinit_input`. And each time `xpad_init_input` is called, `xpad_led_probe` submits `irq_out`! I can submit it multiple times! Yes, that's the angle!

Okay, let's try toggling `pad_present` with the `XTYPE_XBOX360W` device. Here's a quick syzlang snippet I've drafted to test this:
```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
syz_usb_disconnect(r0)
```
Let's give this a shot and see if it yields the desired crash!

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 182209
							output: 585
							thoughts: 709
						

**Debugging the USB Driver**

Okay, still no crash, which is... frustrating, but expected at this stage. I've been staring at this code, and I think I've spotted something. The problem might be in how `xpad_presence_work` interacts with the workqueue. If we send multiple packets, the `xpad->work` is scheduled, but `schedule_work` only schedules it once if it's already pending. So, even though we are sending multiple packets, `xpad_presence_work` might only run once and thus it only submits `irq_out` once.

To make sure it runs multiple times and processes each packet, we need to ensure that it finishes running before sending the next packet. I'm going to try using `nanosleep` between the `syz_usb_ep_write` calls in my syzlang repro. This should give the workqueue a chance to complete between each write.

Here's the plan. I'll connect the USB device, then alternate writing two different packets to the endpoint with a short `nanosleep` in between each write. I'm hoping this will force the workqueue to process each packet individually, potentially revealing the issue. If this doesn't trigger the crash, then I'll need to re-evaluate.

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
nanosleep(&(0x7f0000000200)={0x0, 0x10000000}, 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
nanosleep(&(0x7f0000000200)={0x0, 0x10000000}, 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
nanosleep(&(0x7f0000000200)={0x0, 0x10000000}, 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
nanosleep(&(0x7f0000000200)={0x0, 0x10000000}, 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 183815
							output: 265
							thoughts: 1209
						

**Debugging a USB Driver Race Condition**

Okay, still no crash after running the fuzzer. Let's think this through. `syz_usb_ep_write` is writing to the IN endpoint, simulating the device sending data.  The completion handler for the `irq_in` URB is `xpad_irq_in`, which is submitted by `xpad360w_start_input`.  `xpad_irq_in` then resubmits `irq_in` after it's called on completion of the URB. Since `dummy_hcd` only completes URBs if one is pending, then there *is* a pending `irq_in`, so `xpad_irq_in` *should* be called. So why isn't it crashing?

Maybe `xpad_presence_work` isn't calling `xpad_init_input`. Let me check that function. Ah, `xpad_init_input` returns an error on failure. Does it fail? It looks like it calls `input_allocate_device`, and then `input_register_device`.  If `input_register_device` succeeds, then it sets `xpad->input_created = true` and proceeds to `xpad_led_probe`. Wait, `xpad_led_probe` is called *before* `input_register_device`! `xpad_led_probe` submits `irq_out`, and then `input_register_device` is called. If that succeeds, then `xpad_init_input` returns 0. If `irq_out` completes *before* `syz_usb_disconnect` is called, there's no race.  So to hit the race, `syz_usb_disconnect` needs to be called *exactly* when `irq_out` is completing. However, `irq_out` completes very quickly, and calling `syz_usb_disconnect` after `syz_usb_ep_write` might be too late. The solution would be to call `syz_usb_disconnect` concurrently.

My previous attempt didn't crash.  Perhaps `syz_usb_disconnect` runs too fast. If it runs *before* `syz_usb_ep_write` even starts, `xpad_disconnect` will kill `irq_in` and `xpad->work` will be flushed. A tiny delay before calling `syz_usb_disconnect` might be enough. Let's try inserting a `nanosleep` call. This should give `syz_usb_ep_write` a chance to actually trigger the completion of `irq_out` before the disconnect happens. I'm going to try this new syzlang program now, fingers crossed!

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80') (async)
nanosleep(&(0x7f0000000200)={0x0, 0x1000000}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 185928
							output: 213
							thoughts: 1734
						

**Okay, let's break this down. No crash yet, but we're getting closer. The key seems to be the timing of that `irq_out` USB transfer on the Xbox 360 wireless controller.**

First, I checked the endpoint address and confirmed that `0x81` is the correct endpoint for `syz_usb_ep_write`, not `0x82` as I initially thought. Now, I'm trying to understand *why* the expected race isn't happening with the initial connect/disconnect approach.

The critical insight here is that `irq_out` can be submitted at multiple points: during the probe phase *and* potentially later.  Specifically, `xpad_inquiry_pad_presence` *immediately* submits the `irq_out` USB transfer during the probe process when the device is first connected. Because of this, the transfer completes very quickly and the `xpad->irq_out_active` flag is set to false well before the disconnect happens. Thus, my initial connect/disconnect sequence likely *doesn't* expose the race because the transfer has already completed before `syz_usb_disconnect` is called, and `xpad_stop_output` returns immediately when the device is disconnected. No race condition!

To trigger the race, the `irq_out` transfer needs to happen *after* the initial connect/probe sequence. If I send a presence packet with `syz_usb_ep_write`, it triggers `xpad_presence_work`, which eventually *also* submits `irq_out`! This is key. The race now becomes *very* small; only if `syz_usb_disconnect` is called *exactly* when the later `irq_out` is completing, will it hit the race.

So, to increase the likelihood of the crash I considered fault injection with `fail_nth`. I'm going to focus on running the connect/send/disconnect sequence in a loop. I think syzkaller will reliably hit this now.

However, thinking more deeply, the `XTYPE_XBOXONE` case is more interesting, because the `irq_out` USB transfer is submitted on device open, which happens in syzkaller's background thread! This means the race window is *huge* because it now involves concurrent execution of `xpad_open` and `xpad_disconnect`! This looks much more promising. I'm going to try the connect/disconnect, but use a short `nanosleep` to increase the probability.

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x0, 0x10000000}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 188454
							output: 224
							thoughts: 383
						

**Debugging a Persistent Issue**

Okay, still no crash. Hmm, could it be that syzkaller's background thread isn't actually opening the device? Wait, yes, it does open `/dev/input/event*` devices, I remember that now. But the question is *when*? Does it happen right away? It might be on a slight delay, and that could be the problem. If I use `openat` myself, I can guarantee that the device is open when I need it! The issue now is that I don't have the device node name. Oh, wait, I can use `openat` with `AT_FDCWD` and use `/dev/input/event0`. Does syzkaller restrict access to that device specifically? No, it allows opening it! Perfect. Let me try opening `/dev/input/event0` myself, right now.

Here's the syzlang code I'll use:

```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
r1 = openat(0xffffffffffffff9c, &(0x7f0000000100)='/dev/input/event0\x00', 0x2, 0x0)
syz_usb_disconnect(r0)
```

Let's run this and see what happens. This should give me more control over the device's open state.

call #1 openat: escaping filename "/dev/input/event0\x00"

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
r1 = openat(0xffffffffffffff9c, &(0x7f0000000100)='/dev/input/event0\x00', 0x2, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 189536
							output: 23
							thoughts: 116
						

Here's my thought process, as it just happened:

**Dealing with Restricted Open Paths in Syzkaller**

Alright, it's that familiar pain point: `escaping filename` again. Specifically, I'm trying to work around Syzkaller's restriction on using absolute paths with `openat`. I need to get access to a device, and I know Syzkaller has limitations. The immediate solution that springs to mind is leveraging `syz_open_dev`. I remember this being a workaround for cases exactly like this.

Okay, let's put that theory into practice. I'll need to define it in syzlang to test it out.

```syzlang
r1 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x0, 0x2)
```

Now, just to be absolutely sure that this function exists and is properly named, I'll need to verify its existence and arguments. I'll quickly check the `dev_input.txt` file in the syzkaller source code to confirm the correct syntax for `syz_open_dev$evdev`. Always double-check those syscalls!

no matches

map[Expression:syz_open_dev.*evdev]

map[Output:]

gemini-3.1-pro-preview

							input: 189962
							output: 22
							thoughts: 20
						

Here's a summary of my thought process, tailored for an expert like you:

**Investigating a Potential Fuzzing Target**

Alright, let's get down to brass tacks. I'm zeroing in on a likely target for fuzzing. Given what I'm looking for, my gut tells me `syz_open_dev` is a prime candidate. The first thing I need to do, before I dive into any deeper analysis, is verify its presence and how it's being used. So, I'm reaching for `dev_input.txt`. This file likely holds information on the device I'm investigating, hopefully, it has information about the `syz_open_dev` system call. The goal is to see exactly where `syz_open_dev` is being called and get a sense of its overall interaction within the system. Is it a frequent call, an infrequent one, are there interesting device paths associated with it? This quick check will guide my next steps. It's all about efficient prioritization and avoiding wasted effort. From here, I can form an initial assessment. Then I can create a plan to begin fuzzing `syz_open_dev`.

no matches

map[Expression:syz_open_dev.*input]

map[Output:]

gemini-3.1-pro-preview

							input: 190270
							output: 18
							thoughts: 16
						

Here's my thought process, summarized as you requested:

**Checking the Input for `openat`**

Okay, so I need to quickly determine something about how `openat` is being used. First instinct? Let's dive right into the `dev_input.txt` file. I'm assuming that this is where the raw data or a representation of the input to the system resides. I need to see if `openat` is mentioned in this input file. This will give me immediate insight into what the system is being asked to do, or what it's dealing with, regarding this system call. It's a fundamental starting point for analysis – checking the input directly. This should quickly confirm if I need to dig deeper into the code that processes this file, or if this is the relevant place to begin looking into how `openat` is handled.

no matches

map[Expression:openat.*input]

map[Output:]

gemini-3.1-pro-preview

							input: 190500
							output: 17
							thoughts: 15
						

Here's my take on those thoughts:

**Checking Input for Open Command**

Okay, first things first, let's establish a baseline. I need to quickly ascertain the intended operation. My immediate inclination is to examine the `dev_input.txt` file. I'm specifically looking for any indication of an "open" operation or command within that input file. It's the most logical starting point to determine the user's intent, before attempting any more complex parsing or inference. Let's see if that quick check gives me what I need.

map[Expression:open.*input]

map[Output:
Full output is too long, showing 500 out of 1847 lines.
Use more precise expression if possible.

[Documentation/admin-guide/gpio/gpio-aggregator.rst=211=After that, a new gpiochip "door" has been created:
 --
 Documentation/admin-guide/gpio/gpio-aggregator.rst-216-    gpiochip12 - 2 lines:
 Documentation/admin-guide/gpio/gpio-aggregator.rst:217:	    line   0:       "open"       unused   input  active-high
 Documentation/admin-guide/gpio/gpio-aggregator.rst-218-	    line   1:       "lock"       unused   input  active-high
 --
 Documentation/devicetree/bindings/pinctrl/nuvoton,npcm7xx-pinctrl.txt=107=Optional Properties:
 --
 Documentation/devicetree/bindings/pinctrl/nuvoton,npcm7xx-pinctrl.txt-109- input-disable, output-high, output-low, drive-push-pull,
 Documentation/devicetree/bindings/pinctrl/nuvoton,npcm7xx-pinctrl.txt:110: drive-open-drain, input-debounce, slew-rate, drive-strength
 Documentation/devicetree/bindings/pinctrl/nuvoton,npcm7xx-pinctrl.txt-111-
 --
 Documentation/firmware-guide/acpi/acpi-lid.rst=100=C. button.lid_init_state=ignore:
 --
 Documentation/firmware-guide/acpi/acpi-lid.rst-104-   to the userspace by always pairing "closed" input events with complement
 Documentation/firmware-guide/acpi/acpi-lid.rst:105:   "opened" input events. But there is still no guarantee that the "opened"
 Documentation/firmware-guide/acpi/acpi-lid.rst-106-   notifications can be delivered to the userspace when the lid is actually
 --
 Documentation/hid/hid-transport.rst=232=The available HID callbacks are:
 --
 Documentation/hid/hid-transport.rst-259-   Called from HID device drivers once they are interested in data reports.
 Documentation/hid/hid-transport.rst:260:   Usually, while user-space didn't open any input API/etc., device drivers are
 Documentation/hid/hid-transport.rst-261-   not interested in device data and transport drivers can put devices asleep.
 --
 Documentation/hwmon/adm1025.rst=58=This driver also supports the ADM1025A, which differs from the ADM1025
 Documentation/hwmon/adm1025.rst:59:only in that it has "open-drain VID inputs while the ADM1025 has on-chip
 Documentation/hwmon/adm1025.rst-60-100k pull-ups on the VID inputs". It doesn't make any difference for us.
 --
 Documentation/input/ff.rst=155=Control of playing is done with write(). Below is an example:
 --
 Documentation/input/ff.rst-166-   ...
 Documentation/input/ff.rst:167:	fd = open("/dev/input/eventXX", O_RDWR);
 Documentation/input/ff.rst-168-   ...
 --
 Documentation/input/input-programming.rst=134=again. To do that, we would add this to our example driver::
 Documentation/input/input-programming.rst-135-
 Documentation/input/input-programming.rst:136:    static int button_open(struct input_dev *dev)
 Documentation/input/input-programming.rst-137-    {
 --
 Documentation/input/joydev/joystick-api.rst=38=By default, the device is opened in blocking mode::
 Documentation/input/joydev/joystick-api.rst-39-
 Documentation/input/joydev/joystick-api.rst:40:	int fd = open ("/dev/input/js0", O_RDONLY);
 Documentation/input/joydev/joystick-api.rst-41-
 --
 Documentation/input/uinput.rst=42=the sake of simplicity.
 --
 Documentation/input/uinput.rst-65-
 Documentation/input/uinput.rst:66:      int fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
 Documentation/input/uinput.rst-67-
 --
 Documentation/input/uinput.rst=116=mouse.
 --
 Documentation/input/uinput.rst-128-
 Documentation/input/uinput.rst:129:      int fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
 Documentation/input/uinput.rst-130-
 --
 Documentation/input/uinput.rst=185=but interact with uinput via ioctl calls, or use libevdev.
 --
 Documentation/input/uinput.rst-197-
 Documentation/input/uinput.rst:198:      fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
 Documentation/input/uinput.rst-199-      rc = ioctl(fd, UI_GET_VERSION, &version);
 --
 Documentation/userspace-api/media/drivers/cx2341x-uapi.rst=45=Raw format c example
 --
 Documentation/userspace-api/media/drivers/cx2341x-uapi.rst-114-	if (fin == NULL) {
 Documentation/userspace-api/media/drivers/cx2341x-uapi.rst:115:		fprintf(stderr, "cannot open input\n");
 Documentation/userspace-api/media/drivers/cx2341x-uapi.rst-116-		exit(-1);
 --
 Documentation/userspace-api/media/rc/keytable.c.rst=3=file: uapi/v4l/keytable.c
 --
 Documentation/userspace-api/media/rc/keytable.c.rst-75-	    if ((fd = open(argv[1], O_RDONLY)) < 0) {
 Documentation/userspace-api/media/rc/keytable.c.rst:76:		    perror("Couldn't open input device");
 Documentation/userspace-api/media/rc/keytable.c.rst-77-		    return(-1);
 --
 arch/mips/tools/elf-entry.c=32=int main(int argc, const char *argv[])
 --
 arch/mips/tools/elf-entry.c-46-	if (!file) {
 arch/mips/tools/elf-entry.c:47:		perror("Unable to open input file");
 arch/mips/tools/elf-entry.c-48-		return EXIT_FAILURE;
 --
 arch/um/drivers/chan_kern.c=14=static void *not_configged_init(char *str, int device,
 --
 arch/um/drivers/chan_kern.c-21-
 arch/um/drivers/chan_kern.c:22:static int not_configged_open(int input, int output, int primary, void *data,
 arch/um/drivers/chan_kern.c-23-			      char **dev_out)
 --
 arch/um/drivers/chan_kern.c=90=static int open_one_chan(struct chan *chan)
 --
 arch/um/drivers/chan_kern.c-98-		fd = 0;
 arch/um/drivers/chan_kern.c:99:	else fd = (*chan->ops->open)(chan->input, chan->output, chan->primary,
 arch/um/drivers/chan_kern.c-100-				     chan->data, &chan->dev);
 --
 arch/um/drivers/fd.c=22=static void *fd_init(char *str, int device, const struct chan_opts *opts)
 --
 arch/um/drivers/fd.c-49-
 arch/um/drivers/fd.c:50:static int fd_open(int input, int output, int primary, void *d, char **dev_out)
 arch/um/drivers/fd.c-51-{
 --
 arch/um/drivers/null.c=15=static void *null_init(char *str, int device, const struct chan_opts *opts)
 --
 arch/um/drivers/null.c-19-
 arch/um/drivers/null.c:20:static int null_open(int input, int output, int primary, void *d,
 arch/um/drivers/null.c-21-		     char **dev_out)
 --
 arch/um/drivers/port_user.c=63=static void port_free(void *d)
 --
 arch/um/drivers/port_user.c-70-
 arch/um/drivers/port_user.c:71:static int port_open(int input, int output, int primary, void *d,
 arch/um/drivers/port_user.c-72-		     char **dev_out)
 --
 arch/um/drivers/pty.c=26=static void *pty_chan_init(char *str, int device, const struct chan_opts *opts)
 --
 arch/um/drivers/pty.c-39-
 arch/um/drivers/pty.c:40:static int pts_open(int input, int output, int primary, void *d,
 arch/um/drivers/pty.c-41-		    char **dev_out)
 --
 arch/um/drivers/pty.c=78=static int getmaster(char *line)
 --
 arch/um/drivers/pty.c-112-
 arch/um/drivers/pty.c:113:static int pty_open(int input, int output, int primary, void *d,
 arch/um/drivers/pty.c-114-		    char **dev_out)
 --
 arch/um/drivers/tty.c=19=static void *tty_chan_init(char *str, int device, const struct chan_opts *opts)
 --
 arch/um/drivers/tty.c-38-
 arch/um/drivers/tty.c:39:static int tty_open(int input, int output, int primary, void *d,
 arch/um/drivers/tty.c-40-		    char **dev_out)
 --
 arch/um/drivers/xterm.c=73=__uml_setup("xterm=", xterm_setup,
 --
 arch/um/drivers/xterm.c-86-
 arch/um/drivers/xterm.c:87:static int xterm_open(int input, int output, int primary, void *d,
 arch/um/drivers/xterm.c-88-		      char **dev_out)
 --
 arch/x86/tools/insn_sanity.c=158=static void parse_args(int argc, char **argv)
 --
 arch/x86/tools/insn_sanity.c-181-			if (!input_file)
 arch/x86/tools/insn_sanity.c:182:				usage("Failed to open input file");
 arch/x86/tools/insn_sanity.c-183-			break;
 --
 block/blk-iocost.c=3204=static const match_table_t qos_tokens = {
 --
 block/blk-iocost.c-3213-
 block/blk-iocost.c:3214:static ssize_t ioc_qos_write(struct kernfs_open_file *of, char *input,
 block/blk-iocost.c-3215-			     size_t nbytes, loff_t off)
 --
 block/blk-iocost.c=3396=static const match_table_t i_lcoef_tokens = {
 --
 block/blk-iocost.c-3405-
 block/blk-iocost.c:3406:static ssize_t ioc_cost_model_write(struct kernfs_open_file *of, char *input,
 block/blk-iocost.c-3407-				    size_t nbytes, loff_t off)
 --
 drivers/accessibility/speakup/genmap.c=49=main(int argc, char *argv[])
 --
 drivers/accessibility/speakup/genmap.c-71-
 drivers/accessibility/speakup/genmap.c:72:	open_input(NULL, argv[1]);
 drivers/accessibility/speakup/genmap.c-73-	while (fgets(buffer, sizeof(buffer), infile)) {
 --
 drivers/accessibility/speakup/makemapdata.c=49=main(int argc, char *argv[])
 --
 drivers/accessibility/speakup/makemapdata.c-69-
 drivers/accessibility/speakup/makemapdata.c:70:	open_input(dir_name, "include/linux/input.h");
 drivers/accessibility/speakup/makemapdata.c-71-	while (get_define()) {
 --
 drivers/accessibility/speakup/makemapdata.c-78-
 drivers/accessibility/speakup/makemapdata.c:79:	open_input(dir_name, "include/uapi/linux/input-event-codes.h");
 drivers/accessibility/speakup/makemapdata.c-80-	while (get_define()) {
 --
 drivers/accessibility/speakup/makemapdata.c-87-
 drivers/accessibility/speakup/makemapdata.c:88:	open_input(spk_dir_name, "spk_priv_keyinfo.h");
 drivers/accessibility/speakup/makemapdata.c-89-	while (get_define()) {
 --
 drivers/accessibility/speakup/utils.h=30=char filename[256];
 drivers/accessibility/speakup/utils.h-31-
 drivers/accessibility/speakup/utils.h:32:static inline void open_input(const char *dir_name, const char *name)
 drivers/accessibility/speakup/utils.h-33-{
 --
 drivers/acpi/button.c=496=static int acpi_button_resume(struct device *dev)
 --
 drivers/acpi/button.c-519-
 drivers/acpi/button.c:520:static int acpi_lid_input_open(struct input_dev *input)
 drivers/acpi/button.c-521-{
 --
 drivers/acpi/button.c=532=static int acpi_button_probe(struct platform_device *pdev)
 --
 drivers/acpi/button.c-583-			ACPI_BUTTON_CLASS, ACPI_BUTTON_SUBCLASS_LID);
 drivers/acpi/button.c:584:		input->open = acpi_lid_input_open;
 drivers/acpi/button.c-585-	} else {
 --
 drivers/gpu/drm/xe/xe_eu_stall.c=893=static int xe_eu_stall_stream_open_locked(struct drm_device *dev,
 --
 drivers/gpu/drm/xe/xe_eu_stall.c-949- *
 drivers/gpu/drm/xe/xe_eu_stall.c:950: * This function opens a EU stall data stream with input properties from
 drivers/gpu/drm/xe/xe_eu_stall.c-951- * the user space.
 --
 drivers/hid/hid-alps.c=609=static int T4_init(struct hid_device *hdev, struct alps_dev *pri_data)
 --
 drivers/hid/hid-alps.c-659-
 drivers/hid/hid-alps.c:660:static int alps_sp_open(struct input_dev *dev)
 drivers/hid/hid-alps.c-661-{
 --
 drivers/hid/hid-google-hammer.c=479=static int hammer_probe(struct hid_device *hdev,
 --
 drivers/hid/hid-google-hammer.c-504-	 * We always want to poll for, and handle tablet mode events from
 drivers/hid/hid-google-hammer.c:505:	 * devices that have folded usage, even when nobody has opened the input
 drivers/hid/hid-google-hammer.c-506-	 * device. This also prevents the hid core from dropping early tablet
 --
 drivers/hid/hid-input.c=1882=static int hidinput_input_event(struct input_dev *dev, unsigned int type,
 --
 drivers/hid/hid-input.c-1905-
 drivers/hid/hid-input.c:1906:static int hidinput_open(struct input_dev *dev)
 drivers/hid/hid-input.c-1907-{
 --
 drivers/hid/hid-input.c=2030=static struct hid_input *hidinput_allocate(struct hid_device *hid,
 --
 drivers/hid/hid-input.c-2102-	input_dev->event = hidinput_input_event;
 drivers/hid/hid-input.c:2103:	input_dev->open = hidinput_open;
 drivers/hid/hid-input.c-2104-	input_dev->close = hidinput_close;
 --
 drivers/hid/hid-letsketch.c=60=struct letsketch_data {
 --
 drivers/hid/hid-letsketch.c-66-
 drivers/hid/hid-letsketch.c:67:static int letsketch_open(struct input_dev *dev)
 drivers/hid/hid-letsketch.c-68-{
 --
 drivers/hid/hid-lg-g15.c=893=static int lg_g15_raw_event(struct hid_device *hdev, struct hid_report *report,
 --
 drivers/hid/hid-lg-g15.c-931-
 drivers/hid/hid-lg-g15.c:932:static int lg_g15_input_open(struct input_dev *dev)
 drivers/hid/hid-lg-g15.c-933-{
 --
 drivers/hid/hid-lg-g15.c=1064=static void lg_g15_init_input_dev_core(struct hid_device *hdev, struct input_dev *input,
 --
 drivers/hid/hid-lg-g15.c-1074-	input->dev.parent = &hdev->dev;
 drivers/hid/hid-lg-g15.c:1075:	input->open = lg_g15_input_open;
 drivers/hid/hid-lg-g15.c-1076-	input->close = lg_g15_input_close;
 --
 drivers/hid/hid-logitech-hidpp.c=4116=static void hidpp_non_unifying_init(struct hidpp_device *hidpp)
 --
 drivers/hid/hid-logitech-hidpp.c-4132-
 drivers/hid/hid-logitech-hidpp.c:4133:static int hidpp_input_open(struct input_dev *dev)
 drivers/hid/hid-logitech-hidpp.c-4134-{
 --
 drivers/hid/hid-logitech-hidpp.c=4147=static struct input_dev *hidpp_allocate_input(struct hid_device *hdev)
 --
 drivers/hid/hid-logitech-hidpp.c-4155-	input_set_drvdata(input_dev, hdev);
 drivers/hid/hid-logitech-hidpp.c:4156:	input_dev->open = hidpp_input_open;
 drivers/hid/hid-logitech-hidpp.c-4157-	input_dev->close = hidpp_input_close;
 --
 drivers/hid/hid-picolcd_core.c=519=static int picolcd_probe(struct hid_device *hdev,
 --
 drivers/hid/hid-picolcd_core.c-559-	if (error) {
 drivers/hid/hid-picolcd_core.c:560:		hid_err(hdev, "failed to open input interrupt pipe for key and IR events\n");
 drivers/hid/hid-picolcd_core.c-561-		goto err_cleanup_hid_hw;
 --
 drivers/hid/hid-steam.c=557=static void steam_set_lizard_mode(struct steam_device *steam, bool enable)
 --
 drivers/hid/hid-steam.c-589-
 drivers/hid/hid-steam.c:590:static int steam_input_open(struct input_dev *dev)
 drivers/hid/hid-steam.c-591-{
 --
 drivers/hid/hid-steam.c=706=static int steam_input_register(struct steam_device *steam)
 --
 drivers/hid/hid-steam.c-725-	input->dev.parent = &hdev->dev;
 drivers/hid/hid-steam.c:726:	input->open = steam_input_open;
 drivers/hid/hid-steam.c-727-	input->close = steam_input_close;
 --
 drivers/hid/hid-udraw-ps3.c=101=static int udraw_raw_event(struct hid_device *hdev, struct hid_report *report,
 --
 drivers/hid/hid-udraw-ps3.c-263-
 drivers/hid/hid-udraw-ps3.c:264:static int udraw_open(struct input_dev *dev)
 drivers/hid/hid-udraw-ps3.c-265-{
 --
 drivers/hid/hid-wiimote-modules.c=425=static void wiimod_accel_in_accel(struct wiimote_data *wdata,
 --
 drivers/hid/hid-wiimote-modules.c-458-
 drivers/hid/hid-wiimote-modules.c:459:static int wiimod_accel_open(struct input_dev *dev)
 drivers/hid/hid-wiimote-modules.c-460-{
 --
 drivers/hid/hid-wiimote-modules.c=607=static int wiimod_ir_change(struct wiimote_data *wdata, __u16 mode)
 --
 drivers/hid/hid-wiimote-modules.c-718-
 drivers/hid/hid-wiimote-modules.c:719:static int wiimod_ir_open(struct input_dev *dev)
 drivers/hid/hid-wiimote-modules.c-720-{
 --
 drivers/hid/hid-wiimote-modules.c=820=static void wiimod_nunchuk_in_ext(struct wiimote_data *wdata, const __u8 *ext)
 --
 drivers/hid/hid-wiimote-modules.c-903-
 drivers/hid/hid-wiimote-modules.c:904:static int wiimod_nunchuk_open(struct input_dev *dev)
 drivers/hid/hid-wiimote-modules.c-905-{
 --
 drivers/hid/hid-wiimote-modules.c=1044=static void wiimod_classic_in_ext(struct wiimote_data *wdata, const __u8 *ext)
 --
 drivers/hid/hid-wiimote-modules.c-1197-
 drivers/hid/hid-wiimote-modules.c:1198:static int wiimod_classic_open(struct input_dev *dev)
 drivers/hid/hid-wiimote-modules.c-1199-{
 --
 drivers/hid/hid-wiimote-modules.c=1316=static void wiimod_bboard_in_ext(struct wiimote_data *wdata,
 --
 drivers/hid/hid-wiimote-modules.c-1388-
 drivers/hid/hid-wiimote-modules.c:1389:static int wiimod_bboard_open(struct input_dev *dev)
 drivers/hid/hid-wiimote-modules.c-1390-{
 --
 drivers/hid/hid-wiimote-modules.c=1623=static void wiimod_pro_in_ext(struct wiimote_data *wdata, const __u8 *ext)
 --
 drivers/hid/hid-wiimote-modules.c-1763-
 drivers/hid/hid-wiimote-modules.c:1764:static int wiimod_pro_open(struct input_dev *dev)
 drivers/hid/hid-wiimote-modules.c-1765-{
 --
 drivers/hid/hid-wiimote-modules.c=1994=static void wiimod_drums_in_ext(struct wiimote_data *wdata, const __u8 *ext)
 --
 drivers/hid/hid-wiimote-modules.c-2083-
 drivers/hid/hid-wiimote-modules.c:2084:static int wiimod_drums_open(struct input_dev *dev)
 drivers/hid/hid-wiimote-modules.c-2085-{
 --
 drivers/hid/hid-wiimote-modules.c=2223=static void wiimod_guitar_in_ext(struct wiimote_data *wdata, const __u8 *ext)
 --
 drivers/hid/hid-wiimote-modules.c-2313-
 drivers/hid/hid-wiimote-modules.c:2314:static int wiimod_guitar_open(struct input_dev *dev)
 drivers/hid/hid-wiimote-modules.c-2315-{
 --
 drivers/hid/hid-wiimote-modules.c=2439=static void wiimod_turntable_in_ext(struct wiimote_data *wdata, const __u8 *ext)
 --
 drivers/hid/hid-wiimote-modules.c-2532-
 drivers/hid/hid-wiimote-modules.c:2533:static int wiimod_turntable_open(struct input_dev *dev)
 drivers/hid/hid-wiimote-modules.c-2534-{
 --
 drivers/hid/hid-wiimote-modules.c=2712=static void wiimod_mp_in_mp(struct wiimote_data *wdata, const __u8 *ext)
 --
 drivers/hid/hid-wiimote-modules.c-2770-
 drivers/hid/hid-wiimote-modules.c:2771:static int wiimod_mp_open(struct input_dev *dev)
 drivers/hid/hid-wiimote-modules.c-2772-{
 --
 drivers/hid/usbhid/usbkbd.c=190=static void usb_kbd_led(struct urb *urb)
 --
 drivers/hid/usbhid/usbkbd.c-217-
 drivers/hid/usbhid/usbkbd.c:218:static int usb_kbd_open(struct input_dev *dev)
 drivers/hid/usbhid/usbkbd.c-219-{
 --
 drivers/hid/usbhid/usbmouse.c=49=static void usb_mouse_irq(struct urb *urb)
 --
 drivers/hid/usbhid/usbmouse.c-87-
 drivers/hid/usbhid/usbmouse.c:88:static int usb_mouse_open(struct input_dev *dev)
 drivers/hid/usbhid/usbmouse.c-89-{
 --
 drivers/hid/wacom_sys.c=171=static int wacom_raw_event(struct hid_device *hdev, struct hid_report *report,
 --
 drivers/hid/wacom_sys.c-188-
 drivers/hid/wacom_sys.c:189:static int wacom_open(struct input_dev *dev)
 drivers/hid/wacom_sys.c-190-{
 --
 drivers/hwmon/adm1025.c-18- * This driver also supports the ADM1025A, which differs from the ADM1025
 drivers/hwmon/adm1025.c:19: * only in that it has "open-drain VID inputs while the ADM1025 has
 drivers/hwmon/adm1025.c-20- * on-chip 100k pull-ups on the VID inputs". It doesn't make any
 --
 drivers/iio/adc/ad7173.c=1727=static int ad7173_validate_reference(struct ad7173_state *st, int ref_sel)
 --
 drivers/iio/adc/ad7173.c-1747-
 drivers/iio/adc/ad7173.c:1748:static int ad7173_validate_openwire_ain_inputs(struct ad7173_state *st,
 drivers/iio/adc/ad7173.c-1749-					       bool differential,
 --
 drivers/iio/adc/ad7173.c=1779=static int ad7173_fw_parse_channel_config(struct iio_dev *indio_dev)
 --
 drivers/iio/adc/ad7173.c-1922-			if (st->info->has_openwire_det &&
 drivers/iio/adc/ad7173.c:1923:			    ad7173_validate_openwire_ain_inputs(st, chan->differential, ain[0], ain[1])) {
 drivers/iio/adc/ad7173.c-1924-				chan->event_spec = ad4111_events;
 --
 drivers/iio/adc/at91_adc.c=829=static const struct iio_info at91_adc_info = {
 --
 drivers/iio/adc/at91_adc.c-833-/* Touchscreen related functions */
 drivers/iio/adc/at91_adc.c:834:static int atmel_ts_open(struct input_dev *dev)
 drivers/iio/adc/at91_adc.c-835-{
 --
 drivers/input/apm-power.c=48=static int apmpower_connect(struct input_handler *handler,
 --
 drivers/input/apm-power.c-72-	if (error) {
 drivers/input/apm-power.c:73:		pr_err("Failed to open input power device, error %d\n", error);
 drivers/input/apm-power.c-74-		input_unregister_handle(handle);
 --
 drivers/input/input.c=569=EXPORT_SYMBOL(input_release_device);
 --
 drivers/input/input.c-571-/**
 drivers/input/input.c:572: * input_open_device - open input device
 drivers/input/input.c-573- * @handle: handle through which device is being accessed
 --
 drivers/input/input.c-577- */
 drivers/input/input.c:578:int input_open_device(struct input_handle *handle)
 drivers/input/input.c-579-{
 --
 drivers/input/input.c=1141=static int input_proc_devices_open(struct inode *inode, struct file *file)
 drivers/input/input.c-1142-{
 drivers/input/input.c:1143:	return seq_open_private(file, &input_devices_seq_ops,
 drivers/input/input.c-1144-				sizeof(struct input_seq_state));
 --
 drivers/input/input.c=1147=static const struct proc_ops input_devices_proc_ops = {
 drivers/input/input.c:1148:	.proc_open	= input_proc_devices_open,
 drivers/input/input.c-1149-	.proc_poll	= input_proc_devices_poll,
 --
 drivers/input/input.c=1202=static int input_proc_handlers_open(struct inode *inode, struct file *file)
 drivers/input/input.c-1203-{
 drivers/input/input.c:1204:	return seq_open_private(file, &input_handlers_seq_ops,
 drivers/input/input.c-1205-				sizeof(struct input_seq_state));
 --
 drivers/input/input.c=1208=static const struct proc_ops input_handlers_proc_ops = {
 drivers/input/input.c:1209:	.proc_open	= input_proc_handlers_open,
 drivers/input/input.c-1210-	.proc_read	= seq_read,
 --
 drivers/input/input.c=1705=static void input_dev_toggle(struct input_dev *dev, bool activate)
 --
 drivers/input/input.c-1722- *
 drivers/input/input.c:1723: * This function tries to reset the state of an opened input device and
 drivers/input/input.c-1724- * bring internal state and state if the hardware in sync with each other.
 --
 drivers/input/input.c=2584=static void input_handle_setup_event_handler(struct input_handle *handle)
 --
 drivers/input/input.c-2603- * and handler's lists so that events can flow through
 drivers/input/input.c:2604: * it once it is opened using input_open_device().
 drivers/input/input.c-2605- *
 --
 drivers/input/joystick/a3d.c=209=static void a3d_adc_close(struct gameport *gameport)
 --
 drivers/input/joystick/a3d.c-216-/*
 drivers/input/joystick/a3d.c:217: * a3d_open() is a callback from the input open routine.
 drivers/input/joystick/a3d.c-218- */
 drivers/input/joystick/a3d.c-219-
 drivers/input/joystick/a3d.c:220:static int a3d_open(struct input_dev *dev)
 drivers/input/joystick/a3d.c-221-{
 --
 drivers/input/joystick/adafruit-seesaw.c=145=static int seesaw_read_data(struct i2c_client *client, struct seesaw_data *data)
 --
 drivers/input/joystick/adafruit-seesaw.c-181-
 drivers/input/joystick/adafruit-seesaw.c:182:static int seesaw_open(struct input_dev *input)
 drivers/input/joystick/adafruit-seesaw.c-183-{
 --
 drivers/input/joystick/adc-joystick.c=54=static int adc_joystick_handle(const void *data, void *private)
 --
 drivers/input/joystick/adc-joystick.c-106-
 drivers/input/joystick/adc-joystick.c:107:static int adc_joystick_open(struct input_dev *dev)
 drivers/input/joystick/adc-joystick.c-108-{
 --
 drivers/input/joystick/adi.c=259=static void adi_poll(struct gameport *gameport)
 --
 drivers/input/joystick/adi.c-267-/*
 drivers/input/joystick/adi.c:268: * adi_open() is a callback from the input open routine.
 drivers/input/joystick/adi.c-269- */
 drivers/input/joystick/adi.c-270-
 drivers/input/joystick/adi.c:271:static int adi_open(struct input_dev *dev)
 drivers/input/joystick/adi.c-272-{
 --
 drivers/input/joystick/amijoy.c=35=static irqreturn_t amijoy_interrupt(int irq, void *dummy)
 --
 drivers/input/joystick/amijoy.c-57-
 drivers/input/joystick/amijoy.c:58:static int amijoy_open(struct input_dev *dev)
 drivers/input/joystick/amijoy.c-59-{
 --
 drivers/input/joystick/analog.c=249=static void analog_poll(struct gameport *gameport)
 --
 drivers/input/joystick/analog.c-279-/*
 drivers/input/joystick/analog.c:280: * analog_open() is a callback from the input open routine.
 drivers/input/joystick/analog.c-281- */
 drivers/input/joystick/analog.c-282-
 drivers/input/joystick/analog.c:283:static int analog_open(struct input_dev *dev)
 drivers/input/joystick/analog.c-284-{
 --
 drivers/input/joystick/cobra.c=91=static void cobra_poll(struct gameport *gameport)
 --
 drivers/input/joystick/cobra.c-120-
 drivers/input/joystick/cobra.c:121:static int cobra_open(struct input_dev *dev)
 drivers/input/joystick/cobra.c-122-{
 --
 drivers/input/joystick/db9.c=352=static void db9_timer(struct timer_list *t)
 --
 drivers/input/joystick/db9.c-503-
 drivers/input/joystick/db9.c:504:static int db9_open(struct input_dev *dev)
 drivers/input/joystick/db9.c-505-{
 --
 drivers/input/joystick/gamecon.c=727=static void gc_timer(struct timer_list *t)
 --
 drivers/input/joystick/gamecon.c-764-
 drivers/input/joystick/gamecon.c:765:static int gc_open(struct input_dev *dev)
 drivers/input/joystick/gamecon.c-766-{
 --
 drivers/input/joystick/gf2k.c=186=static void gf2k_poll(struct gameport *gameport)
 --
 drivers/input/joystick/gf2k.c-198-
 drivers/input/joystick/gf2k.c:199:static int gf2k_open(struct input_dev *dev)
 drivers/input/joystick/gf2k.c-200-{
 --
 drivers/input/joystick/grip.c=163=static void grip_poll(struct gameport *gameport)
 --
 drivers/input/joystick/grip.c-263-
 drivers/input/joystick/grip.c:264:static int grip_open(struct input_dev *dev)
 drivers/input/joystick/grip.c-265-{
 --
 drivers/input/joystick/grip_mp.c=536=static void grip_poll(struct gameport *gameport)
 --
 drivers/input/joystick/grip_mp.c-560-
 drivers/input/joystick/grip_mp.c:561:static int grip_open(struct input_dev *dev)
 drivers/input/joystick/grip_mp.c-562-{
 --
]
]

gemini-3.1-pro-preview

							input: 200492
							output: 206
							thoughts: 286
						

**My Syzkaller Device Connection Hack**

Okay, so I'm hitting a roadblock. It looks like syzkaller doesn't have a specific pseudo-syscall for directly opening an input device. That's annoying, but wait a minute... I remember that background thread! Syzkaller automatically opens *all* `/dev/input/event*` devices. This is perfect! If I just connect a device and give syzkaller some time, it should open it itself.

The question is, how long is "some time"? Is one second enough? I doubt it. Let's be safe and give it three seconds. That should be plenty.

Here's my syzlang program. I'm using `syz_usb_connect` to attach a USB device, giving it a three-second nap with `nanosleep`, and finally, I'll disconnect it with `syz_usb_disconnect`. Let's see if this works!

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x3, 0x0}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 201219
							output: 581
							thoughts: 3402
						

**Race Condition Analysis and Exploit Strategy for Xbox 360 Wireless Controller Driver**

Okay, so the goal is still to trigger that elusive crash. The fact that the initial attempts haven't worked is frustrating, but it's essential to dig into why. The key insight is the timing of the `irq_out` completion relative to the `syz_usb_disconnect` call. We need `irq_out` active when `xpad_disconnect` gets called.  If `irq_out` only gets submitted once, the window for this race is tiny, almost impossible to hit reliably. The challenge, then, is to force `irq_out` to be submitted *multiple* times.

For the `XTYPE_XBOXONE` case, `irq_out` is submitted only once when the device is opened and if `xpad_play_effect` is called. That's not the path to take here, since syzkaller doesn't exercise that functionality. But, the `XTYPE_XBOX360W` implementation looks promising, and `irq_out` is submitted by `xpad_led_probe`, which is itself called by `xpad_init_input`. Now, if we can repeatedly toggle `pad_present`, we can force repeated calls to `xpad_init_input`, leading to multiple submissions of `irq_out`. That feels like a solid angle of attack.

I looked at the syzlang code and realized that the initial `syz_usb_ep_write` calls weren't likely functioning as I expected. I reviewed the syzlang code and it used `syz_usb_ep_write` with an IN endpoint. But `syz_usb_ep_write` is a pseudo-syscall that submits a USB request to the *host*. The `raw-gadget` interface is for the device to send data to the host. The call uses `USB_RAW_IOCTL_EP_WRITE`, which is exactly what we need, the data should go from the device to the host.

Now, I was suspicious about the data format. Reviewing the `xpad360w_process_packet` function, `0x08` and `0x80` values control the `pad_present` variable. This toggling of `pad_present`, then, should repeatedly call `xpad_init_input` which in turn calls `xpad_led_probe`. This should definitely submit `irq_out` multiple times. So I devised a plan to send `0x08\x80` to make `pad_present` true, wait, then send `0x08\x00` to make it false, and then repeat.

However, maybe it's the timing again. The delay between the packets sent via `syz_usb_ep_write` needs to be finely tuned.  If the delay is too short, `xpad->work` doesn't have enough time to run. If that happens, then we might update `xpad->pad_present`, but `xpad->work` will only see the *last* state. We need to wait for `xpad->work` to *finish* before sending another packet. I guessed that 100ms should be enough delay between packets sent.

Here is the updated syzlang code with a 100ms delay:
```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
nanosleep(&(0x7f0000000200)={0x0, 0x5f5e100}, 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
nan

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
nanosleep(&(0x7f0000000200)={0x0, 0x5f5e100}, 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
nanosleep(&(0x7f0000000200)={0x0, 0x5f5e100}, 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
nanosleep(&(0x7f0000000200)={0x0, 0x5f5e100}, 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x00')
nanosleep(&(0x7f0000000200)={0x0, 0x5f5e100}, 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80')
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 206258
							output: 17
							thoughts: 2797
						

**Race Condition Analysis in the Xbox One Controller Driver**

Okay, so the crash still isn't happening. I'm focusing on the `xpad` driver and, specifically, how it handles the USB disconnect sequence and the interaction with the output interrupt (`irq_out`). I need to understand when and how `irq_out` is submitted, and when it completes.

The initial thought process is centered around `xpad_init_input` and its failure scenarios, however, that does not play a role here. I've tracked the call chain. It appears that `xpad_led_probe` is called. Specifically, `led_set_brightness` schedules a workqueue task.  This is asynchronous! `led_set_brightness` is the culprit. When `led_classdev_unregister` is called, it flushes the workqueue and waits, but *only* if the workqueue has submitted the `irq_out`.

Here's the key: `irq_out` is *not* submitted synchronously during the initialization. It is submitted asynchronously by the workqueue.  When the device disconnects, `xpad_disconnect` calls `xpad_deinit_input`, and then `led_classdev_unregister` flushes the `set_brightness_work`. This means `irq_out` *should* complete before `led_classdev_unregister` returns. `xpad_stop_output` then waits for the anchor to be empty. This implies the race is highly unlikely because `irq_out` should *already* be complete by the time `xpad_stop_output` gets called.

So why doesn't it crash? Perhaps `irq_out` completes *before* `xpad_stop_output` is called, which would mean it runs quickly, and completes fast.  Then the wait in `flush_work` ensures we don't race!

Alright, it appears the only way to get this race is for the `irq_out` to *still* be active when `xpad_stop_output` is called.  But `irq_out` is very fast, maybe only taking 1ms. If the `input_unregister_device` operation takes *more* than 1ms, then `irq_out` will always complete before `xpad_stop_output`, making the race almost impossible to hit. This is why it's so hard to reproduce the crash!

Okay, let's explore if there are other ways to submit `irq_out`. What about `XTYPE_XBOXONE` controllers? `irq_out` is submitted via `xpad_start_xbox_one`, which is called when the device is opened. If we open the device and disconnect it, `xpad_disconnect` calls `xpad_stop_output`. Wait, `xpad_close` is called during the `input_unregister_device`, and if it kills `irq_in`, what about `irq_out`? Did `xpad_irq_out` resubmit it?  

Upon analyzing the code, it turns out that `xpad_irq_out` only resubmits the `irq_out` if a pending packet exists in the output ring! For Xbox One controllers, it sends a few initialization packets, however, after the initialization packets are sent, `irq_out` is *not* resubmitted. Therefore, `irq_out` is only run once, and it finishes quickly, preventing a race!

However, the controller sends three init packets. If we disconnect the device *precisely* when the 3rd packet is completing, then we hit the race. But this requires extremely precise timing! It seems like this approach has a small chance to hit this race.

How can we make `irq_out` run continuously? Ah, force feedback! If a force feedback effect is sent, `irq_out` is likely to be constantly running.  Can syzkaller send a force feedback effect? I need to use `syz_open_dev` to access `/dev/input/event#` to then send a force feedback request. Unfortunately, I'm not seeing `syz_open_dev` in `dev_input.txt`. I will need to explore how to get a file descriptor for `/dev/input/event#` inside of a syzkaller program, or perhaps a different way of submitting the `irq_out`.

map[Expression:fd_input]

map[Output:drivers/net/ethernet/intel/i40e/i40e.h=1103=static inline int i40e_get_fd_cnt_all(struct i40e_pf *pf)
--
drivers/net/ethernet/intel/i40e/i40e.h-1108-/**
drivers/net/ethernet/intel/i40e/i40e.h:1109: * i40e_read_fd_input_set - reads value of flow director input set register
drivers/net/ethernet/intel/i40e/i40e.h-1110- * @pf: pointer to the PF struct
--
drivers/net/ethernet/intel/i40e/i40e.h-1115- **/
drivers/net/ethernet/intel/i40e/i40e.h:1116:static inline u64 i40e_read_fd_input_set(struct i40e_pf *pf, u16 addr)
drivers/net/ethernet/intel/i40e/i40e.h-1117-{
--
drivers/net/ethernet/intel/i40e/i40e.h-1127-/**
drivers/net/ethernet/intel/i40e/i40e.h:1128: * i40e_write_fd_input_set - writes value into flow director input set register
drivers/net/ethernet/intel/i40e/i40e.h-1129- * @pf: pointer to the PF struct
--
drivers/net/ethernet/intel/i40e/i40e.h-1135- **/
drivers/net/ethernet/intel/i40e/i40e.h:1136:static inline void i40e_write_fd_input_set(struct i40e_pf *pf,
drivers/net/ethernet/intel/i40e/i40e.h-1137-					   u16 addr, u64 val)
--
drivers/net/ethernet/intel/i40e/i40e_ethtool.c=3354=static int i40e_get_ethtool_fdir_entry(struct i40e_pf *pf,
--
drivers/net/ethernet/intel/i40e/i40e_ethtool.c-3443-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c:3444:	input_set = i40e_read_fd_input_set(pf, index);
drivers/net/ethernet/intel/i40e/i40e_ethtool.c-3445-
--
drivers/net/ethernet/intel/i40e/i40e_ethtool.c=4292=static int i40e_check_fdir_input_set(struct i40e_vsi *vsi,
--
drivers/net/ethernet/intel/i40e/i40e_ethtool.c-4351-	/* Read the current input set from register memory. */
drivers/net/ethernet/intel/i40e/i40e_ethtool.c:4352:	current_mask = i40e_read_fd_input_set(pf, index);
drivers/net/ethernet/intel/i40e/i40e_ethtool.c-4353-	new_mask = current_mask;
--
drivers/net/ethernet/intel/i40e/i40e_ethtool.c-4670-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c:4671:	i40e_write_fd_input_set(pf, index, new_mask);
drivers/net/ethernet/intel/i40e/i40e_ethtool.c-4672-
--
drivers/net/ethernet/intel/i40e/i40e_ethtool.c-4679-	if (index == LIBIE_FILTER_PCTYPE_NONF_IPV4_OTHER)
drivers/net/ethernet/intel/i40e/i40e_ethtool.c:4680:		i40e_write_fd_input_set(pf, LIBIE_FILTER_PCTYPE_FRAG_IPV4,
drivers/net/ethernet/intel/i40e/i40e_ethtool.c-4681-					new_mask);
--
drivers/net/ethernet/intel/i40e/i40e_main.c=9151=static void i40e_fdir_filter_exit(struct i40e_pf *pf)
--
drivers/net/ethernet/intel/i40e/i40e_main.c-9178-	/* Reprogram the default input set for TCP/IPv4 */
drivers/net/ethernet/intel/i40e/i40e_main.c:9179:	i40e_write_fd_input_set(pf, LIBIE_FILTER_PCTYPE_NONF_IPV4_TCP,
drivers/net/ethernet/intel/i40e/i40e_main.c-9180-				I40E_L3_SRC_MASK | I40E_L3_DST_MASK |
--
drivers/net/ethernet/intel/i40e/i40e_main.c-9183-	/* Reprogram the default input set for TCP/IPv6 */
drivers/net/ethernet/intel/i40e/i40e_main.c:9184:	i40e_write_fd_input_set(pf, LIBIE_FILTER_PCTYPE_NONF_IPV6_TCP,
drivers/net/ethernet/intel/i40e/i40e_main.c-9185-				I40E_L3_V6_SRC_MASK | I40E_L3_V6_DST_MASK |
--
drivers/net/ethernet/intel/i40e/i40e_main.c-9188-	/* Reprogram the default input set for UDP/IPv4 */
drivers/net/ethernet/intel/i40e/i40e_main.c:9189:	i40e_write_fd_input_set(pf, LIBIE_FILTER_PCTYPE_NONF_IPV4_UDP,
drivers/net/ethernet/intel/i40e/i40e_main.c-9190-				I40E_L3_SRC_MASK | I40E_L3_DST_MASK |
--
drivers/net/ethernet/intel/i40e/i40e_main.c-9193-	/* Reprogram the default input set for UDP/IPv6 */
drivers/net/ethernet/intel/i40e/i40e_main.c:9194:	i40e_write_fd_input_set(pf, LIBIE_FILTER_PCTYPE_NONF_IPV6_UDP,
drivers/net/ethernet/intel/i40e/i40e_main.c-9195-				I40E_L3_V6_SRC_MASK | I40E_L3_V6_DST_MASK |
--
drivers/net/ethernet/intel/i40e/i40e_main.c-9198-	/* Reprogram the default input set for SCTP/IPv4 */
drivers/net/ethernet/intel/i40e/i40e_main.c:9199:	i40e_write_fd_input_set(pf, LIBIE_FILTER_PCTYPE_NONF_IPV4_SCTP,
drivers/net/ethernet/intel/i40e/i40e_main.c-9200-				I40E_L3_SRC_MASK | I40E_L3_DST_MASK |
--
drivers/net/ethernet/intel/i40e/i40e_main.c-9203-	/* Reprogram the default input set for SCTP/IPv6 */
drivers/net/ethernet/intel/i40e/i40e_main.c:9204:	i40e_write_fd_input_set(pf, LIBIE_FILTER_PCTYPE_NONF_IPV6_SCTP,
drivers/net/ethernet/intel/i40e/i40e_main.c-9205-				I40E_L3_V6_SRC_MASK | I40E_L3_V6_DST_MASK |
--
drivers/net/ethernet/intel/i40e/i40e_main.c-9208-	/* Reprogram the default input set for Other/IPv4 */
drivers/net/ethernet/intel/i40e/i40e_main.c:9209:	i40e_write_fd_input_set(pf, LIBIE_FILTER_PCTYPE_NONF_IPV4_OTHER,
drivers/net/ethernet/intel/i40e/i40e_main.c-9210-				I40E_L3_SRC_MASK | I40E_L3_DST_MASK);
drivers/net/ethernet/intel/i40e/i40e_main.c-9211-
drivers/net/ethernet/intel/i40e/i40e_main.c:9212:	i40e_write_fd_input_set(pf, LIBIE_FILTER_PCTYPE_FRAG_IPV4,
drivers/net/ethernet/intel/i40e/i40e_main.c-9213-				I40E_L3_SRC_MASK | I40E_L3_DST_MASK);
--
drivers/net/ethernet/intel/i40e/i40e_main.c-9215-	/* Reprogram the default input set for Other/IPv6 */
drivers/net/ethernet/intel/i40e/i40e_main.c:9216:	i40e_write_fd_input_set(pf, LIBIE_FILTER_PCTYPE_NONF_IPV6_OTHER,
drivers/net/ethernet/intel/i40e/i40e_main.c-9217-				I40E_L3_SRC_MASK | I40E_L3_DST_MASK);
drivers/net/ethernet/intel/i40e/i40e_main.c-9218-
drivers/net/ethernet/intel/i40e/i40e_main.c:9219:	i40e_write_fd_input_set(pf, LIBIE_FILTER_PCTYPE_FRAG_IPV6,
drivers/net/ethernet/intel/i40e/i40e_main.c-9220-				I40E_L3_SRC_MASK | I40E_L3_DST_MASK);
--
drivers/net/ethernet/intel/i40e/i40e_main.c=9636=static void i40e_reenable_fdir_atr(struct i40e_pf *pf)
--
drivers/net/ethernet/intel/i40e/i40e_main.c-9643-		 */
drivers/net/ethernet/intel/i40e/i40e_main.c:9644:		i40e_write_fd_input_set(pf, LIBIE_FILTER_PCTYPE_NONF_IPV4_TCP,
drivers/net/ethernet/intel/i40e/i40e_main.c-9645-					I40E_L3_SRC_MASK | I40E_L3_DST_MASK |
]

gemini-3.1-pro-preview

							input: 213060
							output: 20
							thoughts: 79
						

Okay, here's my interpretation of that thought process, tailored for an expert audience:

**Debugging Syzkaller Resource Handling**

Alright, so I'm digging into this code and immediately I realize that `fd_input` isn't being treated as a proper resource within this Syzkaller context. That's a red flag. Let me backtrack – I'm pretty sure `syz_open_dev` is defined in one of the `sys/linux/dev_*.txt` files. I need to figure out which one specifically. Hmm, is there a `dev_input.txt`? Let me quickly verify by checking the file list. Yes, good, there it is: `dev_input.txt`. Excellent, looks like I've found it. Now let me read that file and see what `syz_open_dev` is actually doing in relation to input devices and figure out why my resource tracking isn't working as expected.

map[File:dev_input.txt]

map[Output:# Copyright 2015 syzkaller project authors. All rights reserved.
# Use of this source code is governed by Apache 2 LICENSE that can be found in the LICENSE file.

include <linux/input.h>

resource fd_evdev[fd]

# There seems to be nothing special we can do with this fd.
syz_open_dev$mouse(dev ptr[in, string["/dev/input/mouse#"]], id intptr, flags flags[open_flags]) fd
openat$mice(fd const[AT_FDCWD], file ptr[in, string["/dev/input/mice"]], flags flags[open_flags]) fd

syz_open_dev$evdev(dev ptr[in, string["/dev/input/event#"]], id intptr, flags flags[open_flags]) fd_evdev

write$evdev(fd fd_evdev, data ptr[in, array[input_event]], len bytesize[data])

ioctl$EVIOCGVERSION(fd fd_evdev, cmd const[EVIOCGVERSION], arg buffer[out])
ioctl$EVIOCGID(fd fd_evdev, cmd const[EVIOCGID], arg buffer[out])
ioctl$EVIOCGREP(fd fd_evdev, cmd const[EVIOCGREP], arg buffer[out])
ioctl$EVIOCGKEYCODE(fd fd_evdev, cmd const[EVIOCGKEYCODE], arg buffer[out])
ioctl$EVIOCGKEYCODE_V2(fd fd_evdev, cmd const[EVIOCGKEYCODE_V2], arg buffer[out])
ioctl$EVIOCGEFFECTS(fd fd_evdev, cmd const[EVIOCGEFFECTS], arg buffer[out])
ioctl$EVIOCGMASK(fd fd_evdev, cmd const[EVIOCGMASK], arg ptr[in, input_mask])
ioctl$EVIOCGNAME(fd fd_evdev, cmd const[EVIOCGNAME64], arg buffer[out])
ioctl$EVIOCGPHYS(fd fd_evdev, cmd const[EVIOCGPHYS64], arg buffer[out])
ioctl$EVIOCGUNIQ(fd fd_evdev, cmd const[EVIOCGUNIQ64], arg buffer[out])
ioctl$EVIOCGPROP(fd fd_evdev, cmd const[EVIOCGPROP64], arg buffer[out])
ioctl$EVIOCGMTSLOTS(fd fd_evdev, cmd const[EVIOCGMTSLOTS64], arg buffer[out])
ioctl$EVIOCGKEY(fd fd_evdev, cmd const[EVIOCGKEY64], arg buffer[out])
ioctl$EVIOCGLED(fd fd_evdev, cmd const[EVIOCGLED64], arg buffer[out])
ioctl$EVIOCGSND(fd fd_evdev, cmd const[EVIOCGSND64], arg buffer[out])
ioctl$EVIOCGSW(fd fd_evdev, cmd const[EVIOCGSW64], arg buffer[out])
ioctl$EVIOCGBITKEY(fd fd_evdev, cmd const[EVIOCGBITKEY64], arg buffer[out])
ioctl$EVIOCGBITSND(fd fd_evdev, cmd const[EVIOCGBITSND64], arg buffer[out])
ioctl$EVIOCGBITSW(fd fd_evdev, cmd const[EVIOCGBITSW64], arg buffer[out])
ioctl$EVIOCGABS0(fd fd_evdev, cmd const[EVIOCGABS0], arg buffer[out])
ioctl$EVIOCGABS20(fd fd_evdev, cmd const[EVIOCGABS20], arg buffer[out])
ioctl$EVIOCGABS2F(fd fd_evdev, cmd const[EVIOCGABS2F], arg buffer[out])
ioctl$EVIOCGABS3F(fd fd_evdev, cmd const[EVIOCGABS3F], arg buffer[out])

ioctl$EVIOCSREP(fd fd_evdev, cmd const[EVIOCSREP], arg ptr[in, array[int32, 2]])
ioctl$EVIOCSKEYCODE(fd fd_evdev, cmd const[EVIOCSKEYCODE], arg ptr[in, array[int32, 2]])
ioctl$EVIOCSKEYCODE_V2(fd fd_evdev, cmd const[EVIOCSKEYCODE_V2], arg ptr[in, input_keymap_entry])
ioctl$EVIOCSFF(fd fd_evdev, cmd const[EVIOCSFF], arg ptr[in, ff_effect])
ioctl$EVIOCRMFF(fd fd_evdev, cmd const[EVIOCRMFF], arg ptr[in, int32])
ioctl$EVIOCGRAB(fd fd_evdev, cmd const[EVIOCGRAB], arg ptr[in, int32])
ioctl$EVIOCREVOKE(fd fd_evdev, cmd const[EVIOCREVOKE], arg ptr[in, int32])
ioctl$EVIOCSMASK(fd fd_evdev, cmd const[EVIOCSMASK], arg ptr[in, input_mask])
ioctl$EVIOCSCLOCKID(fd fd_evdev, cmd const[EVIOCSCLOCKID], arg ptr[in, int32])
ioctl$EVIOCSABS0(fd fd_evdev, cmd const[EVIOCSABS0], arg ptr[in, input_absinfo])
ioctl$EVIOCSABS20(fd fd_evdev, cmd const[EVIOCSABS20], arg ptr[in, input_absinfo])
ioctl$EVIOCSABS2F(fd fd_evdev, cmd const[EVIOCSABS2F], arg ptr[in, input_absinfo])
ioctl$EVIOCSABS3F(fd fd_evdev, cmd const[EVIOCSABS3F], arg ptr[in, input_absinfo])

ff_effect_type = FF_PERIODIC, FF_CONSTANT, FF_SPRING, FF_FRICTION, FF_DAMPER, FF_INERTIA, FF_RAMP
ff_periodic_effect_wave = FF_SQUARE, FF_TRIANGLE, FF_SINE, FF_SAW_UP, FF_SAW_DOWN, FF_CUSTOM
input_codes = EV_SYN, EV_KEY, EV_REL, EV_ABS, EV_MSC, EV_SW, EV_LED, EV_SND, EV_REP, EV_FF, EV_PWR, EV_FF_STATUS, EV_MAX

input_event {
	time	timeval
	type	flags[input_codes, int16]
	code	int16
	val	int32
}

input_keymap_entry {
	flags	int8
	len	int8[0:32]
	index	int16
	keycode	int32
	scancod	array[int8, 32]
}

ff_effect {
	type	flags[ff_effect_type, int16]
	id	int16
	dir	int16
	trigger	ff_trigger
	replay	ff_replay
	u	ff_effect_u
}

ff_effect_u [
	const	ff_constant_effect
	ramp	ff_ramp_effect
	period	ff_periodic_effect
	cond	array[ff_condition_effect, 2]
	rumble	ff_rumble_effect
]

ff_trigger {
	button	int16
	interv	int16
}

ff_replay {
	len	int16
	delay	int16
}

ff_constant_effect {
	level	int16
	envelop	ff_envelope
}

ff_ramp_effect {
	slevel	int16
	elevel	int16
	envelop	ff_envelope
}

ff_periodic_effect {
	wave		flags[ff_periodic_effect_wave, int16]
	period		int16
	magnit		int16
	offset		int16
	phase		int16
	envelope	ff_envelope
	custom_len	len[custom_data, int32]
	custom_data	ptr[in, array[int16]]
}

ff_condition_effect {
	rsatur	int16
	lsatur	int16
	rcoeff	int16
	lcoeff	int16
	dead	int16
	center	int16
}

ff_rumble_effect {
	smagnit	int16
	wmagnit	int16
}

ff_envelope {
	len	int16
	level	int16
	flen	int16
	flevel	int16
}

input_mask {
	type	flags[input_codes, int32]
	size	bytesize[ptr, int32]
	ptr	ptr64[in, array[int8]]
}

input_absinfo {
	val	int32
	min	int32
	max	int32
	fuzz	int32
	flag	int32
	res	int32
}

define EVIOCGNAME64	EVIOCGNAME(64)
define EVIOCGPHYS64	EVIOCGPHYS(64)
define EVIOCGUNIQ64	EVIOCGUNIQ(64)
define EVIOCGPROP64	EVIOCGPROP(64)
define EVIOCGMTSLOTS64	EVIOCGMTSLOTS(64)
define EVIOCGKEY64	EVIOCGKEY(64)
define EVIOCGLED64	EVIOCGLED(64)
define EVIOCGSND64	EVIOCGSND(64)
define EVIOCGSW64	EVIOCGSW(64)
define EVIOCGBITKEY64	EVIOCGBIT(EV_KEY, 64)
define EVIOCGBITSND64	EVIOCGBIT(EV_SND, 64)
define EVIOCGBITSW64	EVIOCGBIT(EV_SW, 64)
define EVIOCGABS0	EVIOCGABS(0)
define EVIOCGABS20	EVIOCGABS(0x20)
define EVIOCGABS2F	EVIOCGABS(0x2F)
define EVIOCGABS3F	EVIOCGABS(0x3F)
define EVIOCSABS0	EVIOCSABS(0)
define EVIOCSABS20	EVIOCSABS(0x20)
define EVIOCSABS2F	EVIOCSABS(0x2F)
define EVIOCSABS3F	EVIOCSABS(0x3F)
]

gemini-3.1-pro-preview

							input: 215953
							output: 264
							thoughts: 557
						

**My Current Strategy: Exploiting the Xbox One Controller Driver**

Okay, so `syz_open_dev$evdev` is *definitely* defined in `dev_input.txt` - that's great! It looks like I can successfully open an input device. Knowing this, I think I can exploit this to achieve my goals. If I open an input device, `xpad_open` will get called, and that in turn will kick off `xpad_start_input`, which is what submits `irq_out`!

The idea is to leverage the `XTYPE_XBOXONE` device type. I'm thinking I can trigger a disconnect immediately after submission of `irq_out`. `irq_out` gets submitted when the device opens.

Here's the plan, so far. I'll construct a syzlang snippet. First, connect the USB device using `syz_usb_connect`. Then, use `nanosleep` to allow for a tiny bit of time. Then, I'll call `syz_open_dev$evdev` on `/dev/input/event#` to open it. I will use a flag of `0x2`. And finally, I'll immediately disconnect the USB device using `syz_usb_disconnect`, using the handle from the connection.

The smart part is that `syz_open_dev$evdev` will connect to any available `/dev/input/event#`. Since I just connected the USB device, it should be the new one that was just created! If I can open it, then `xpad_open` will be called, submitting `irq_out`. Then, *immediately* after, I'll call `syz_usb_disconnect(r0)`.

This is my hypothesis: this will trigger `xpad_disconnect`, which in turn calls `xpad_stop_output`. Since `irq_out` was *just* submitted, it might still be in a running state. Let's see if this works!

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x0, 0x10000000}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 217245
							output: 267
							thoughts: 407
						

**Analyzing the Persistent Non-Crash**

Okay, still no crash after all this time. I need to rethink my approach. Wait a minute... `syz_open_dev$evdev` is synchronous! That's the key. It means it only returns *after* `xpad_open` completes. Therefore, if `xpad_open` finishes, that means `irq_out` has already been submitted. That also means that `syz_usb_disconnect` is called *after* `irq_out` submission. But `irq_out` completes really fast! If it completes *before* `syz_usb_disconnect`, there's no race at all, and no crash.

The whole point is that `syz_usb_disconnect` needs to be called *concurrently* with `syz_open_dev$evdev` to introduce the race condition I'm after. I need to make them overlap.

Looking at my syzlang code, I can see how to do this. I've got:

```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x0, 0x10000000}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2) (async)
syz_usb_disconnect(r0)
```

The crucial part is using `(async)` with `syz_open_dev$evdev`. That should make them run concurrently! I'm going to try this change and see if it finally triggers the bug. Fingers crossed!

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x0, 0x10000000}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2) (async)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 218481
							output: 308
							thoughts: 439
						

**Debugging the USB Disconnect Issue**

Okay, still no crash, which is frustrating. I'm starting to think the order of operations is key here. Could it be that `syz_usb_disconnect` is running *before* `syz_open_dev$evdev` even gets a chance to start? If that's the case, `xpad_disconnect` is being called before the device is properly open, and then `syz_open_dev$evdev` subsequently fails because the device is, well, *gone*. That explains it.

What we need is for `syz_open_dev$evdev` to kick off *first*, and *then* have `syz_usb_disconnect` run while `xpad_open` is in progress. The obvious solution here is a small delay. We can insert a short `nanosleep` before `syz_usb_disconnect` to give the opening process some time to get going. Here's what the Syzlang code will look like:

```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x0, 0x10000000}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2) (async)
nanosleep(&(0x7f0000000100)={0x0, 0x1000000}, 0x0)
syz_usb_disconnect(r0)
```

Alright, let's give this a shot and see if that resolves the issue. Fingers crossed!

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x0, 0x10000000}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2) (async)
nanosleep(&(0x7f0000000100)={0x0, 0x1000000}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 219798
							output: 265
							thoughts: 2356
						

**Race Condition Analysis and Exploit Strategy for Xbox 360 Wireless Controller Driver**

Okay, so the initial hunt for a crash in the Xbox 360 wireless controller driver hasn't yielded results yet, but I'm getting closer. I'm focusing on a potential use-after-free vulnerability tied to the `irq_out` (output interrupt) URB. The key is to find a narrow window where `xpad_stop_output` might be called concurrently with `irq_out` being active.

My initial thought was that a missed `xpad_irq_out` call might be the cause, which is the URB completion handler. However, I now realize it accesses `xpad->odata_lock` immediately, so if `xpad` gets freed before this handler is run, it's a guaranteed use-after-free!

The crux is timing. `xpad_disconnect` *unconditionally* calls `xpad_stop_output`. That function waits for `irq_out` to complete using `usb_wait_anchor_empty_timeout`. Then `usb_unanchor_urb` is called, which then unchains the URB. Then, `xpad_irq_out` is the completion handler, and is called. 

So the vulnerability occurs if `xpad_stop_output` is called while `irq_out` *is* active. The fact that the crash isn't happening suggests that `irq_out` completes *before* `xpad_stop_output` is called. It's either that or `irq_out` was never even submitted.

The opening of an input device with `syz_open_dev$evdev` might be a red herring; if the wrong device is opened, `xpad_open` might not be called. But with the Xbox 360 Wireless device, I can toggle the `pad_present` flag and trigger `xpad_init_input` which leads to `xpad_led_probe` and submitting `irq_out`.

Here's the new plan: I'll use the `XTYPE_XBOX360W` type and toggle `pad_present` to get `irq_out` going. I need to trigger the disconnect at exactly the right time.

The `syz_usb_ep_write` call is what can be used to send to the IN endpoint. The IN endpoint's completion handler is `xpad_irq_in`. So, writing to this endpoint will kickstart the process. `xpad_irq_in` will call `xpad360w_process_packet` and then schedule `xpad_presence_work`. If `xpad_presence_work` runs at roughly the same time as `syz_usb_disconnect` is called, we'll get there. I'll need to submit the write and the disconnect asynchronously to facilitate the race. The `nanosleep` is there as a very coarse-grained delay, but the `(async)` directive is important. I'll then adjust the delay and try to trigger the crash!

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e0491021401010203010902200001010080fa0904000002ff5d81000705810320000407050203200004"], 0x0)
syz_usb_ep_write(r0, 0x81, 0x2, &(0x7f0000000100)='\x08\x80') (async)
nanosleep(&(0x7f0000000200)={0x0, 0x5000000}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 223129
							output: 266
							thoughts: 3880
						

**Debugging the USB Disconnect Race Condition**

Okay, so I'm trying to figure out this persistent crash I'm seeing.  No luck yet, still, and I need to go through my reasoning again.  First, let's step through the key aspects again.  I was initially looking at `syz_usb_ep_write` with endpoint `0x81`. But `dummy_hcd` uses `ep & 0x7f`. But `0x81` should be right! Why isn't it crashing? It might be that `xpad_presence_work` isn't running.  If that's the case, `irq_out` is never submitted. Why isn't it running? Because `xpad_irq_in` isn't being called! And why isn't that being called? Because `irq_in` isn't submitted. And why not that?  Because `xpad360w_start_input` is failing. Why would that happen? Maybe `xpad_probe` failed. Why did that even fail?

Okay, let's check the device descriptor. It *looks* perfect! Correct length, descriptor type, USB version, all the standard fields match what I expect for the relevant devices. Both endpoints are interrupt endpoints. One is IN (`0x81`), one is OUT (`0x02`). `xpad_probe` itself checks that we have two endpoints, both interrupt type, and it iterates through them. Then, in the code, `xpad_init_output` is called to set up the output URB and this *shouldn't* fail. So, this *should* work! After that, `xpad_probe` fills in the `irq_in` URB using the input endpoint.

Then `xpad360w_start_input` is called, which submits the `irq_in` URB. That, then calls `xpad_inquiry_pad_presence` which is supposed to submit the `irq_out` URB. And, if `usb_submit_urb` succeeds, which it should, `xpad_probe` should succeed and `syz_usb_connect` should return!

If that happens, `syz_usb_ep_write` should trigger a write to the IN endpoint. Then, `xpad_irq_in` should be called, leading to processing in `xpad360w_process_packet`. This means `xpad_presence_work` should be scheduled, then `xpad_init_input` is called and then `xpad_led_probe` is called. That also submits the `irq_out` URB. If `irq_out` completes, then `syz_usb_disconnect` is called. It seems like the race happens when the disconnect is called exactly when the `irq_out` is completing. That would be a tiny window.

So, how can I hit this more reliably? Maybe inject a fault to stall the process, but `usb_wait_anchor_empty_timeout` is not a syscall. Okay, a loop! So, I can try running a program that connects, writes to the endpoint, disconnects and does this a few times.  I have this already.  But syzkaller reproduces it reliably. Is there a way to make it *more* reliable? With the `XTYPE_XBOXONE` type, `irq_out` is submitted when the device is opened. If there is a concurrent open, that could increase the race window. I think that syzkaller's background thread might open the device. The background thread would call `xpad_open`, which then does `xpad_start_input`, and submits `irq_out`. Then, the disconnect path would run and call `xpad_stop_output` concurrently with this.

So, let's try that scenario again, but make sure the open happens. I can open the device myself and make sure it is happening. I can use `openat` and then path to `/dev/input/event0` to make sure the open happens.

Wait, I need to use `syz_open_dev` and `/dev/input/event#`. Okay, I have a program that uses syz_open_dev. Let's see if this does it.

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x0, 0x2) (async)
nanosleep(&(0x7f0000000200)={0x0, 0x1000000}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 228255
							output: 374
							thoughts: 448
						

**Debugging the Event Device Connection**

Okay, still no crash, which means I need to dig deeper. I'm focusing on that `syz_open_dev$evdev` call. I remember that it's designed to open *any* available `/dev/input/event#` device. The critical thing here is that if it picks the *wrong* event device, the `xpad_open` function that I want to trigger won't be called, and I won't see the bug. So, the question becomes: how do I *guarantee* it opens the *right* event device?

Aha! I think I've got it. I can just call `syz_open_dev$evdev` multiple times! Let's force a scenario where we open `/dev/input/event#` with different flags. Maybe the correct device will be selected, at different points in the process.

So, I'll structure the syzlang code like this:
1.  Connect a USB device using `syz_usb_connect`.
2.  Call `syz_open_dev$evdev` three times in succession: Once for read-only access, once for write-only, and once for read-write.
3.  Add a short delay using `nanosleep`.
4.  Finally, disconnect the USB device with `syz_usb_disconnect`.

The hope is that by opening multiple event devices, the code will trigger the behavior that leads to the crash, especially if there's some kind of race condition involved in device selection. Here's how I envision the new code:

```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x0, 0x2) (async)
r2 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x1, 0x2) (async)
r3 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x2) (async)
nanosleep(&(0x7f0000000200)={0x0, 0x1000000}, 0x0)
syz_usb_disconnect(r0)
```

Let's run this and see if it yields any results!

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x0, 0x2) (async)
r2 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x1, 0x2) (async)
r3 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x2) (async)
nanosleep(&(0x7f0000000200)={0x0, 0x1000000}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 229836
							output: 536
							thoughts: 1780
						

**Race Condition Hunt: A Syzkaller Investigation**

Okay, so still no crash, which is frustrating. Let's retrace our steps. Remember `syz_open_dev$evdev` takes an `id` argument, and that's key. If `id` is zero, we're opening `/dev/input/event0`. One opens `/dev/input/event1`, and so on. But wait, looking at `executor/common_linux.h`, `syz_open_dev` is actually using `sprintf` to construct the device path. So the number is the `id`! So we can open several event devices at once.

But what if the device is `event3` or `event4`? We'd need to loop and open them. Let's see... Wait! If we use `XTYPE_XBOX360W`, we can skip all of that. `xpad_presence_work` calls `xpad_init_input`, which calls `xpad_led_probe`, and *that* submits `irq_out`! Bingo! We can trigger `xpad_presence_work` with a presence packet. The current repro uses `syz_usb_connect`, sends some data to `0x81`, sleeps, sends some more, then disconnects.

Why is this not crashing? Ah, `syz_usb_ep_write` uses `USB_RAW_IOCTL_EP_WRITE`. Does `dummy_hcd` support this? Yes, `raw-gadget` does. And `syz_usb_connect` uses `vusb`, implemented via `raw-gadget`. Does `raw-gadget` support interrupt endpoints? Yes! And `xpad_irq_in` is an INTERRUPT endpoint. Does `syz_usb_ep_write` work for interrupt endpoints? Yes. And *xpad_probe* submits `irq_in` with `usb_fill_int_urb`.

So if `irq_in` is submitted, `raw-gadget` will get the URB. Then `syz_usb_ep_write` completes the URB, so `xpad_irq_in` *will* be called, and `xpad360w_process_packet` will be called and then `xpad_presence_work` will be scheduled! Then `xpad_init_input` is called, and `xpad_led_probe` submits `irq_out`! Now, *if* `syz_usb_disconnect` is called EXACTLY when `irq_out` is active, that's it!

The race window is tiny! How to hit it reliably? Can we use `fail_nth` to inject a fault in `usb_wait_anchor_empty_timeout`? No, it's not a syscall. We can loop! Wait, Syzkaller reproduces it reliably. But can we make it *more* reliable?

If we use `XTYPE_XBOXONE`, `irq_out` is submitted when the device is opened. If we can use `syz_open_dev$evdev` to open the device, we can make this more reliable. Let's try opening `event0` through `event5` and then disconnect the device.
```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x0, 0x2) (async)
r2 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x1, 0x2) (async)
r3 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x0, 0x2) (async)
r2 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x1, 0x2) (async)
r3 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x2, 0x2) (async)
r4 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x3, 0x2) (async)
r5 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x4, 0x2) (async)
r6 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x5, 0x2) (async)
nanosleep(&(0x7f0000000200)={0x0, 0x1000000}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 233208
							output: 225
							thoughts: 487
						

**Debugging a Kernel Race Condition**

Okay, still no crash. I need to think this through. Right, `syz_open_dev$evdev` expects the device path string to be *exactly* `/dev/input/event#`. If I include a null terminator, like `/dev/input/event#\x00`, it should still be correct. So why isn't it crashing?

My initial thought was maybe `irq_out` wasn't being submitted when the device opens. Let me go back and double check `xpad_start_xbox_one`. Ah, here it is:

```c
static int xpad_start_xbox_one(struct usb_xpad *xpad)
{
	...
	xpad->init_seq = 0;
	return xpad_try_sending_next_out_packet(xpad);
}
```

And `xpad_try_sending_next_out_packet` *does* submit `irq_out`. So it *is* submitted! The problem is that it likely completes very quickly. I'm trying to cause a race condition, and that means I need to disconnect *precisely* when it's completing. The `nanosleep` might be too crude to get the timing right. 

What if I remove the `nanosleep`? Let's try a different approach, a simpler syzkaller program:

```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x0, 0x2) (async)
syz_usb_disconnect(r0)
```

This looks promising. Let's give this a shot!

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000100)='/dev/input/event#\x00', 0x0, 0x2) (async)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 234488
							output: 301
							thoughts: 478
						

**Debugging the Elusive Crash**

Okay, still no crash. Hmm, something's not right. Could `syz_open_dev$evdev` be failing because the device isn't ready *yet*? Think about it: `syz_usb_connect` returns once the device is enumerated, but udev might still be busy creating the `/dev/input/event#` node! If udev hasn't finished, `syz_open_dev$evdev` will definitely fail. And if that fails, then `xpad_open` *never* gets called, which means the `irq_out` submission never even happens. Ah, that explains it! That's why I'm not seeing a crash.

The question then becomes, how do I wait for udev to do its job? A simple loop to open the device until it succeeds would be ideal, but syzlang doesn't have loops, of course. Okay, I can work with that; the simplest approach is a sleep. I can just introduce a delay of 1 second before attempting to open the device. Let's try implementing that; here is the new syzlang script:

```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2) (async)
nanosleep(&(0x7f0000000100)={0x0, 0x1000000}, 0x0)
syz_usb_disconnect(r0)
```

Alright, let's give this a shot and see if that sleep fixes the issue!

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2) (async)
nanosleep(&(0x7f0000000100)={0x0, 0x1000000}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 235859
							output: 517
							thoughts: 576
						

**Event Device Enumeration and Vulnerability Exploration**

Okay, still no luck with the initial crash attempt. Time to re-evaluate. I'm looking closely at this `syz_open_dev$evdev` call. It takes an `id intptr` argument, which, if I understand correctly, determines which `/dev/input/eventX` device is opened. If `0` is passed, it specifically targets `event0`. The obvious thought then occurs: what if the target device isn't `event0`?

Aha! We can try opening devices from `event0` up to `event9` using the `id` argument of `syz_open_dev$evdev`. Let me write some syzlang to test this idea.

First I'll establish a USB connection, add a delay, then open `event0` to `event4` with different device id's asynchronously. I'll include a small delay so these system calls have time to execute. Then I'll disconnect the USB connection. Hopefully, this enumeration will uncover a potential vulnerability by interacting with different event devices on the system.

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2) (async)
r2 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x1, 0x2) (async)
r3 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x2, 0x2) (async)
r4 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x3, 0x2) (async)
r5 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x4, 0x2) (async)
nanosleep(&(0x7f0000000100)={0x0, 0x1000000}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 237223
							output: 20
							thoughts: 235
						

**Analyzing the Potential for a Crash**

Okay, still no crash, which is frustrating. Let's see... I'm looking at `syz_open_dev` in `executor/common_linux.h`. I recall that function does this:

```c
static long syz_open_dev(volatile long a0, volatile long a1, volatile long a2)
{
	if (a0 == 0xc || a0 == 0xb) {
		// ...
	}
	char buf[128];
	sprintf(buf, (char*)a0, (int)a1);
	return open(buf, a2, 0);
}
```

My initial thought was that if `a0` is something like `/dev/input/event#`, then `sprintf` might replace the `#` with a number. But no, wait, that's not how `sprintf` works. It's expecting a format specifier like `%d`. So, if the input string is literally `/dev/input/event#`, `sprintf` won't do any replacement at all, and it'll just output the same literal string. I need to be more precise about the format string used. Right, I remember that `sprintf` only replaces format specifiers like `%d`, `%s` etc. Okay, let me go back and double check the code around `syz_open_dev` in `executor/common_linux.h`.

no matches

map[Expression:syz_open_dev]

map[Output:]

gemini-3.1-pro-preview

							input: 237812
							output: 17
							thoughts: 19
						

Here's a summary of my thought process:

**Diving into the `open_dev` Implementation**

Okay, so I need to understand how `open_dev` is working. It's time to dig into the code. The logical place to start is `executor/common_linux.h`. That header file is a good candidate for defining low-level system interactions, and the name "common" suggests it houses shared functionality. Let's see what we can find in there regarding the `open_dev` function and its related implementations. I'm expecting to find the nitty-gritty details of device opening – probably some system calls and error handling. I'm hoping it's well-commented so I don't have to spend too long trying to decipher the intent.

map[Expression:open_dev]

map[Output:
Full output is too long, showing 500 out of 1313 lines.
Use more precise expression if possible.

[Documentation/arch/s390/vfio-ap.rst=310=matrix device.
 --
 Documentation/arch/s390/vfio-ap.rst-432-
 Documentation/arch/s390/vfio-ap.rst:433:  open_device:
 Documentation/arch/s390/vfio-ap.rst-434-    The vfio_ap driver uses this callback to register a
 Documentation/arch/s390/vfio-ap.rst-435-    VFIO_GROUP_NOTIFY_SET_KVM notifier callback function for the matrix mdev
 Documentation/arch/s390/vfio-ap.rst:436:    devices. The open_device callback is invoked by userspace to connect the
 Documentation/arch/s390/vfio-ap.rst-437-    VFIO iommu group for the matrix mdev device to the MDEV bus. Access to the
 --
 Documentation/driver-api/vfio.rst=403=similar to a file operations structure::
 --
 Documentation/driver-api/vfio.rst-413-		void	(*detach_ioas)(struct vfio_device *vdev);
 Documentation/driver-api/vfio.rst:414:		int	(*open_device)(struct vfio_device *vdev);
 Documentation/driver-api/vfio.rst-415-		void	(*close_device)(struct vfio_device *vdev);
 --
 Documentation/driver-api/vfio.rst=433=container_of().
 --
 Documentation/driver-api/vfio.rst-464-	  order to unpin pages within the dma_unmap range. Drivers must tolerate
 Documentation/driver-api/vfio.rst:465:	  this callback even before calls to open_device().
 Documentation/driver-api/vfio.rst-466-
 --
 Documentation/userspace-api/media/v4l/capture.c.rst=4=file: media/v4l/capture.c
 --
 Documentation/userspace-api/media/v4l/capture.c.rst-539-
 Documentation/userspace-api/media/v4l/capture.c.rst:540:    static void open_device(void)
 Documentation/userspace-api/media/v4l/capture.c.rst-541-    {
 --
 Documentation/userspace-api/media/v4l/capture.c.rst-655-
 Documentation/userspace-api/media/v4l/capture.c.rst:656:	    open_device();
 Documentation/userspace-api/media/v4l/capture.c.rst-657-	    init_device();
 --
 Documentation/virt/kvm/devices/vfio.rst=56=device file descriptor via VFIO_GROUP_GET_DEVICE_FD in order to support
 Documentation/virt/kvm/devices/vfio.rst:57:drivers which require a kvm pointer to be set in their .open_device()
 Documentation/virt/kvm/devices/vfio.rst-58-callback.  It is the same for device file descriptor via character device
 --
 arch/powerpc/include/asm/lv1call.h=273=LV1_CALL(configure_virtual_uart_irq,                    1, 1, 166 )
 arch/powerpc/include/asm/lv1call.h:274:LV1_CALL(open_device,                                   3, 0, 170 )
 arch/powerpc/include/asm/lv1call.h-275-LV1_CALL(close_device,                                  2, 0, 171 )
 --
 arch/powerpc/platforms/ps3/device-init.c=772=static int ps3_probe_thread(void *data)
 --
 arch/powerpc/platforms/ps3/device-init.c-798-
 arch/powerpc/platforms/ps3/device-init.c:799:	res = lv1_open_device(local->dev.sbd.bus_id, local->dev.sbd.dev_id, 0);
 arch/powerpc/platforms/ps3/device-init.c-800-	if (res) {
 arch/powerpc/platforms/ps3/device-init.c:801:		pr_err("%s:%u: lv1_open_device failed %s\n", __func__,
 arch/powerpc/platforms/ps3/device-init.c-802-		       __LINE__, ps3_result(res));
 --
 arch/powerpc/platforms/ps3/gelic_udbg.c=117=static void __init gelic_debug_init(void)
 --
 arch/powerpc/platforms/ps3/gelic_udbg.c-123-
 arch/powerpc/platforms/ps3/gelic_udbg.c:124:	result = lv1_open_device(GELIC_BUS_ID, GELIC_DEVICE_ID, 0);
 arch/powerpc/platforms/ps3/gelic_udbg.c-125-	if (result)
 --
 arch/powerpc/platforms/ps3/system-bus.c=41=static int ps3_open_hv_device_sb(struct ps3_system_bus_device *dev)
 --
 arch/powerpc/platforms/ps3/system-bus.c-63-
 arch/powerpc/platforms/ps3/system-bus.c:64:	result = lv1_open_device(dev->bus_id, dev->dev_id, 0);
 arch/powerpc/platforms/ps3/system-bus.c-65-
 arch/powerpc/platforms/ps3/system-bus.c-66-	if (result) {
 arch/powerpc/platforms/ps3/system-bus.c:67:		pr_warn("%s:%d: lv1_open_device dev=%u.%u(%s) failed: %s\n",
 arch/powerpc/platforms/ps3/system-bus.c-68-			__func__, __LINE__, dev->match_id, dev->match_sub_id,
 --
 arch/um/drivers/ubd_kern.c=706=static void ubd_close_dev(struct ubd *ubd_dev)
 --
 arch/um/drivers/ubd_kern.c-716-
 arch/um/drivers/ubd_kern.c:717:static int ubd_open_dev(struct ubd *ubd_dev)
 arch/um/drivers/ubd_kern.c-718-{
 --
 arch/um/drivers/ubd_kern.c=829=static int ubd_add(int n, char **error_out)
 --
 arch/um/drivers/ubd_kern.c-855-
 arch/um/drivers/ubd_kern.c:856:	err = ubd_open_dev(ubd_dev);
 arch/um/drivers/ubd_kern.c-857-	if (err) {
 --
 arch/um/drivers/vfio_kern.c=458=static int uml_vfio_read_msix_table(struct uml_vfio_device *dev)
 --
 arch/um/drivers/vfio_kern.c-483-
 arch/um/drivers/vfio_kern.c:484:static void uml_vfio_open_device(struct uml_vfio_device *dev)
 arch/um/drivers/vfio_kern.c-485-{
 --
 arch/um/drivers/vfio_kern.c=645=static int uml_vfio_mc_config(char *str, char **error_out)
 --
 arch/um/drivers/vfio_kern.c-657-		return PTR_ERR(dev);
 arch/um/drivers/vfio_kern.c:658:	uml_vfio_open_device(dev);
 arch/um/drivers/vfio_kern.c-659-	return 0;
 --
 arch/um/drivers/vfio_kern.c=681=static int __init uml_vfio_init(void)
 --
 arch/um/drivers/vfio_kern.c-688-	list_for_each_entry_safe(dev, n, &uml_vfio_devices, list)
 arch/um/drivers/vfio_kern.c:689:		uml_vfio_open_device(dev);
 arch/um/drivers/vfio_kern.c-690-
 --
 block/bdev.c=1212=int lookup_bdev(const char *pathname, dev_t *dev)
 --
 block/bdev.c-1229-	error = -EACCES;
 block/bdev.c:1230:	if (!may_open_dev(&path))
 block/bdev.c-1231-		goto out_path_put;
 --
 drivers/accel/habanalabs/common/habanalabs_ioctl.c=564=static int dram_replaced_rows_info(struct hl_fpriv *hpriv, struct hl_info_args *args)
 --
 drivers/accel/habanalabs/common/habanalabs_ioctl.c-581-
 drivers/accel/habanalabs/common/habanalabs_ioctl.c:582:static int last_err_open_dev_info(struct hl_fpriv *hpriv, struct hl_info_args *args)
 drivers/accel/habanalabs/common/habanalabs_ioctl.c-583-{
 drivers/accel/habanalabs/common/habanalabs_ioctl.c:584:	struct hl_info_last_err_open_dev_time info = {0};
 drivers/accel/habanalabs/common/habanalabs_ioctl.c-585-	struct hl_device *hdev = hpriv->hdev;
 --
 drivers/accel/habanalabs/common/habanalabs_ioctl.c=1005=static int _hl_info_ioctl(struct hl_fpriv *hpriv, void *data,
 --
 drivers/accel/habanalabs/common/habanalabs_ioctl.c-1050-	case HL_INFO_LAST_ERR_OPEN_DEV_TIME:
 drivers/accel/habanalabs/common/habanalabs_ioctl.c:1051:		return last_err_open_dev_info(hpriv, args);
 drivers/accel/habanalabs/common/habanalabs_ioctl.c-1052-
 --
 drivers/bluetooth/hci_vhci.c=34=struct vhci_data {
 --
 drivers/bluetooth/hci_vhci.c-50-
 drivers/bluetooth/hci_vhci.c:51:static int vhci_open_dev(struct hci_dev *hdev)
 drivers/bluetooth/hci_vhci.c-52-{
 --
 drivers/bluetooth/hci_vhci.c=405=static int __vhci_create_device(struct vhci_data *data, __u8 opcode)
 --
 drivers/bluetooth/hci_vhci.c-431-
 drivers/bluetooth/hci_vhci.c:432:	hdev->open  = vhci_open_dev;
 drivers/bluetooth/hci_vhci.c-433-	hdev->close = vhci_close_dev;
 --
 drivers/crypto/intel/qat/qat_common/adf_gen4_vf_mig.c=48=static void adf_gen4_vfmig_reset_device(struct qat_mig_dev *mdev)
 --
 drivers/crypto/intel/qat/qat_common/adf_gen4_vf_mig.c-53-
 drivers/crypto/intel/qat/qat_common/adf_gen4_vf_mig.c:54:static int adf_gen4_vfmig_open_device(struct qat_mig_dev *mdev)
 drivers/crypto/intel/qat/qat_common/adf_gen4_vf_mig.c-55-{
 --
 drivers/crypto/intel/qat/qat_common/adf_gen4_vf_mig.c=997=void adf_gen4_init_vf_mig_ops(struct qat_migdev_ops *vfmig_ops)
 --
 drivers/crypto/intel/qat/qat_common/adf_gen4_vf_mig.c-1001-	vfmig_ops->reset = adf_gen4_vfmig_reset_device;
 drivers/crypto/intel/qat/qat_common/adf_gen4_vf_mig.c:1002:	vfmig_ops->open = adf_gen4_vfmig_open_device;
 drivers/crypto/intel/qat/qat_common/adf_gen4_vf_mig.c-1003-	vfmig_ops->close = adf_gen4_vfmig_close_device;
 --
 drivers/firmware/efi/libstub/file.c=95=static int find_file_option(const efi_char16_t *cmdline, int cmdline_len,
 --
 drivers/firmware/efi/libstub/file.c-127-
 drivers/firmware/efi/libstub/file.c:128:static efi_status_t efi_open_device_path(efi_file_protocol_t **volume,
 drivers/firmware/efi/libstub/file.c-129-					 struct finfo *fi)
 --
 drivers/firmware/efi/libstub/file.c=226=do_builtin:	cmdline	    = builtin_cmdline;
 --
 drivers/firmware/efi/libstub/file.c-245-
 drivers/firmware/efi/libstub/file.c:246:		status = efi_open_device_path(&volume, &fi);
 drivers/firmware/efi/libstub/file.c-247-		if (status == EFI_UNSUPPORTED || status == EFI_NOT_FOUND)
 --
 drivers/gpib/common/gpib_os.c=35=static int command_ioctl(struct gpib_file_private *file_priv, struct gpib_board *board,
 drivers/gpib/common/gpib_os.c-36-			 unsigned long arg);
 drivers/gpib/common/gpib_os.c:37:static int open_dev_ioctl(struct file *filep, struct gpib_board *board, unsigned long arg);
 drivers/gpib/common/gpib_os.c-38-static int close_dev_ioctl(struct file *filep, struct gpib_board *board, unsigned long arg);
 --
 drivers/gpib/common/gpib_os.c=73=static int t1_delay_ioctl(struct gpib_board *board, unsigned long arg);
 drivers/gpib/common/gpib_os.c-74-
 drivers/gpib/common/gpib_os.c:75:static int cleanup_open_devices(struct gpib_file_private *file_priv, struct gpib_board *board);
 drivers/gpib/common/gpib_os.c-76-
 --
 drivers/gpib/common/gpib_os.c=565=int ibclose(struct inode *inode, struct file *filep)
 --
 drivers/gpib/common/gpib_os.c-593-
 drivers/gpib/common/gpib_os.c:594:		cleanup_open_devices(priv, board);
 drivers/gpib/common/gpib_os.c-595-
 --
 drivers/gpib/common/gpib_os.c=611=long ibioctl(struct file *filep, unsigned int cmd, unsigned long arg)
 --
 drivers/gpib/common/gpib_os.c-708-	case IBOPENDEV:
 drivers/gpib/common/gpib_os.c:709:		retval = open_dev_ioctl(filep, board, arg);
 drivers/gpib/common/gpib_os.c-710-		goto done;
 --
 drivers/gpib/common/gpib_os.c=1130=static int status_bytes_ioctl(struct gpib_board *board, unsigned long arg)
 --
 drivers/gpib/common/gpib_os.c-1152-
 drivers/gpib/common/gpib_os.c:1153:static int increment_open_device_count(struct gpib_board *board, struct list_head *head,
 drivers/gpib/common/gpib_os.c-1154-				       unsigned int pad, int sad)
 --
 drivers/gpib/common/gpib_os.c-1188-
 drivers/gpib/common/gpib_os.c:1189:static int subtract_open_device_count(struct gpib_board *board, struct list_head *head,
 drivers/gpib/common/gpib_os.c-1190-				      unsigned int pad, int sad, unsigned int count)
 --
 drivers/gpib/common/gpib_os.c-1217-
 drivers/gpib/common/gpib_os.c:1218:static inline int decrement_open_device_count(struct gpib_board *board, struct list_head *head,
 drivers/gpib/common/gpib_os.c-1219-					      unsigned int pad, int sad)
 drivers/gpib/common/gpib_os.c-1220-{
 drivers/gpib/common/gpib_os.c:1221:	return subtract_open_device_count(board, head, pad, sad, 1);
 drivers/gpib/common/gpib_os.c-1222-}
 drivers/gpib/common/gpib_os.c-1223-
 drivers/gpib/common/gpib_os.c:1224:static int cleanup_open_devices(struct gpib_file_private *file_priv, struct gpib_board *board)
 drivers/gpib/common/gpib_os.c-1225-{
 --
 drivers/gpib/common/gpib_os.c-1236-		if (desc->is_board == 0) {
 drivers/gpib/common/gpib_os.c:1237:			retval = decrement_open_device_count(board, &board->device_list, desc->pad,
 drivers/gpib/common/gpib_os.c-1238-							     desc->sad);
 --
 drivers/gpib/common/gpib_os.c-1248-
 drivers/gpib/common/gpib_os.c:1249:static int open_dev_ioctl(struct file *filep, struct gpib_board *board, unsigned long arg)
 drivers/gpib/common/gpib_os.c-1250-{
 drivers/gpib/common/gpib_os.c:1251:	struct gpib_open_dev_ioctl open_dev_cmd;
 drivers/gpib/common/gpib_os.c-1252-	int retval;
 --
 drivers/gpib/common/gpib_os.c-1255-
 drivers/gpib/common/gpib_os.c:1256:	retval = copy_from_user(&open_dev_cmd, (void __user *)arg, sizeof(open_dev_cmd));
 drivers/gpib/common/gpib_os.c-1257-	if (retval)
 --
 drivers/gpib/common/gpib_os.c-1275-
 drivers/gpib/common/gpib_os.c:1276:	file_priv->descriptors[i]->pad = open_dev_cmd.pad;
 drivers/gpib/common/gpib_os.c:1277:	file_priv->descriptors[i]->sad = open_dev_cmd.sad;
 drivers/gpib/common/gpib_os.c:1278:	file_priv->descriptors[i]->is_board = open_dev_cmd.is_board;
 drivers/gpib/common/gpib_os.c-1279-	mutex_unlock(&file_priv->descriptors_mutex);
 drivers/gpib/common/gpib_os.c-1280-
 drivers/gpib/common/gpib_os.c:1281:	retval = increment_open_device_count(board, &board->device_list, open_dev_cmd.pad,
 drivers/gpib/common/gpib_os.c:1282:					     open_dev_cmd.sad);
 drivers/gpib/common/gpib_os.c-1283-	if (retval < 0)
 --
 drivers/gpib/common/gpib_os.c-1291-
 drivers/gpib/common/gpib_os.c:1292:	open_dev_cmd.handle = i;
 drivers/gpib/common/gpib_os.c:1293:	retval = copy_to_user((void __user *)arg, &open_dev_cmd, sizeof(open_dev_cmd));
 drivers/gpib/common/gpib_os.c-1294-	if (retval)
 --
 drivers/gpib/common/gpib_os.c=1300=static int close_dev_ioctl(struct file *filep, struct gpib_board *board, unsigned long arg)
 --
 drivers/gpib/common/gpib_os.c-1331-
 drivers/gpib/common/gpib_os.c:1332:	retval = decrement_open_device_count(board, &board->device_list, pad, sad);
 drivers/gpib/common/gpib_os.c-1333-
 --
 drivers/gpib/common/gpib_os.c=1499=static int pad_ioctl(struct gpib_board *board, struct gpib_file_private *file_priv,
 --
 drivers/gpib/common/gpib_os.c-1518-	} else {
 drivers/gpib/common/gpib_os.c:1519:		retval = decrement_open_device_count(board, &board->device_list, desc->pad,
 drivers/gpib/common/gpib_os.c-1520-						     desc->sad);
 --
 drivers/gpib/common/gpib_os.c-1525-
 drivers/gpib/common/gpib_os.c:1526:		retval = increment_open_device_count(board, &board->device_list, desc->pad,
 drivers/gpib/common/gpib_os.c-1527-						     desc->sad);
 --
 drivers/gpib/common/gpib_os.c=1535=static int sad_ioctl(struct gpib_board *board, struct gpib_file_private *file_priv,
 --
 drivers/gpib/common/gpib_os.c-1554-	} else {
 drivers/gpib/common/gpib_os.c:1555:		retval = decrement_open_device_count(board, &board->device_list, desc->pad,
 drivers/gpib/common/gpib_os.c-1556-						     desc->sad);
 --
 drivers/gpib/common/gpib_os.c-1561-
 drivers/gpib/common/gpib_os.c:1562:		retval = increment_open_device_count(board, &board->device_list, desc->pad,
 drivers/gpib/common/gpib_os.c-1563-						     desc->sad);
 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c=1444=int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv)
 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c-1477-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c:1478:	r = amdgpu_xcp_open_device(adev, fpriv, file_priv);
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c-1479-	if (r)
 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c=411=void amdgpu_xcp_dev_unplug(struct amdgpu_device *adev)
 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c-432-
 drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c:433:int amdgpu_xcp_open_device(struct amdgpu_device *adev,
 drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c-434-			   struct amdgpu_fpriv *fpriv,
 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.h=175=void amdgpu_xcp_dev_unplug(struct amdgpu_device *adev);
 drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.h:176:int amdgpu_xcp_open_device(struct amdgpu_device *adev,
 drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.h-177-			   struct amdgpu_fpriv *fpriv,
 --
 drivers/gpu/drm/i915/gvt/kvmgt.c=642=static bool __kvmgt_vgpu_exist(struct intel_vgpu *vgpu)
 --
 drivers/gpu/drm/i915/gvt/kvmgt.c-662-
 drivers/gpu/drm/i915/gvt/kvmgt.c:663:static int intel_vgpu_open_device(struct vfio_device *vfio_dev)
 drivers/gpu/drm/i915/gvt/kvmgt.c-664-{
 --
 drivers/gpu/drm/i915/gvt/kvmgt.c=1440=static const struct vfio_device_ops intel_vgpu_dev_ops = {
 --
 drivers/gpu/drm/i915/gvt/kvmgt.c-1442-	.release	= intel_vgpu_release_dev,
 drivers/gpu/drm/i915/gvt/kvmgt.c:1443:	.open_device	= intel_vgpu_open_device,
 drivers/gpu/drm/i915/gvt/kvmgt.c-1444-	.close_device	= intel_vgpu_close_device,
 --
 drivers/hid/hid-appletb-kbd.c=255=static int appletb_kbd_inp_connect(struct input_handler *handler,
 --
 drivers/hid/hid-appletb-kbd.c-284-
 drivers/hid/hid-appletb-kbd.c:285:	rc = input_open_device(handle);
 drivers/hid/hid-appletb-kbd.c-286-	if (rc)
 --
 drivers/input/apm-power.c=48=static int apmpower_connect(struct input_handler *handler,
 --
 drivers/input/apm-power.c-70-
 drivers/input/apm-power.c:71:	error = input_open_device(handle);
 drivers/input/apm-power.c-72-	if (error) {
 --
 drivers/input/evdev.c=371=static void evdev_detach_client(struct evdev *evdev,
 --
 drivers/input/evdev.c-379-
 drivers/input/evdev.c:380:static int evdev_open_device(struct evdev *evdev)
 drivers/input/evdev.c-381-{
 --
 drivers/input/evdev.c-390-	else if (!evdev->open++) {
 drivers/input/evdev.c:391:		retval = input_open_device(&evdev->handle);
 drivers/input/evdev.c-392-		if (retval)
 --
 drivers/input/evdev.c=461=static int evdev_open(struct inode *inode, struct file *file)
 --
 drivers/input/evdev.c-477-
 drivers/input/evdev.c:478:	error = evdev_open_device(evdev);
 drivers/input/evdev.c-479-	if (error)
 --
 drivers/input/input-leds.c=89=static int input_leds_connect(struct input_handler *handler,
 --
 drivers/input/input-leds.c-118-
 drivers/input/input-leds.c:119:	error = input_open_device(&leds->handle);
 drivers/input/input-leds.c-120-	if (error)
 --
 drivers/input/input.c=569=EXPORT_SYMBOL(input_release_device);
 --
 drivers/input/input.c-571-/**
 drivers/input/input.c:572: * input_open_device - open input device
 drivers/input/input.c-573- * @handle: handle through which device is being accessed
 --
 drivers/input/input.c-577- */
 drivers/input/input.c:578:int input_open_device(struct input_handle *handle)
 drivers/input/input.c-579-{
 --
 drivers/input/input.c-619-}
 drivers/input/input.c:620:EXPORT_SYMBOL(input_open_device);
 drivers/input/input.c-621-
 --
 drivers/input/input.c=694=static void input_disconnect_device(struct input_dev *dev)
 --
 drivers/input/input.c-700-	 * not to protect access to dev->going_away but rather to ensure
 drivers/input/input.c:701:	 * that there are no threads in the middle of input_open_device()
 drivers/input/input.c-702-	 */
 --
 drivers/input/input.c=2584=static void input_handle_setup_event_handler(struct input_handle *handle)
 --
 drivers/input/input.c-2603- * and handler's lists so that events can flow through
 drivers/input/input.c:2604: * it once it is opened using input_open_device().
 drivers/input/input.c-2605- *
 --
 drivers/input/joydev.c=185=static void joydev_refresh_state(struct joydev *joydev)
 --
 drivers/input/joydev.c-195-
 drivers/input/joydev.c:196:static int joydev_open_device(struct joydev *joydev)
 drivers/input/joydev.c-197-{
 --
 drivers/input/joydev.c-206-	else if (!joydev->open++) {
 drivers/input/joydev.c:207:		retval = input_open_device(&joydev->handle);
 drivers/input/joydev.c-208-		if (retval)
 --
 drivers/input/joydev.c=257=static int joydev_open(struct inode *inode, struct file *file)
 --
 drivers/input/joydev.c-271-
 drivers/input/joydev.c:272:	error = joydev_open_device(joydev);
 drivers/input/joydev.c-273-	if (error)
 --
 drivers/input/mousedev.c=58=struct mousedev {
 --
 drivers/input/mousedev.c-77-
 drivers/input/mousedev.c:78:	int (*open_device)(struct mousedev *mousedev);
 drivers/input/mousedev.c-79-	void (*close_device)(struct mousedev *mousedev);
 --
 drivers/input/mousedev.c=411=static void mousedev_free(struct device *dev)
 --
 drivers/input/mousedev.c-418-
 drivers/input/mousedev.c:419:static int mousedev_open_device(struct mousedev *mousedev)
 drivers/input/mousedev.c-420-{
 --
 drivers/input/mousedev.c-429-	else if (!mousedev->open++) {
 drivers/input/mousedev.c:430:		retval = input_open_device(&mousedev->handle);
 drivers/input/mousedev.c-431-		if (retval)
 --
 drivers/input/mousedev.c=439=static void mousedev_close_device(struct mousedev *mousedev)
 --
 drivers/input/mousedev.c-453- */
 drivers/input/mousedev.c:454:static int mixdev_open_devices(struct mousedev *mixdev)
 drivers/input/mousedev.c-455-{
 --
 drivers/input/mousedev.c-466-			if (!mousedev->opened_by_mixdev) {
 drivers/input/mousedev.c:467:				if (mousedev_open_device(mousedev))
 drivers/input/mousedev.c-468-					continue;
 --
 drivers/input/mousedev.c=533=static int mousedev_open(struct inode *inode, struct file *file)
 --
 drivers/input/mousedev.c-555-
 drivers/input/mousedev.c:556:	error = mousedev->open_device(mousedev);
 drivers/input/mousedev.c-557-	if (error)
 --
 drivers/input/mousedev.c=842=static struct mousedev *mousedev_create(struct input_dev *dev,
 --
 drivers/input/mousedev.c-872-
 drivers/input/mousedev.c:873:		mousedev->open_device = mixdev_open_devices;
 drivers/input/mousedev.c-874-		mousedev->close_device = mixdev_close_devices;
 --
 drivers/input/mousedev.c-881-
 drivers/input/mousedev.c:882:		mousedev->open_device = mousedev_open_device;
 drivers/input/mousedev.c-883-		mousedev->close_device = mousedev_close_device;
 --
 drivers/input/mousedev.c=935=static int mixdev_add_device(struct mousedev *mousedev)
 --
 drivers/input/mousedev.c-943-	if (mousedev_mix->open) {
 drivers/input/mousedev.c:944:		retval = mousedev_open_device(mousedev);
 drivers/input/mousedev.c-945-		if (retval)
 --
 drivers/leds/trigger/ledtrig-input-events.c=72=static int input_events_connect(struct input_handler *handler, struct input_dev *dev,
 --
 drivers/leds/trigger/ledtrig-input-events.c-89-
 drivers/leds/trigger/ledtrig-input-events.c:90:	ret = input_open_device(handle);
 drivers/leds/trigger/ledtrig-input-events.c-91-	if (ret)
 --
 drivers/macintosh/mac_hid.c=94=static int mac_hid_emumouse_connect(struct input_handler *handler,
 --
 drivers/macintosh/mac_hid.c-120-
 drivers/macintosh/mac_hid.c:121:	error = input_open_device(handle);
 drivers/macintosh/mac_hid.c-122-	if (error) {
 --
 drivers/md/bcache/super.c=691=static int prio_read(struct cache *ca, uint64_t bucket)
 --
 drivers/md/bcache/super.c-734-
 drivers/md/bcache/super.c:735:static int open_dev(struct gendisk *disk, blk_mode_t mode)
 drivers/md/bcache/super.c-736-{
 --
 drivers/md/bcache/super.c=761=static const struct block_device_operations bcache_cached_ops = {
 drivers/md/bcache/super.c-762-	.submit_bio	= cached_dev_submit_bio,
 drivers/md/bcache/super.c:763:	.open		= open_dev,
 drivers/md/bcache/super.c-764-	.release	= release_dev,
 --
 drivers/md/bcache/super.c=769=static const struct block_device_operations bcache_flash_ops = {
 drivers/md/bcache/super.c-770-	.submit_bio	= flash_dev_submit_bio,
 drivers/md/bcache/super.c:771:	.open		= open_dev,
 drivers/md/bcache/super.c-772-	.release	= release_dev,
 --
 drivers/md/dm-ioctl.c=65=static struct rb_root uuid_rb_tree = RB_ROOT;
 drivers/md/dm-ioctl.c-66-
 drivers/md/dm-ioctl.c:67:static void dm_hash_remove_all(bool keep_open_devices, bool mark_deferred, bool only_deferred);
 drivers/md/dm-ioctl.c-68-
 --
 drivers/md/dm-ioctl.c=308=static struct dm_table *__hash_remove(struct hash_cell *hc)
 --
 drivers/md/dm-ioctl.c-335-
 drivers/md/dm-ioctl.c:336:static void dm_hash_remove_all(bool keep_open_devices, bool mark_deferred, bool only_deferred)
 drivers/md/dm-ioctl.c-337-{
 --
 drivers/md/dm-ioctl.c-353-
 drivers/md/dm-ioctl.c:354:		if (keep_open_devices &&
 drivers/md/dm-ioctl.c-355-		    dm_lock_for_deletion(md, mark_deferred, only_deferred)) {
 --
 drivers/md/dm-ioctl.c-370-		dm_put(md);
 drivers/md/dm-ioctl.c:371:		if (likely(keep_open_devices))
 drivers/md/dm-ioctl.c-372-			dm_destroy(md);
 --
 drivers/md/dm-thin-metadata.c=994=int dm_pool_metadata_close(struct dm_pool_metadata *pmd)
 --
 drivers/md/dm-thin-metadata.c-996-	int r;
 drivers/md/dm-thin-metadata.c:997:	unsigned int open_devices = 0;
 drivers/md/dm-thin-metadata.c-998-	struct dm_thin_device *td, *tmp;
 --
 drivers/md/dm-thin-metadata.c-1002-		if (td->open_count)
 drivers/md/dm-thin-metadata.c:1003:			open_devices++;
 drivers/md/dm-thin-metadata.c-1004-		else {
 --
 drivers/md/dm-thin-metadata.c-1010-
 drivers/md/dm-thin-metadata.c:1011:	if (open_devices) {
 drivers/md/dm-thin-metadata.c-1012-		DMERR("attempt to close pmd when %u device(s) are still open",
 drivers/md/dm-thin-metadata.c:1013:		       open_devices);
 drivers/md/dm-thin-metadata.c-1014-		return -EBUSY;
 --
 drivers/md/dm-thin-metadata.c-1031-/*
 drivers/md/dm-thin-metadata.c:1032: * __open_device: Returns @td corresponding to device with id @dev,
 drivers/md/dm-thin-metadata.c-1033- * creating it if @create is set and incrementing @td->open_count.
 --
 drivers/md/dm-thin-metadata.c-1035- */
 drivers/md/dm-thin-metadata.c:1036:static int __open_device(struct dm_pool_metadata *pmd,
 drivers/md/dm-thin-metadata.c-1037-			 dm_thin_id dev, int create,
 --
 drivers/md/dm-thin-metadata.c=1104=static int __create_thin(struct dm_pool_metadata *pmd,
 --
 drivers/md/dm-thin-metadata.c-1135-
 drivers/md/dm-thin-metadata.c:1136:	r = __open_device(pmd, dev, 1, &td);
 drivers/md/dm-thin-metadata.c-1137-	if (r) {
 --
 drivers/md/dm-thin-metadata.c=1159=static int __set_snapshot_details(struct dm_pool_metadata *pmd,
 --
 drivers/md/dm-thin-metadata.c-1165-
 drivers/md/dm-thin-metadata.c:1166:	r = __open_device(pmd, origin, 0, &td);
 drivers/md/dm-thin-metadata.c-1167-	if (r)
 --
 drivers/md/dm-thin-metadata.c=1180=static int __create_snap(struct dm_pool_metadata *pmd,
 --
 drivers/md/dm-thin-metadata.c-1215-
 drivers/md/dm-thin-metadata.c:1216:	r = __open_device(pmd, dev, 1, &td);
 drivers/md/dm-thin-metadata.c-1217-	if (r)
 --
 drivers/md/dm-thin-metadata.c=1249=static int __delete_device(struct dm_pool_metadata *pmd, dm_thin_id dev)
 --
 drivers/md/dm-thin-metadata.c-1255-	/* TODO: failure should mark the transaction invalid */
 drivers/md/dm-thin-metadata.c:1256:	r = __open_device(pmd, dev, 0, &td);
 drivers/md/dm-thin-metadata.c-1257-	if (r)
 --
 drivers/md/dm-thin-metadata.c=1495=int dm_pool_open_thin_device(struct dm_pool_metadata *pmd, dm_thin_id dev,
 --
 drivers/md/dm-thin-metadata.c-1501-	if (!pmd->fail_io)
 drivers/md/dm-thin-metadata.c:1502:		r = __open_device(pmd, dev, 0, td);
 drivers/md/dm-thin-metadata.c-1503-	pmd_write_unlock(pmd);
 --
 drivers/net/ethernet/chelsio/cxgb/common.h=221=struct adapter {
 --
]
]

gemini-3.1-pro-preview

							input: 248874
							output: 345
							thoughts: 2441
						

**Race Condition Analysis and Exploit Development**

Okay, let's break this down. My initial thought was, "aha, `syz_open_dev` in `executor/common_linux.h` uses `sprintf` to construct a device path, and if we can control that path, we can control the device opened." Specifically, with the string `"/dev/input/event#"` in `dev_input.txt`, Syzkaller's compiler substitutes the `#` with `%d`, so by supplying  `"/dev/input/event#"` to `syz_open_dev$evdev`, it'll open something like `/dev/input/event0`. My thinking was that by opening `/dev/input/event0`, we trigger the `xpad_open` function. I initially figured it would crash because of a timing issue with the interrupt output (`irq_out`). If `irq_out` completed *before* `syz_usb_disconnect` was called, there's no race.

I started thinking, "how can we make the race happen?", with the initial thought that using `XTYPE_XBOX360W` and toggling `pad_present` could trigger the race, but I'd already tried that and it didn't crash. That led me to the conclusion that `xpad_led_probe` asynchronously submits `irq_out` via `set_brightness_work`. Since this asynchronous submission means `xpad_presence_work` finished before `irq_out`, there's no way to reliably trigger the race. `xpad_disconnect` calls `xpad_deinit_input`, then the `led_classdev_unregister` function and `flush_work(&led_cdev->set_brightness_work)`. Because `flush_work` waits for the `set_brightness_work` workqueue to finish, this means that when `flush_work` finishes, it already submitted `irq_out`. Then, the asynchronous call and the `input_unregister_device` function complete, causing the potential race to disappear, specifically with `XTYPE_XBOX360W`.

Then I moved on to `XTYPE_XBOXONE`. In the case of this device, `irq_out` is submitted by `xpad_start_xbox_one`, called by `xpad_start_input` which in turn is called by `xpad_open`. Opening the device via `syz_open_dev$evdev` calls `xpad_open`. So, `xpad_open` calls `xpad_start_input`, submitting `irq_out`, and then returns. After this the device is disconnected. `xpad_disconnect` calls `xpad_deinit_input`, which then calls `input_unregister_device` and `xpad_close`, followed by `xpad_stop_output`. Because `xpad_close` is called during the execution of `input_unregister_device`, and if it takes some time, `irq_out` will have completed *before* `xpad_stop_output` is called.

The key observation is that `xpad_close` is called during `input_unregister_device`. So, is there any way to ensure `irq_out` is submitted *after* `xpad_close`? No, because it is called when the device is closed. However, can we call `irq_out` concurrently with `xpad_disconnect`? The answer is `xpad_play_effect`! By opening the device and calling `ioctl(EVIOCSFF)` to play a force feedback effect, `ioctl(EVIOCSFF)` will call `xpad_play_effect`, which in turn submits `irq_out`. By calling `ioctl(EVIOCSFF)` concurrently with `syz_usb_disconnect`, we can trigger the race. My next step was to confirm this in `xpad_play_effect`! The code `xpad_play_effect` indeed calls `xpad_try_sending_next_out_packet`, meaning `irq_out` gets submitted!

So, by calling `ioctl(EVIOCSFF)` concurrently with `syz_usb_disconnect`, we can hit the race! So I wrote a Syzlang program to do this. I've set up a connection with `syz_usb_connect`, added a short `nanosleep` call, opened the device with `syz_open_dev$evdev`, and then issue the `ioctl$EVIOCSFF` call as an asynchronous operation, followed by `syz_usb_disconnect`. I can verify that `0x40304580` is `E

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2)
ioctl$EVIOCSFF(r1, 0x40304580, &(0x7f0000000300)={0x50, 0xffff, 0x0, {0x0, 0x0}, {0x0, 0x0}, @rumble={0xffff, 0xffff}}) (async)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 252716
							output: 338
							thoughts: 321
						

**Analyzing the `ioctl$EVIOCSFF` System Call**

Okay, still no crash, which means I need to re-examine my approach to exploiting this. Looking at the call, I realize I need to understand the `cmd` argument for the `ioctl`. Specifically, I was concerned about the value to pass as the `cmd`. The documentation specifies `cmd const[EVIOCSFF]`. I was thinking that if I pass a raw hex value like `0x40304580`, it might get rejected by a parsing check for `EVIOCSFF`. But then I remember that the parser *does* accept that hex value if it matches the defined constant.

Now, let's unpack `EVIOCSFF`. It's defined as `_IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect))`. I know `sizeof(struct ff_effect)` is 44 bytes, and `_IOC_WRITE` is equivalent to 1. So, that means the calculated value of `EVIOCSFF` would be `0x402c4580`, which is the hex equivalent.

But wait, why calculate it? I'm wondering if I can simply just use `0x0`, and let Syzkaller populate the value based on the `const` constraint. Thinking about it, the `cmd const[EVIOCSFF]` in the syzlang definition suggests that I can omit it, or use `0x0`. That *could* be the key. My Syzkaller memory tells me that if something is `const`, I *must* provide the exact value, or specify `0x0` which will instruct Syzkaller to fill in the correct value.

I really need to double check the Syzkaller description for `dev_input.txt` again. And yes:

```
ioctl$EVIOCSFF(fd fd_evdev, cmd const[EVIOCSFF], arg ptr[in, ff_effect])
```
It looks like I can definitely use `0x0` for the `cmd` argument, and Syzkaller will automatically substitute the correct value, which should be `EVIOCSFF`. I'll try `0x0` for `cmd`, and see if this gets me further.

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2)
ioctl$EVIOCSFF(r1, 0x0, &(0x7f0000000300)={0x50, 0xffff, 0x0, {0x0, 0x0}, {0x0, 0x0}, @rumble={0xffff, 0xffff}}) (async)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 253902
							output: 395
							thoughts: 893
						

**Analyzing the Force Feedback Mechanism**

Okay, still no crash, which means I need to carefully examine how the force feedback effects are triggered. The `ioctl$EVIOCSFF` call is what uploads the effect data, but I'm realizing it's *not* what actually plays it. The key, it seems, is `xpad_play_effect`, which is called when the effect is PLAYED.

To play the effect, a simple `input_event` needs to be written to the device. Let me refresh my understanding... I need an `input_event` struct, where the `type` is `EV_FF`, the `code` is the effect ID (received from EVIOCSFF), and the `value` is `1` to indicate 'play'.

`xpad_init_ff` is interesting; it sets `ff->upload = xpad_play_effect`, and `input_ff_create_memless` sets `ff->play = xpad_play_effect`. So `xpad_play_effect` is definitely the right function. And it *is* called when we PLAY the effect.

So, to recap: `EVIOCSFF` uploads, and a subsequent `input_event` write triggers the play.

Now, let's look at that syzlang code... `EV_FF` is `0x15`, and the effect ID returned by `EVIOCSFF` should be used for the `code`. If we're uploading the first effect, its ID is indeed `0`. So, the `input_event` should be: `type = EV_FF (0x15), code = 0, value = 1` which results in: `write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18)`

Alright, let's try this with the syzlang code. I've updated the script to include the `write` call after the `ioctl$EVIOCSFF`. Let's see if this plays the effect and triggers the crash!

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2)
ioctl$EVIOCSFF(r1, 0x0, &(0x7f0000000300)={0x50, 0xffff, 0x0, {0x0, 0x0}, {0x0, 0x0}, @rumble={0xffff, 0xffff}})
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 255699
							output: 635
							thoughts: 1442
						

**Debugging the Force Feedback Crash**

Okay, still no crash after that first attempt. I need to retrace my steps and figure out why. The `write$evdev` call uses a `data ptr[in, array[input_event]]`, and I've verified that the `input_event` struct format is correct, so `[{{0x0, 0x0}, 0x15, 0x0, 0x1}]` *should* be valid input.

The question then becomes: is `xpad_play_effect` even *being* called? Let's trace it back. I need to check `input_ff_create_memless`, and I see now that `ff->playback` points to the `play_effect` function argument of the create call.

So, when is `ff->playback` *actually* used? It's when an `EV_FF` event is written. Examining the `input_ff_event` function makes this clear. Now, where do these events come from? `evdev_write` calls `input_inject_event`, and *that* calls `input_handle_event` which finally calls `input_ff_event`! So yes, `xpad_play_effect` *is* being called, and it submits `irq_out`.

If `irq_out` is submitted, it completes. The hypothesis is still that `syz_usb_disconnect` called concurrently would cause the crash. Hmm, maybe `irq_out` completes too quickly?

Alright, let's see...if I send *multiple* `write$evdev` calls, then I can submit `irq_out` multiple times! This increases the chances of hitting the race condition. Time to generate a new Syzlang program that exploits this approach.

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2)
ioctl$EVIOCSFF(r1, 0x0, &(0x7f0000000300)={0x50, 0xffff, 0x0, {0x0, 0x0}, {0x0, 0x0}, @rumble={0xffff, 0xffff}})
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 258202
							output: 556
							thoughts: 1715
						

**Analyzing the Race Condition in the xpad Driver**

Okay, so still no crash, which is puzzling. Let's retrace the execution path. The `xpad_play_effect` function's check for the effect type, specifically `FF_RUMBLE` (0x50), seems correct. The magnitudes are extracted, and then a spinlock is acquired. The code then enters the `switch` statement, which correctly determines that the device is of type `XTYPE_XBOXONE`. It correctly constructs the command to activate the rumble and sets the `packet->pending` flag. Crucially, `xpad_try_sending_next_out_packet` is called, which then submits `irq_out`.

The question is, why didn't this crash? I suspect the timing of the `syz_usb_disconnect` function call is the key. The problem is that it might be getting called before `write$evdev` starts, or completes. If `syz_usb_disconnect` runs before `write$evdev` and we use `(async)` for `write$evdev` calls, then `write$evdev` might run in a separate thread. `syz_usb_disconnect` runs in the main thread. If the main thread doesn't wait, it could call `syz_usb_disconnect` immediately. This then calls `xpad_disconnect`, `xpad_deinit_input`, `input_unregister_device`, `xpad_close`, and finally `xpad_stop_output`. If `write$evdev` has not started, `irq_out` is NOT active, and when `xpad_stop_output` returns, the `xpad` device has been freed. If `write$evdev` then starts, it will call `evdev_write`, but `evdev_write` checks if the device is disconnected! If the device is disconnected, then `evdev_write` returns an error, and `xpad_play_effect` is never called.

We need `write$evdev` to start BEFORE `syz_usb_disconnect` happens, to hit the race. If we don't use `(async)` for the first `write$evdev`, it will wait for it to finish. But, if it finishes, `irq_out` could have already completed because it completes very quickly. Thus we want `syz_usb_disconnect` and `write$evdev` to run CONCURRENTLY to hit the race.

The solution is to insert a `nanosleep` in the main thread to allow the async threads to start before calling `syz_usb_disconnect`, thus increasing the chance to hit the race! So I will write this syzlang code:
```syzlang
r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2)
ioctl$EVIOCSFF(r1, 0x0, &(0x7f0000000300)={0x50, 0xffff, 0x0, {0x0, 0x0}, {0x0, 0x0}, @rumble={0xffff, 0xffff}})
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2)
ioctl$EVIOCSFF(r1, 0x0, &(0x7f0000000300)={0x50, 0xffff, 0x0, {0x0, 0x0}, {0x0, 0x0}, @rumble={0xffff, 0xffff}})
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
nanosleep(&(0x7f0000000100)={0x0, 0x1000000}, 0x0)
syz_usb_disconnect(r0)]

map[CoverageID: ReproducedBugTitle: ReproducedCrashReport:]

gemini-3.1-pro-preview

							input: 261529
							output: 431
							thoughts: 5008
						

**Race Condition in `xpad` Driver: A Deep Dive**

Okay, so I've been digging into this potential crash, and it seems like the key lies in a race condition within the `xpad` driver when dealing with Xbox controllers. Specifically, I need to figure out how to trigger a situation where `irq_out` (an interrupt-driven output) is active while the driver is disconnecting.

First, I confirmed the size of `input_event` and the structure of my intended FF effect. Everything checks out with how I'm setting up my IOCTL calls; but it still didn't crash. My initial thought was `EVIOCSFF` failing, but the code shows it sets capabilities correctly. So, something else is at play.

The crucial insight is that the critical race condition isn't in submitting the USB interrupt, but in its completion coinciding with the shutdown process.  There are a few ways to potentially trigger `irq_out`:  opening the device (XBOXONE), sending a presence packet (XBOX360W), sending an LED command (XBOX360 & 360W), or sending a force feedback effect (all types). I can't send an LED command directly because of sandboxing restrictions in `syzkaller`, so I'm focusing on the others.

Initially, I tried calling `syz_usb_ep_write` to send a presence packet, but this wasn't the correct path. It led me down the route of `xpad_presence_work`, which calls a series of routines that do *asynchronous* `irq_out` submissions.  Specifically, `xpad_led_probe` triggers `set_brightness_work` which in turn submits `irq_out` via `led_set_brightness`. The asynchronous nature of `set_brightness_work` is important, because I need it to be *concurrent* with the `syz_usb_disconnect` to trigger the race.

The problem, though, is that the `flush_work` called by `led_classdev_unregister` blocks until `set_brightness_work` *finishes*.  So, for `XTYPE_XBOX360W`, the asynchronous `irq_out` completion would always occur *before* the critical `xpad_stop_output` code.  Therefore, no race with that device.

But let's look at `XTYPE_XBOXONE`. This one is interesting: the `irq_out` is submitted by `xpad_start_xbox_one`, which is called from `xpad_start_input`. And `xpad_start_input` is called from `xpad_open`.  So, if I open the device, that starts everything.  Then, when I disconnect the device via `syz_usb_disconnect`, a closing sequence is initiated that triggers `xpad_stop_output`.

The key is that `xpad_close` is called during the disconnection, which potentially overlaps with the `irq_out` that was started earlier.  So, for `XBOXONE`, the `irq_out` is submitted *before* the disconnect sequence is triggered.

Now, my idea is to trigger the race.  I can inject an effect (via `ioctl$EVIOCSFF`) and then a play event (`EV_FF`). `xpad_play_effect` will submit `irq_out`. If I can execute the disconnect concurrently, then it will crash.  However, `input_unregister_device` sets `dev->going_away`, which drops any *new* events.  I *must* write the `EV_FF` event *before* `input_unregister_device` sets `dev->going_away`.  If done correctly, I should have a chance.  The question is: can `irq_out` complete *after* the close?

If I can send *multiple* `EV_FF` events, then the `irq_out` will be resubmitted each time. This allows me to delay the completion.  But, on closer look, if there are multiple calls to `xpad_try_sending_next_out_packet`, it just overwrites the same packet.  So, I can't chain these together, and I only get one call.

Now I am at the crux of the problem. If I send multiple FF events, I'm basically overwriting the `packet->pending = true`. The `irq_out` can be delayed if multiple output packets were used. Since I only have three output packets, I will try to submit those three packets and see if this delays things.

But then, I had another insight.  If `xpad_irq_out` is running

map[CandidateReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2)
ioctl$EVIOCSFF(r1, 0x0, &(0x7f0000000300)={0x50, 0xffff, 0x0, {0x0, 0x0}, {0x0, 0x0}, @rumble={0xffff, 0xffff}})
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
syz_usb_disconnect(r0) ReproOpts:{"procs": 1, "sandbox": "none", "fault_call": -1, "fault_nth": 0}]

map[CandidateReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1, 0x0}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200)='/dev/input/event#\x00', 0x0, 0x2)
ioctl$EVIOCSFF(r1, 0x0, &(0x7f0000000300)={0x50, 0xffff, 0x0, {0x0, 0x0}, {0x0, 0x0}, @rumble={0xffff, 0xffff}})
write$evdev(r1, &(0x7f0000000400)=[{{0x0, 0x0}, 0x15, 0x0, 0x1}], 0x18) (async)
syz_usb_disconnect(r0) ReproOpts:{"procs": 1, "sandbox": "none", "fault_call": -1, "fault_nth": 0}]

map[ReproSyz:r0 = syz_usb_connect(0x0, 0x32, &(0x7f0000000000)=ANY=[@ANYBLOB="12010002ffffff405e04d1021401010203010902200001010080fa0904000002ff5dd0000705810320000407050203200004"], 0x0)
nanosleep(&(0x7f0000000100)={0x1}, 0x0)
r1 = syz_open_dev$evdev(&(0x7f0000000200), 0x0, 0x2)
ioctl$EVIOCSFF(r1, 0x0, &(0x7f0000000300)={0x50, 0xffff, 0x0, {}, {}, @rumble={0xffff, 0xffff}})
write$evdev(r1, &(0x7f0000000400)=[{{}, 0x15, 0x0, 0x1}], 0x18) (async)
syz_usb_disconnect(r0)
]

reproducer did not crash

map[ReproducedBugTitle: ReproducedCrashReport:]