syzbot

map[AckedBy:<nil> Fixes:map[Hash:328de1c519c5c0925151cae47944a1c1a0333bcd Title:HID: mcp2221: add GPIO functionality support] KernelBranch:master KernelCommit:5200f5f493f79f14bbdc349e402a40dfb32f23c8 KernelRepo:git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git PatchDescription:HID: mcp2221: fix OOB read in mcp2221_raw_event()

syzbot reported a slab-out-of-bounds read in mcp2221_raw_event(). This
happens because the driver does not validate the size of the incoming
HID report and blindly processes it based on the command byte data[0],
without verifying if the report is actually a response to the command
the driver just sent.

If the device sends an MCP2221_GPIO_SET (0x50) input report before any
GPIO operations are performed (or if a malicious device injects one),
mcp->gp_idx is still 0. The expression mcp->gp_idx - 1 results in -1,
causing the code to access data[-1], which reads out of the bounds of
the URB transfer buffer.

To fix this, ensure that the report size is at least 64 bytes (the
expected report size for MCP2221). Also, verify that the incoming report
matches the currently pending command by checking data[0] !=
mcp->txbuf[0]. Since mcp->txbuf[0] and mcp->gp_idx are always set
together when sending GPIO commands, this check inherently guarantees
that mcp->gp_idx is valid and correctly initialized for the specific
command being processed, preventing the out-of-bounds access. PatchDiff:diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index e4ddd8e92..7f4f2110b 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -861,6 +861,12 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 	u8 *buf;
 	struct mcp2221 *mcp = hid_get_drvdata(hdev);
 
+	if (unlikely(size < 64))
+		return 1;
+
+	if (data[0] != mcp->txbuf[0])
+		return 1;
+
 	switch (data[0]) {
 
 	case MCP2221_I2C_WR_DATA:
 Recipients:[map[Email:bentiss@kernel.org Name:Benjamin Tissoires To:true] map[Email:gupt21@gmail.com Name:Rishi Gupta To:true] map[Email:jikos@kernel.org Name:Jiri Kosina To:true] map[Email:linux-i2c@vger.kernel.org Name: To:true] map[Email:linux-input@vger.kernel.org Name: To:true] map[Email:linux-kernel@vger.kernel.org Name: To:false]] ReportedBy:<nil> ReviewedBy:<nil> TestedBy:<nil>]

map[KernelBranch:master KernelCommit:5200f5f493f79f14bbdc349e402a40dfb32f23c8 KernelRepo:git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git]

map[SimplifiedCRepro:// autogenerated by syzkaller (https://github.com/google/syzkaller)

#define _GNU_SOURCE 

#include <endian.h>
#include <errno.h>
#include <fcntl.h>
#include <stdarg.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mount.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>

#include <linux/usb/ch9.h>

static unsigned long long procid;

static void sleep_ms(uint64_t ms)
{
	usleep(ms * 1000);
}

#define MAX_FDS 30

#define USB_MAX_IFACE_NUM 4
#define USB_MAX_EP_NUM 32
#define USB_MAX_FDS 6

struct usb_endpoint_index {
	struct usb_endpoint_descriptor desc;
	int handle;
};

struct usb_iface_index {
	struct usb_interface_descriptor* iface;
	uint8_t bInterfaceNumber;
	uint8_t bAlternateSetting;
	uint8_t bInterfaceClass;
	struct usb_endpoint_index eps[USB_MAX_EP_NUM];
	int eps_num;
};

struct usb_device_index {
	struct usb_device_descriptor* dev;
	struct usb_config_descriptor* config;
	uint8_t bDeviceClass;
	uint8_t bMaxPower;
	int config_length;
	struct usb_iface_index ifaces[USB_MAX_IFACE_NUM];
	int ifaces_num;
	int iface_cur;
};

struct usb_info {
	int fd;
	struct usb_device_index index;
};

static struct usb_info usb_devices[USB_MAX_FDS];

static struct usb_device_index* lookup_usb_index(int fd)
{
	for (int i = 0; i < USB_MAX_FDS; i++) {
		if (__atomic_load_n(&usb_devices[i].fd, __ATOMIC_ACQUIRE) == fd)
			return &usb_devices[i].index;
	}
	return NULL;
}

static int usb_devices_num;

static bool parse_usb_descriptor(const char* buffer, size_t length, struct usb_device_index* index)
{
	if (length < sizeof(*index->dev) + sizeof(*index->config))
		return false;
	memset(index, 0, sizeof(*index));
	index->dev = (struct usb_device_descriptor*)buffer;
	index->config = (struct usb_config_descriptor*)(buffer + sizeof(*index->dev));
	index->bDeviceClass = index->dev->bDeviceClass;
	index->bMaxPower = index->config->bMaxPower;
	index->config_length = length - sizeof(*index->dev);
	index->iface_cur = -1;
	size_t offset = 0;
	while (true) {
		if (offset + 1 >= length)
			break;
		uint8_t desc_length = buffer[offset];
		uint8_t desc_type = buffer[offset + 1];
		if (desc_length <= 2)
			break;
		if (offset + desc_length > length)
			break;
		if (desc_type == USB_DT_INTERFACE && index->ifaces_num < USB_MAX_IFACE_NUM) {
			struct usb_interface_descriptor* iface = (struct usb_interface_descriptor*)(buffer + offset);
			index->ifaces[index->ifaces_num].iface = iface;
			index->ifaces[index->ifaces_num].bInterfaceNumber = iface->bInterfaceNumber;
			index->ifaces[index->ifaces_num].bAlternateSetting = iface->bAlternateSetting;
			index->ifaces[index->ifaces_num].bInterfaceClass = iface->bInterfaceClass;
			index->ifaces_num++;
		}
		if (desc_type == USB_DT_ENDPOINT && index->ifaces_num > 0) {
			struct usb_iface_index* iface = &index->ifaces[index->ifaces_num - 1];
			if (iface->eps_num < USB_MAX_EP_NUM) {
				memcpy(&iface->eps[iface->eps_num].desc, buffer + offset, sizeof(iface->eps[iface->eps_num].desc));
				iface->eps_num++;
			}
		}
		offset += desc_length;
	}
	return true;
}

static struct usb_device_index* add_usb_index(int fd, const char* dev, size_t dev_len)
{
	int i = __atomic_fetch_add(&usb_devices_num, 1, __ATOMIC_RELAXED);
	if (i >= USB_MAX_FDS)
		return NULL;
	if (!parse_usb_descriptor(dev, dev_len, &usb_devices[i].index))
		return NULL;
	__atomic_store_n(&usb_devices[i].fd, fd, __ATOMIC_RELEASE);
	return &usb_devices[i].index;
}

struct vusb_connect_string_descriptor {
	uint32_t len;
	char* str;
} __attribute__((packed));

struct vusb_connect_descriptors {
	uint32_t qual_len;
	char* qual;
	uint32_t bos_len;
	char* bos;
	uint32_t strs_len;
	struct vusb_connect_string_descriptor strs[0];
} __attribute__((packed));

static const char default_string[] = {
    8, USB_DT_STRING,
    's', 0, 'y', 0, 'z', 0
};

static const char default_lang_id[] = {
    4, USB_DT_STRING,
    0x09, 0x04
};

static bool lookup_connect_response_in(int fd, const struct vusb_connect_descriptors* descs,
				       const struct usb_ctrlrequest* ctrl,
				       struct usb_qualifier_descriptor* qual,
				       char** response_data, uint32_t* response_length)
{
	struct usb_device_index* index = lookup_usb_index(fd);
	uint8_t str_idx;
	if (!index)
		return false;
	switch (ctrl->bRequestType & USB_TYPE_MASK) {
	case USB_TYPE_STANDARD:
		switch (ctrl->bRequest) {
		case USB_REQ_GET_DESCRIPTOR:
			switch (ctrl->wValue >> 8) {
			case USB_DT_DEVICE:
				*response_data = (char*)index->dev;
				*response_length = sizeof(*index->dev);
				return true;
			case USB_DT_CONFIG:
				*response_data = (char*)index->config;
				*response_length = index->config_length;
				return true;
			case USB_DT_STRING:
				str_idx = (uint8_t)ctrl->wValue;
				if (descs && str_idx < descs->strs_len) {
					*response_data = descs->strs[str_idx].str;
					*response_length = descs->strs[str_idx].len;
					return true;
				}
				if (str_idx == 0) {
					*response_data = (char*)&default_lang_id[0];
					*response_length = default_lang_id[0];
					return true;
				}
				*response_data = (char*)&default_string[0];
				*response_length = default_string[0];
				return true;
			case USB_DT_BOS:
				*response_data = descs->bos;
				*response_length = descs->bos_len;
				return true;
			case USB_DT_DEVICE_QUALIFIER:
				if (!descs->qual) {
					qual->bLength = sizeof(*qual);
					qual->bDescriptorType = USB_DT_DEVICE_QUALIFIER;
					qual->bcdUSB = index->dev->bcdUSB;
					qual->bDeviceClass = index->dev->bDeviceClass;
					qual->bDeviceSubClass = index->dev->bDeviceSubClass;
					qual->bDeviceProtocol = index->dev->bDeviceProtocol;
					qual->bMaxPacketSize0 = index->dev->bMaxPacketSize0;
					qual->bNumConfigurations = index->dev->bNumConfigurations;
					qual->bRESERVED = 0;
					*response_data = (char*)qual;
					*response_length = sizeof(*qual);
					return true;
				}
				*response_data = descs->qual;
				*response_length = descs->qual_len;
				return true;
			default:
				break;
			}
			break;
		default:
			break;
		}
		break;
	default:
		break;
	}
	return false;
}

typedef bool (*lookup_connect_out_response_t)(int fd, const struct vusb_connect_descriptors* descs,
					      const struct usb_ctrlrequest* ctrl, bool* done);

static bool lookup_connect_response_out_generic(int fd, const struct vusb_connect_descriptors* descs,
						const struct usb_ctrlrequest* ctrl, bool* done)
{
	switch (ctrl->bRequestType & USB_TYPE_MASK) {
	case USB_TYPE_STANDARD:
		switch (ctrl->bRequest) {
		case USB_REQ_SET_CONFIGURATION:
			*done = true;
			return true;
		default:
			break;
		}
		break;
	}
	return false;
}

struct vusb_descriptor {
	uint8_t req_type;
	uint8_t desc_type;
	uint32_t len;
	char data[0];
} __attribute__((packed));

struct vusb_descriptors {
	uint32_t len;
	struct vusb_descriptor* generic;
	struct vusb_descriptor* descs[0];
} __attribute__((packed));

struct vusb_response {
	uint8_t type;
	uint8_t req;
	uint32_t len;
	char data[0];
} __attribute__((packed));

struct vusb_responses {
	uint32_t len;
	struct vusb_response* generic;
	struct vusb_response* resps[0];
} __attribute__((packed));

static bool lookup_control_response(const struct vusb_descriptors* descs, const struct vusb_responses* resps,
				    struct usb_ctrlrequest* ctrl, char** response_data, uint32_t* response_length)
{
	int descs_num = 0;
	int resps_num = 0;
	if (descs)
		descs_num = (descs->len - offsetof(struct vusb_descriptors, descs)) / sizeof(descs->descs[0]);
	if (resps)
		resps_num = (resps->len - offsetof(struct vusb_responses, resps)) / sizeof(resps->resps[0]);
	uint8_t req = ctrl->bRequest;
	uint8_t req_type = ctrl->bRequestType & USB_TYPE_MASK;
	uint8_t desc_type = ctrl->wValue >> 8;
	if (req == USB_REQ_GET_DESCRIPTOR) {
		int i;
		for (i = 0; i < descs_num; i++) {
			struct vusb_descriptor* desc = descs->descs[i];
			if (!desc)
				continue;
			if (desc->req_type == req_type && desc->desc_type == desc_type) {
				*response_length = desc->len;
				if (*response_length != 0)
					*response_data = &desc->data[0];
				else
					*response_data = NULL;
				return true;
			}
		}
		if (descs && descs->generic) {
			*response_data = &descs->generic->data[0];
			*response_length = descs->generic->len;
			return true;
		}
	} else {
		int i;
		for (i = 0; i < resps_num; i++) {
			struct vusb_response* resp = resps->resps[i];
			if (!resp)
				continue;
			if (resp->type == req_type && resp->req == req) {
				*response_length = resp->len;
				if (*response_length != 0)
					*response_data = &resp->data[0];
				else
					*response_data = NULL;
				return true;
			}
		}
		if (resps && resps->generic) {
			*response_data = &resps->generic->data[0];
			*response_length = resps->generic->len;
			return true;
		}
	}
	return false;
}

#define UDC_NAME_LENGTH_MAX 128

struct usb_raw_init {
	__u8 driver_name[UDC_NAME_LENGTH_MAX];
	__u8 device_name[UDC_NAME_LENGTH_MAX];
	__u8 speed;
};

enum usb_raw_event_type {
	USB_RAW_EVENT_INVALID = 0,
	USB_RAW_EVENT_CONNECT = 1,
	USB_RAW_EVENT_CONTROL = 2,
};

struct usb_raw_event {
	__u32 type;
	__u32 length;
	__u8 data[0];
};

struct usb_raw_ep_io {
	__u16 ep;
	__u16 flags;
	__u32 length;
	__u8 data[0];
};

#define USB_RAW_EPS_NUM_MAX 30
#define USB_RAW_EP_NAME_MAX 16
#define USB_RAW_EP_ADDR_ANY 0xff

struct usb_raw_ep_caps {
	__u32 type_control : 1;
	__u32 type_iso : 1;
	__u32 type_bulk : 1;
	__u32 type_int : 1;
	__u32 dir_in : 1;
	__u32 dir_out : 1;
};

struct usb_raw_ep_limits {
	__u16 maxpacket_limit;
	__u16 max_streams;
	__u32 reserved;
};

struct usb_raw_ep_info {
	__u8 name[USB_RAW_EP_NAME_MAX];
	__u32 addr;
	struct usb_raw_ep_caps caps;
	struct usb_raw_ep_limits limits;
};

struct usb_raw_eps_info {
	struct usb_raw_ep_info eps[USB_RAW_EPS_NUM_MAX];
};

#define USB_RAW_IOCTL_INIT _IOW('U', 0, struct usb_raw_init)
#define USB_RAW_IOCTL_RUN _IO('U', 1)
#define USB_RAW_IOCTL_EVENT_FETCH _IOR('U', 2, struct usb_raw_event)
#define USB_RAW_IOCTL_EP0_WRITE _IOW('U', 3, struct usb_raw_ep_io)
#define USB_RAW_IOCTL_EP0_READ _IOWR('U', 4, struct usb_raw_ep_io)
#define USB_RAW_IOCTL_EP_ENABLE _IOW('U', 5, struct usb_endpoint_descriptor)
#define USB_RAW_IOCTL_EP_DISABLE _IOW('U', 6, __u32)
#define USB_RAW_IOCTL_EP_WRITE _IOW('U', 7, struct usb_raw_ep_io)
#define USB_RAW_IOCTL_EP_READ _IOWR('U', 8, struct usb_raw_ep_io)
#define USB_RAW_IOCTL_CONFIGURE _IO('U', 9)
#define USB_RAW_IOCTL_VBUS_DRAW _IOW('U', 10, __u32)
#define USB_RAW_IOCTL_EPS_INFO _IOR('U', 11, struct usb_raw_eps_info)
#define USB_RAW_IOCTL_EP0_STALL _IO('U', 12)
#define USB_RAW_IOCTL_EP_SET_HALT _IOW('U', 13, __u32)
#define USB_RAW_IOCTL_EP_CLEAR_HALT _IOW('U', 14, __u32)
#define USB_RAW_IOCTL_EP_SET_WEDGE _IOW('U', 15, __u32)

static int usb_raw_open()
{
	return open("/dev/raw-gadget", O_RDWR);
}

static int usb_raw_init(int fd, uint32_t speed, const char* driver, const char* device)
{
	struct usb_raw_init arg;
	strncpy((char*)&arg.driver_name[0], driver, sizeof(arg.driver_name));
	strncpy((char*)&arg.device_name[0], device, sizeof(arg.device_name));
	arg.speed = speed;
	return ioctl(fd, USB_RAW_IOCTL_INIT, &arg);
}

static int usb_raw_run(int fd)
{
	return ioctl(fd, USB_RAW_IOCTL_RUN, 0);
}

static int usb_raw_ep_write(int fd, struct usb_raw_ep_io* io)
{
	return ioctl(fd, USB_RAW_IOCTL_EP_WRITE, io);
}

static int usb_raw_configure(int fd)
{
	return ioctl(fd, USB_RAW_IOCTL_CONFIGURE, 0);
}

static int usb_raw_vbus_draw(int fd, uint32_t power)
{
	return ioctl(fd, USB_RAW_IOCTL_VBUS_DRAW, power);
}

static int usb_raw_ep0_write(int fd, struct usb_raw_ep_io* io)
{
	return ioctl(fd, USB_RAW_IOCTL_EP0_WRITE, io);
}

static int usb_raw_ep0_read(int fd, struct usb_raw_ep_io* io)
{
	return ioctl(fd, USB_RAW_IOCTL_EP0_READ, io);
}

static int usb_raw_event_fetch(int fd, struct usb_raw_event* event)
{
	return ioctl(fd, USB_RAW_IOCTL_EVENT_FETCH, event);
}

static int usb_raw_ep_enable(int fd, struct usb_endpoint_descriptor* desc)
{
	return ioctl(fd, USB_RAW_IOCTL_EP_ENABLE, desc);
}

static int usb_raw_ep_disable(int fd, int ep)
{
	return ioctl(fd, USB_RAW_IOCTL_EP_DISABLE, ep);
}

static int usb_raw_ep0_stall(int fd)
{
	return ioctl(fd, USB_RAW_IOCTL_EP0_STALL, 0);
}

static int lookup_interface(int fd, uint8_t bInterfaceNumber, uint8_t bAlternateSetting)
{
	struct usb_device_index* index = lookup_usb_index(fd);
	if (!index)
		return -1;
	for (int i = 0; i < index->ifaces_num; i++) {
		if (index->ifaces[i].bInterfaceNumber == bInterfaceNumber &&
		    index->ifaces[i].bAlternateSetting == bAlternateSetting)
			return i;
	}
	return -1;
}

static int lookup_endpoint(int fd, uint8_t bEndpointAddress)
{
	struct usb_device_index* index = lookup_usb_index(fd);
	if (!index)
		return -1;
	if (index->iface_cur < 0)
		return -1;
	for (int ep = 0; ep < index->ifaces[index->iface_cur].eps_num; ep++)
		if (index->ifaces[index->iface_cur].eps[ep].desc.bEndpointAddress == bEndpointAddress)
			return index->ifaces[index->iface_cur].eps[ep].handle;
	return -1;
}

#define USB_MAX_PACKET_SIZE 4096

struct usb_raw_control_event {
	struct usb_raw_event inner;
	struct usb_ctrlrequest ctrl;
	char data[USB_MAX_PACKET_SIZE];
};

struct usb_raw_ep_io_data {
	struct usb_raw_ep_io inner;
	char data[USB_MAX_PACKET_SIZE];
};

static void set_interface(int fd, int n)
{
	struct usb_device_index* index = lookup_usb_index(fd);
	if (!index)
		return;
	if (index->iface_cur >= 0 && index->iface_cur < index->ifaces_num) {
		for (int ep = 0; ep < index->ifaces[index->iface_cur].eps_num; ep++) {
			int rv = usb_raw_ep_disable(fd, index->ifaces[index->iface_cur].eps[ep].handle);
			if (rv < 0) {
			} else {
			}
		}
	}
	if (n >= 0 && n < index->ifaces_num) {
		for (int ep = 0; ep < index->ifaces[n].eps_num; ep++) {
			int rv = usb_raw_ep_enable(fd, &index->ifaces[n].eps[ep].desc);
			if (rv < 0) {
			} else {
				index->ifaces[n].eps[ep].handle = rv;
			}
		}
		index->iface_cur = n;
	}
}

static int configure_device(int fd)
{
	struct usb_device_index* index = lookup_usb_index(fd);
	if (!index)
		return -1;
	int rv = usb_raw_vbus_draw(fd, index->bMaxPower);
	if (rv < 0) {
		return rv;
	}
	rv = usb_raw_configure(fd);
	if (rv < 0) {
		return rv;
	}
	set_interface(fd, 0);
	return 0;
}

static volatile long syz_usb_connect_impl(uint64_t speed, uint64_t dev_len, const char* dev,
					  const struct vusb_connect_descriptors* descs,
					  lookup_connect_out_response_t lookup_connect_response_out)
{
	if (!dev) {
		return -1;
	}
	int fd = usb_raw_open();
	if (fd < 0) {
		return fd;
	}
	if (fd >= MAX_FDS) {
		close(fd);
		return -1;
	}
	struct usb_device_index* index = add_usb_index(fd, dev, dev_len);
	if (!index) {
		return -1;
	}
	char device[32];
	sprintf(&device[0], "dummy_udc.%llu", procid);
	int rv = usb_raw_init(fd, speed, "dummy_udc", &device[0]);
	if (rv < 0) {
		return rv;
	}
	rv = usb_raw_run(fd);
	if (rv < 0) {
		return rv;
	}
	bool done = false;
	while (!done) {
		struct usb_raw_control_event event;
		event.inner.type = 0;
		event.inner.length = sizeof(event.ctrl);
		rv = usb_raw_event_fetch(fd, (struct usb_raw_event*)&event);
		if (rv < 0) {
			return rv;
		}
		if (event.inner.type != USB_RAW_EVENT_CONTROL)
			continue;
		char* response_data = NULL;
		uint32_t response_length = 0;
		struct usb_qualifier_descriptor qual;
		if (event.ctrl.bRequestType & USB_DIR_IN) {
			if (!lookup_connect_response_in(fd, descs, &event.ctrl, &qual, &response_data, &response_length)) {
				usb_raw_ep0_stall(fd);
				continue;
			}
		} else {
			if (!lookup_connect_response_out(fd, descs, &event.ctrl, &done)) {
				usb_raw_ep0_stall(fd);
				continue;
			}
			response_data = NULL;
			response_length = event.ctrl.wLength;
		}
		if ((event.ctrl.bRequestType & USB_TYPE_MASK) == USB_TYPE_STANDARD &&
		    event.ctrl.bRequest == USB_REQ_SET_CONFIGURATION) {
			rv = configure_device(fd);
			if (rv < 0) {
				return rv;
			}
		}
		struct usb_raw_ep_io_data response;
		response.inner.ep = 0;
		response.inner.flags = 0;
		if (response_length > sizeof(response.data))
			response_length = 0;
		if (event.ctrl.wLength < response_length)
			response_length = event.ctrl.wLength;
		response.inner.length = response_length;
		if (response_data)
			memcpy(&response.data[0], response_data, response_length);
		else
			memset(&response.data[0], 0, response_length);
		if (event.ctrl.bRequestType & USB_DIR_IN) {
			rv = usb_raw_ep0_write(fd, (struct usb_raw_ep_io*)&response);
		} else {
			rv = usb_raw_ep0_read(fd, (struct usb_raw_ep_io*)&response);
		}
		if (rv < 0) {
			return rv;
		}
	}
	sleep_ms(200);
	return fd;
}

static volatile long syz_usb_connect(volatile long a0, volatile long a1, volatile long a2, volatile long a3)
{
	uint64_t speed = a0;
	uint64_t dev_len = a1;
	const char* dev = (const char*)a2;
	const struct vusb_connect_descriptors* descs = (const struct vusb_connect_descriptors*)a3;
	return syz_usb_connect_impl(speed, dev_len, dev, descs, &lookup_connect_response_out_generic);
}

static volatile long syz_usb_control_io(volatile long a0, volatile long a1, volatile long a2)
{
	int fd = a0;
	const struct vusb_descriptors* descs = (const struct vusb_descriptors*)a1;
	const struct vusb_responses* resps = (const struct vusb_responses*)a2;
	struct usb_raw_control_event event;
	event.inner.type = 0;
	event.inner.length = USB_MAX_PACKET_SIZE;
	int rv = usb_raw_event_fetch(fd, (struct usb_raw_event*)&event);
	if (rv < 0) {
		return rv;
	}
	if (event.inner.type != USB_RAW_EVENT_CONTROL) {
		return -1;
	}
	char* response_data = NULL;
	uint32_t response_length = 0;
	if ((event.ctrl.bRequestType & USB_DIR_IN) && event.ctrl.wLength) {
		if (!lookup_control_response(descs, resps, &event.ctrl, &response_data, &response_length)) {
			usb_raw_ep0_stall(fd);
			return -1;
		}
	} else {
		if ((event.ctrl.bRequestType & USB_TYPE_MASK) == USB_TYPE_STANDARD ||
		    event.ctrl.bRequest == USB_REQ_SET_INTERFACE) {
			int iface_num = event.ctrl.wIndex;
			int alt_set = event.ctrl.wValue;
			int iface_index = lookup_interface(fd, iface_num, alt_set);
			if (iface_index < 0) {
			} else {
				set_interface(fd, iface_index);
			}
		}
		response_length = event.ctrl.wLength;
	}
	struct usb_raw_ep_io_data response;
	response.inner.ep = 0;
	response.inner.flags = 0;
	if (response_length > sizeof(response.data))
		response_length = 0;
	if (event.ctrl.wLength < response_length)
		response_length = event.ctrl.wLength;
	if ((event.ctrl.bRequestType & USB_DIR_IN) && !event.ctrl.wLength) {
		response_length = USB_MAX_PACKET_SIZE;
	}
	response.inner.length = response_length;
	if (response_data)
		memcpy(&response.data[0], response_data, response_length);
	else
		memset(&response.data[0], 0, response_length);
	if ((event.ctrl.bRequestType & USB_DIR_IN) && event.ctrl.wLength) {
		rv = usb_raw_ep0_write(fd, (struct usb_raw_ep_io*)&response);
	} else {
		rv = usb_raw_ep0_read(fd, (struct usb_raw_ep_io*)&response);
	}
	if (rv < 0) {
		return rv;
	}
	sleep_ms(200);
	return 0;
}

static volatile long syz_usb_ep_write(volatile long a0, volatile long a1, volatile long a2, volatile long a3)
{
	int fd = a0;
	uint8_t ep = a1;
	uint32_t len = a2;
	char* data = (char*)a3;
	int ep_handle = lookup_endpoint(fd, ep);
	if (ep_handle < 0) {
		return -1;
	}
	struct usb_raw_ep_io_data io_data;
	io_data.inner.ep = ep_handle;
	io_data.inner.flags = 0;
	if (len > sizeof(io_data.data))
		len = sizeof(io_data.data);
	io_data.inner.length = len;
	memcpy(&io_data.data[0], data, len);
	int rv = usb_raw_ep_write(fd, (struct usb_raw_ep_io*)&io_data);
	if (rv < 0) {
		return rv;
	}
	sleep_ms(200);
	return 0;
}

static volatile long syz_usb_disconnect(volatile long a0)
{
	int fd = a0;
	int rv = close(fd);
	sleep_ms(200);
	return rv;
}

uint64_t r[2] = {0xffffffffffffffff, 0xffffffffffffffff};

int main(void)
{
		syscall(__NR_mmap, /*addr=*/0x1ffffffff000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
	syscall(__NR_mmap, /*addr=*/0x200000000000ul, /*len=*/0x1000000ul, /*prot=PROT_WRITE|PROT_READ|PROT_EXEC*/7ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
	syscall(__NR_mmap, /*addr=*/0x200001000000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
	const char* reason;
	(void)reason;
				intptr_t res = 0;
	if (write(1, "executing program\n", sizeof("executing program\n") - 1)) {}
//  syz_usb_connect$hid arguments: [
//    speed: usb_device_speed = 0x0 (8 bytes)
//    dev_len: len = 0x36 (8 bytes)
//    dev: ptr[inout, array[ANYUNION]] {
//      array[ANYUNION] {
//        union ANYUNION {
//          ANYBLOB: buffer: {12 01 00 00 00 00 00 40 26 09 33 33 40 00 00 00 00 01 09 02 24 00 01 00 00 00 00 09 04 00 00 01 03 01 00 00 09 21 00 00 00 01 22 01 00 09 05 81 03 08} (length 0x32)
//        }
//      }
//    }
//    conn_descs: nil
//  ]
//  returns fd_usb_hid
memcpy((void*)0x200000000000, "... [truncated large byte array] ...", 50);
	res = -1;
res = syz_usb_connect(/*speed=*/0, /*dev_len=*/0x36, /*dev=*/0x200000000000, /*conn_descs=*/0);
	if (res != -1)
		r[0] = res;
//  syz_usb_disconnect arguments: [
//    fd: fd_usb (resource)
//  ]
syz_usb_disconnect(/*fd=*/r[0]);
//  syz_usb_connect$hid arguments: [
//    speed: usb_device_speed = 0x3 (8 bytes)
//    dev_len: len = 0x36 (8 bytes)
//    dev: ptr[in, usb_device_descriptor_hid] {
//      usb_device_descriptor_hid {
//        inner: usb_device_descriptor_verbose_t[flags[usb_versions, int16], 0, 0, 0, flags[usb_device_max_packet_sizes, int8], 0, 0, 64, array[usb_config_descriptor_hid, 1]] {
//          bLength: const = 0x12 (1 bytes)
//          bDescriptorType: const = 0x1 (1 bytes)
//          bcdUSB: usb_versions = 0x0 (2 bytes)
//          bDeviceClass: const = 0x0 (1 bytes)
//          bDeviceSubClass: const = 0x0 (1 bytes)
//          bDeviceProtocol: const = 0x0 (1 bytes)
//          bMaxPacketSize0: usb_device_max_packet_sizes = 0x10 (1 bytes)
//          idVendor: const = 0x4d8 (2 bytes)
//          idProduct: const = 0xdd (2 bytes)
//          bcdDevice: const = 0x0 (2 bytes)
//          iManufacturer: const = 0x0 (1 bytes)
//          iProduct: const = 0x0 (1 bytes)
//          iSerialNumber: const = 0x0 (1 bytes)
//          bNumConfigurations: len = 0x1 (1 bytes)
//          configs: array[usb_config_descriptor_hid] {
//            usb_config_descriptor_hid {
//              inner: usb_config_descriptor_verbose_t[const[1, int8], len[interfaces, int8], int8, flags[usb_config_attributes, int8], int8, void, array[usb_interface_descriptor_hid, 1]] {
//                bLength: const = 0x9 (1 bytes)
//                bDescriptorType: const = 0x2 (1 bytes)
//                wTotalLength: len = 0x24 (2 bytes)
//                bNumInterfaces: len = 0x1 (1 bytes)
//                bConfigurationValue: const = 0x0 (1 bytes)
//                iConfiguration: int8 = 0x0 (1 bytes)
//                bmAttributes: usb_config_attributes = 0x0 (1 bytes)
//                bMaxPower: int8 = 0x0 (1 bytes)
//                extra: buffer: {} (length 0x0)
//                interfaces: array[usb_interface_descriptor_hid] {
//                  usb_interface_descriptor_hid {
//                    inner: usb_interface_descriptor_verbose_t[const[0, int8], int8, int8[1:2], const[USB_CLASS_HID, int8], const[USB_INTERFACE_SUBCLASS_BOOT, int8], flags[usb_hid_protocols, int8], int8, usb_hid_descriptor_hid, usb_endpoint_descriptors_hid] {
//                      bLength: const = 0x9 (1 bytes)
//                      bDescriptorType: const = 0x4 (1 bytes)
//                      bInterfaceNumber: const = 0x0 (1 bytes)
//                      bAlternateSetting: int8 = 0x0 (1 bytes)
//                      bNumEndpoints: int8 = 0x0 (1 bytes)
//                      bInterfaceClass: const = 0x3 (1 bytes)
//                      bInterfaceSubClass: const = 0x1 (1 bytes)
//                      bInterfaceProtocol: usb_hid_protocols = 0x0 (1 bytes)
//                      iInterface: int8 = 0x0 (1 bytes)
//                      extra: usb_hid_descriptor_hid {
//                        bLength: len = 0x0 (1 bytes)
//                        bDescriptorType: const = 0x21 (1 bytes)
//                        bcdHID: int16 = 0x0 (2 bytes)
//                        bCountryCode: int8 = 0x0 (1 bytes)
//                        bNumDescriptors: const = 0x1 (1 bytes)
//                        report_desc: usb_hid_class_descriptor_report {
//                          bDescriptorType: const = 0x22 (1 bytes)
//                          wDescriptorLength: int16 = 0x0 (2 bytes)
//                        }
//                      }
//                      endpoints: usb_endpoint_descriptors_hid {
//                        in: usb_endpoint_descriptor_hid_in {
//                          inner: usb_endpoint_descriptor_verbose_t[const[USB_ENDPOINT_HID_IN_ADDRESS, int8], const[USB_ENDPOINT_HID_ATTRIBUTES, int8], flags[usb_endpoint_max_packet_sizes, int16], int8, int8, int8, void] {
//                            bLength: const = 0x9 (1 bytes)
//                            bDescriptorType: const = 0x5 (1 bytes)
//                            bEndpointAddress: const = 0x81 (1 bytes)
//                            bmAttributes: const = 0x3 (1 bytes)
//                            wMaxPacketSize: usb_endpoint_max_packet_sizes = 0x0 (2 bytes)
//                            bInterval: int8 = 0x0 (1 bytes)
//                            bRefresh: int8 = 0x0 (1 bytes)
//                            bSynchAddress: int8 = 0x0 (1 bytes)
//                            extra: buffer: {} (length 0x0)
//                          }
//                        }
//                        out: array[usb_endpoint_descriptor_hid_out] {
//                        }
//                      }
//                    }
//                  }
//                }
//              }
//            }
//          }
//        }
//      }
//    }
//    conn_descs: nil
//  ]
//  returns fd_usb_hid
*(uint8_t*)0x200000000000 = 0x12;
*(uint8_t*)0x200000000001 = 1;
*(uint16_t*)0x200000000002 = 0;
*(uint8_t*)0x200000000004 = 0;
*(uint8_t*)0x200000000005 = 0;
*(uint8_t*)0x200000000006 = 0;
*(uint8_t*)0x200000000007 = 0x10;
*(uint16_t*)0x200000000008 = 0x4d8;
*(uint16_t*)0x20000000000a = 0xdd;
*(uint16_t*)0x20000000000c = 0;
*(uint8_t*)0x20000000000e = 0;
*(uint8_t*)0x20000000000f = 0;
*(uint8_t*)0x200000000010 = 0;
*(uint8_t*)0x200000000011 = 1;
*(uint8_t*)0x200000000012 = 9;
*(uint8_t*)0x200000000013 = 2;
*(uint16_t*)0x200000000014 = 0x24;
*(uint8_t*)0x200000000016 = 1;
*(uint8_t*)0x200000000017 = 0;
*(uint8_t*)0x200000000018 = 0;
*(uint8_t*)0x200000000019 = 0;
*(uint8_t*)0x20000000001a = 0;
*(uint8_t*)0x20000000001b = 9;
*(uint8_t*)0x20000000001c = 4;
*(uint8_t*)0x20000000001d = 0;
*(uint8_t*)0x20000000001e = 0;
*(uint8_t*)0x20000000001f = 0;
*(uint8_t*)0x200000000020 = 3;
*(uint8_t*)0x200000000021 = 1;
*(uint8_t*)0x200000000022 = 0;
*(uint8_t*)0x200000000023 = 0;
*(uint8_t*)0x200000000024 = 0;
*(uint8_t*)0x200000000025 = 0x21;
*(uint16_t*)0x200000000026 = 0;
*(uint8_t*)0x200000000028 = 0;
*(uint8_t*)0x200000000029 = 1;
*(uint8_t*)0x20000000002a = 0x22;
*(uint16_t*)0x20000000002b = 0;
*(uint8_t*)0x20000000002d = 9;
*(uint8_t*)0x20000000002e = 5;
*(uint8_t*)0x20000000002f = 0x81;
*(uint8_t*)0x200000000030 = 3;
*(uint16_t*)0x200000000031 = 0;
*(uint8_t*)0x200000000033 = 0;
*(uint8_t*)0x200000000034 = 0;
*(uint8_t*)0x200000000035 = 0;
	res = -1;
res = syz_usb_connect(/*speed=USB_SPEED_HIGH*/3, /*dev_len=*/0x36, /*dev=*/0x200000000000, /*conn_descs=*/0);
	if (res != -1)
		r[1] = res;
//  syz_usb_control_io arguments: [
//    fd: fd_usb (resource)
//    descs: nil
//    resps: nil
//  ]
syz_usb_control_io(/*fd=*/r[1], /*descs=*/0, /*resps=*/0);
//  syz_usb_control_io arguments: [
//    fd: fd_usb (resource)
//    descs: ptr[in, vusb_descriptors] {
//      vusb_descriptors {
//        len: len = 0x2c (4 bytes)
//        generic: ptr[inout, array[ANYUNION]] {
//          array[ANYUNION] {
//            union ANYUNION {
//              ANYBLOB: buffer: {00 00 08 00 00 00 08 04 82} (length 0x9)
//            }
//          }
//        }
//        string: nil
//        bos: nil
//        hub_hs: nil
//        hub_ss: nil
//      }
//    }
//    resps: nil
//  ]
*(uint32_t*)0x2000000003c0 = 0x2c;
*(uint64_t*)0x2000000003c4 = 0x200000000100;
memcpy((void*)0x200000000100, "\x00\x00\x08\x00\x00\x00\x08\x04\x82", 9);
*(uint64_t*)0x2000000003cc = 0;
*(uint64_t*)0x2000000003d4 = 0;
*(uint64_t*)0x2000000003dc = 0;
*(uint64_t*)0x2000000003e4 = 0;
syz_usb_control_io(/*fd=*/r[1], /*descs=*/0x2000000003c0, /*resps=*/0);
//  syz_usb_ep_write arguments: [
//    fd: fd_usb (resource)
//    ep: int8 = 0x81 (1 bytes)
//    len: len = 0x1 (8 bytes)
//    data: ptr[in, buffer] {
//      buffer: {50 62 7b} (length 0x3)
//    }
//  ]
memcpy((void*)0x200000000040, "Pb{", 3);
syz_usb_ep_write(/*fd=*/r[0], /*ep=*/0x81, /*len=*/1, /*data=*/0x200000000040);
	return 0;
}
]

map[KernelSrc:/app/workdir/cache/src/d5a02ed91a4f019017141f71e695c75b27c3612e]

map[KernelObj:/app/workdir/cache/build/282afa7582a2ae394864486ef053bbce773fb4fb]

map[OtherCrashReports:[==================================================================
BUG: KASAN: use-after-free in mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
Read of size 1 at addr ffff8881b72fffff by task ktimers/1/29

CPU: 1 UID: 0 PID: 29 Comm: ktimers/1 Not tainted syzkaller #1 PREEMPT_{RT,(full)} 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description+0x55/0x1e0 mm/kasan/report.c:378
 print_report+0x58/0x70 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
 __hid_input_report+0x42b/0x590 drivers/hid/hid-core.c:2161
 hid_irq_in+0x495/0x710 drivers/hid/usbhid/hid-core.c:286
 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657
 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005
 __run_hrtimer kernel/time/hrtimer.c:1930 [inline]
 __hrtimer_run_queues+0x405/0xb10 kernel/time/hrtimer.c:1994
 hrtimer_run_softirq+0x18f/0x260 kernel/time/hrtimer.c:2011
 handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 run_ktimerd+0x69/0x100 kernel/softirq.c:1151
 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1b72ff
flags: 0x500000000000000(node=1|zone=2)
raw: 0500000000000000 dead000000000100 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x440dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_COMP), pid 6037, tgid 6037 (syz-executor), ts 125633981260, free_ts 463441946812
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1858
 prep_new_page mm/page_alloc.c:1866 [inline]
 get_page_from_freelist+0x27c8/0x2840 mm/page_alloc.c:3946
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5226
 alloc_pages_mpol+0xd1/0x380 mm/mempolicy.c:2490
 alloc_frozen_pages_noprof mm/mempolicy.c:2561 [inline]
 alloc_pages_noprof+0xd2/0x2f0 mm/mempolicy.c:2581
 pagetable_alloc_noprof include/linux/mm.h:3651 [inline]
 __pte_alloc_one_noprof include/asm-generic/pgalloc.h:76 [inline]
 pte_alloc_one+0x22/0x380 arch/x86/mm/pgtable.c:18
 __pte_alloc+0x25/0x1a0 mm/memory.c:453
 do_anonymous_page mm/memory.c:5338 [inline]
 do_pte_missing+0x21a2/0x2750 mm/memory.c:4548
 handle_pte_fault mm/memory.c:6411 [inline]
 __handle_mm_fault mm/memory.c:6549 [inline]
 handle_mm_fault+0xd09/0x13c0 mm/memory.c:6718
 do_user_addr_fault+0xa73/0x1340 arch/x86/mm/fault.c:1334
 handle_page_fault arch/x86/mm/fault.c:1474 [inline]
 exc_page_fault+0x6a/0xc0 arch/x86/mm/fault.c:1527
 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
page last free pid 20 tgid 20 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1402 [inline]
 __free_frozen_pages+0xf48/0x1080 mm/page_alloc.c:2943
 __tlb_remove_table_free mm/mmu_gather.c:228 [inline]
 tlb_remove_table_rcu+0x85/0x100 mm/mmu_gather.c:291
 rcu_do_batch kernel/rcu/tree.c:2617 [inline]
 rcu_core kernel/rcu/tree.c:2869 [inline]
 rcu_cpu_kthread+0x99e/0x1470 kernel/rcu/tree.c:2957
 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Memory state around the buggy address:
 ffff8881b72ffe80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff8881b72fff00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff8881b72fff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                                                                ^
 ffff8881b7300000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff8881b7300080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
] ReproducedBugTitle:KASAN: slab-out-of-bounds Read in mcp2221_raw_event ReproducedCrashReport:==================================================================
BUG: KASAN: slab-out-of-bounds in mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
Read of size 1 at addr ffff888111fe7fff by task ktimers/0/16

CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted syzkaller #1 PREEMPT_{RT,(full)} 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description+0x55/0x1e0 mm/kasan/report.c:378
 print_report+0x58/0x70 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
 __hid_input_report+0x42b/0x590 drivers/hid/hid-core.c:2161
 hid_irq_in+0x495/0x710 drivers/hid/usbhid/hid-core.c:286
 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657
 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005
 __run_hrtimer kernel/time/hrtimer.c:1930 [inline]
 __hrtimer_run_queues+0x405/0xb10 kernel/time/hrtimer.c:1994
 hrtimer_run_softirq+0x18f/0x260 kernel/time/hrtimer.c:2011
 handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 run_ktimerd+0x69/0x100 kernel/softirq.c:1151
 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

Allocated by task 2:
 kasan_save_stack mm/kasan/common.c:57 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
 unpoison_slab_object mm/kasan/common.c:340 [inline]
 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
 kasan_slab_alloc include/linux/kasan.h:253 [inline]
 slab_post_alloc_hook mm/slub.c:4569 [inline]
 slab_alloc_node mm/slub.c:4898 [inline]
 kmem_cache_alloc_node_noprof+0x22a/0x6e0 mm/slub.c:4950
 alloc_task_struct_node kernel/fork.c:187 [inline]
 dup_task_struct+0x52/0x840 kernel/fork.c:918
 copy_process+0x89b/0x4450 kernel/fork.c:2090
 kernel_clone+0x283/0x870 kernel/fork.c:2721
 kernel_thread+0x13f/0x1b0 kernel/fork.c:2782
 create_kthread kernel/kthread.c:459 [inline]
 kthreadd+0x4ec/0x6e0 kernel/kthread.c:817
 ret_from_fork+0x514/0xb70 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 ffff888111fe5880
 which belongs to the cache task_struct of size 7296
The buggy address is located 2815 bytes to the right of
 allocated 7296-byte region [ffff888111fe5880, ffff888111fe7500)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x111fe0
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff888116e25541
flags: 0x100000000000040(head|node=0|zone=2)
page_type: f5(slab)
raw: 0100000000000040 ffff8881012e0500 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800040004 00000000f5000000 ffff888116e25541
head: 0100000000000040 ffff8881012e0500 dead000000000100 dead000000000122
head: 0000000000000000 0000000800040004 00000000f5000000 ffff888116e25541
head: 0100000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
head: 0000000000000000 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 2388, tgid 2388 (kworker/u9:11), ts 15402053339, free_ts 0
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1858
 prep_new_page mm/page_alloc.c:1866 [inline]
 get_page_from_freelist+0x27c8/0x2840 mm/page_alloc.c:3946
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5226
 alloc_slab_page mm/slub.c:3278 [inline]
 allocate_slab+0x77/0x660 mm/slub.c:3467
 new_slab mm/slub.c:3525 [inline]
 refill_objects+0x33c/0x3d0 mm/slub.c:7271
 refill_sheaf mm/slub.c:2816 [inline]
 __pcs_replace_empty_main+0x373/0x720 mm/slub.c:4651
 alloc_from_pcs mm/slub.c:4749 [inline]
 slab_alloc_node mm/slub.c:4883 [inline]
 kmem_cache_alloc_node_noprof+0x4f4/0x6e0 mm/slub.c:4950
 alloc_task_struct_node kernel/fork.c:187 [inline]
 dup_task_struct+0x52/0x840 kernel/fork.c:918
 copy_process+0x89b/0x4450 kernel/fork.c:2090
 kernel_clone+0x283/0x870 kernel/fork.c:2721
 user_mode_thread+0x110/0x180 kernel/fork.c:2797
 call_usermodehelper_exec_work+0x5c/0x230 kernel/umh.c:171
 process_one_work kernel/workqueue.c:3314 [inline]
 process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397
 worker_thread+0x8a2/0xda0 kernel/workqueue.c:3478
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
page_owner free stack trace missing

Memory state around the buggy address:
 ffff888111fe7e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff888111fe7f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888111fe7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                ^
 ffff888111fe8000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff888111fe8080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
 ReproducedFaultInjection:]

map[Index:codesearch-index]

gemini-3.1-pro-preview

You are an experienced Linux kernel developer tasked with debugging a kernel crash root cause.
You need to provide a detailed explanation of the root cause for another developer to be
able to write a fix for the bug based on your explanation. Include all relevant details
into the response: function/struct/field/etc names, code snippets, line numbers,
macro/enum values, etc.



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

The crash is:

==================================================================
BUG: KASAN: slab-out-of-bounds in mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
Read of size 1 at addr ffff888111fe7fff by task ktimers/0/16

CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted syzkaller #1 PREEMPT_{RT,(full)} 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description+0x55/0x1e0 mm/kasan/report.c:378
 print_report+0x58/0x70 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
 __hid_input_report+0x42b/0x590 drivers/hid/hid-core.c:2161
 hid_irq_in+0x495/0x710 drivers/hid/usbhid/hid-core.c:286
 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657
 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005
 __run_hrtimer kernel/time/hrtimer.c:1930 [inline]
 __hrtimer_run_queues+0x405/0xb10 kernel/time/hrtimer.c:1994
 hrtimer_run_softirq+0x18f/0x260 kernel/time/hrtimer.c:2011
 handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 run_ktimerd+0x69/0x100 kernel/softirq.c:1151
 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

Allocated by task 2:
 kasan_save_stack mm/kasan/common.c:57 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
 unpoison_slab_object mm/kasan/common.c:340 [inline]
 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
 kasan_slab_alloc include/linux/kasan.h:253 [inline]
 slab_post_alloc_hook mm/slub.c:4569 [inline]
 slab_alloc_node mm/slub.c:4898 [inline]
 kmem_cache_alloc_node_noprof+0x22a/0x6e0 mm/slub.c:4950
 alloc_task_struct_node kernel/fork.c:187 [inline]
 dup_task_struct+0x52/0x840 kernel/fork.c:918
 copy_process+0x89b/0x4450 kernel/fork.c:2090
 kernel_clone+0x283/0x870 kernel/fork.c:2721
 kernel_thread+0x13f/0x1b0 kernel/fork.c:2782
 create_kthread kernel/kthread.c:459 [inline]
 kthreadd+0x4ec/0x6e0 kernel/kthread.c:817
 ret_from_fork+0x514/0xb70 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 ffff888111fe5880
 which belongs to the cache task_struct of size 7296
The buggy address is located 2815 bytes to the right of
 allocated 7296-byte region [ffff888111fe5880, ffff888111fe7500)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x111fe0
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff888116e25541
flags: 0x100000000000040(head|node=0|zone=2)
page_type: f5(slab)
raw: 0100000000000040 ffff8881012e0500 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800040004 00000000f5000000 ffff888116e25541
head: 0100000000000040 ffff8881012e0500 dead000000000100 dead000000000122
head: 0000000000000000 0000000800040004 00000000f5000000 ffff888116e25541
head: 0100000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
head: 0000000000000000 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 2388, tgid 2388 (kworker/u9:11), ts 15402053339, free_ts 0
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1858
 prep_new_page mm/page_alloc.c:1866 [inline]
 get_page_from_freelist+0x27c8/0x2840 mm/page_alloc.c:3946
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5226
 alloc_slab_page mm/slub.c:3278 [inline]
 allocate_slab+0x77/0x660 mm/slub.c:3467
 new_slab mm/slub.c:3525 [inline]
 refill_objects+0x33c/0x3d0 mm/slub.c:7271
 refill_sheaf mm/slub.c:2816 [inline]
 __pcs_replace_empty_main+0x373/0x720 mm/slub.c:4651
 alloc_from_pcs mm/slub.c:4749 [inline]
 slab_alloc_node mm/slub.c:4883 [inline]
 kmem_cache_alloc_node_noprof+0x4f4/0x6e0 mm/slub.c:4950
 alloc_task_struct_node kernel/fork.c:187 [inline]
 dup_task_struct+0x52/0x840 kernel/fork.c:918
 copy_process+0x89b/0x4450 kernel/fork.c:2090
 kernel_clone+0x283/0x870 kernel/fork.c:2721
 user_mode_thread+0x110/0x180 kernel/fork.c:2797
 call_usermodehelper_exec_work+0x5c/0x230 kernel/umh.c:171
 process_one_work kernel/workqueue.c:3314 [inline]
 process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397
 worker_thread+0x8a2/0xda0 kernel/workqueue.c:3478
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
page_owner free stack trace missing

Memory state around the buggy address:
 ffff888111fe7e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff888111fe7f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888111fe7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                ^
 ffff888111fe8000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff888111fe8080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================


The following C code is a draft of the vulnerable syscall sequence. Keep in mind that
it may lack the precise threading, sandboxing, and some arguments of a working reproducer:

// autogenerated by syzkaller (https://github.com/google/syzkaller)

#define _GNU_SOURCE 

#include <endian.h>
#include <errno.h>
#include <fcntl.h>
#include <stdarg.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mount.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <unistd.h>

#include <linux/usb/ch9.h>

static unsigned long long procid;

static void sleep_ms(uint64_t ms)
{
	usleep(ms * 1000);
}

#define MAX_FDS 30

#define USB_MAX_IFACE_NUM 4
#define USB_MAX_EP_NUM 32
#define USB_MAX_FDS 6

struct usb_endpoint_index {
	struct usb_endpoint_descriptor desc;
	int handle;
};

struct usb_iface_index {
	struct usb_interface_descriptor* iface;
	uint8_t bInterfaceNumber;
	uint8_t bAlternateSetting;
	uint8_t bInterfaceClass;
	struct usb_endpoint_index eps[USB_MAX_EP_NUM];
	int eps_num;
};

struct usb_device_index {
	struct usb_device_descriptor* dev;
	struct usb_config_descriptor* config;
	uint8_t bDeviceClass;
	uint8_t bMaxPower;
	int config_length;
	struct usb_iface_index ifaces[USB_MAX_IFACE_NUM];
	int ifaces_num;
	int iface_cur;
};

struct usb_info {
	int fd;
	struct usb_device_index index;
};

static struct usb_info usb_devices[USB_MAX_FDS];

static struct usb_device_index* lookup_usb_index(int fd)
{
	for (int i = 0; i < USB_MAX_FDS; i++) {
		if (__atomic_load_n(&usb_devices[i].fd, __ATOMIC_ACQUIRE) == fd)
			return &usb_devices[i].index;
	}
	return NULL;
}

static int usb_devices_num;

static bool parse_usb_descriptor(const char* buffer, size_t length, struct usb_device_index* index)
{
	if (length < sizeof(*index->dev) + sizeof(*index->config))
		return false;
	memset(index, 0, sizeof(*index));
	index->dev = (struct usb_device_descriptor*)buffer;
	index->config = (struct usb_config_descriptor*)(buffer + sizeof(*index->dev));
	index->bDeviceClass = index->dev->bDeviceClass;
	index->bMaxPower = index->config->bMaxPower;
	index->config_length = length - sizeof(*index->dev);
	index->iface_cur = -1;
	size_t offset = 0;
	while (true) {
		if (offset + 1 >= length)
			break;
		uint8_t desc_length = buffer[offset];
		uint8_t desc_type = buffer[offset + 1];
		if (desc_length <= 2)
			break;
		if (offset + desc_length > length)
			break;
		if (desc_type == USB_DT_INTERFACE && index->ifaces_num < USB_MAX_IFACE_NUM) {
			struct usb_interface_descriptor* iface = (struct usb_interface_descriptor*)(buffer + offset);
			index->ifaces[index->ifaces_num].iface = iface;
			index->ifaces[index->ifaces_num].bInterfaceNumber = iface->bInterfaceNumber;
			index->ifaces[index->ifaces_num].bAlternateSetting = iface->bAlternateSetting;
			index->ifaces[index->ifaces_num].bInterfaceClass = iface->bInterfaceClass;
			index->ifaces_num++;
		}
		if (desc_type == USB_DT_ENDPOINT && index->ifaces_num > 0) {
			struct usb_iface_index* iface = &index->ifaces[index->ifaces_num - 1];
			if (iface->eps_num < USB_MAX_EP_NUM) {
				memcpy(&iface->eps[iface->eps_num].desc, buffer + offset, sizeof(iface->eps[iface->eps_num].desc));
				iface->eps_num++;
			}
		}
		offset += desc_length;
	}
	return true;
}

static struct usb_device_index* add_usb_index(int fd, const char* dev, size_t dev_len)
{
	int i = __atomic_fetch_add(&usb_devices_num, 1, __ATOMIC_RELAXED);
	if (i >= USB_MAX_FDS)
		return NULL;
	if (!parse_usb_descriptor(dev, dev_len, &usb_devices[i].index))
		return NULL;
	__atomic_store_n(&usb_devices[i].fd, fd, __ATOMIC_RELEASE);
	return &usb_devices[i].index;
}

struct vusb_connect_string_descriptor {
	uint32_t len;
	char* str;
} __attribute__((packed));

struct vusb_connect_descriptors {
	uint32_t qual_len;
	char* qual;
	uint32_t bos_len;
	char* bos;
	uint32_t strs_len;
	struct vusb_connect_string_descriptor strs[0];
} __attribute__((packed));

static const char default_string[] = {
    8, USB_DT_STRING,
    's', 0, 'y', 0, 'z', 0
};

static const char default_lang_id[] = {
    4, USB_DT_STRING,
    0x09, 0x04
};

static bool lookup_connect_response_in(int fd, const struct vusb_connect_descriptors* descs,
				       const struct usb_ctrlrequest* ctrl,
				       struct usb_qualifier_descriptor* qual,
				       char** response_data, uint32_t* response_length)
{
	struct usb_device_index* index = lookup_usb_index(fd);
	uint8_t str_idx;
	if (!index)
		return false;
	switch (ctrl->bRequestType & USB_TYPE_MASK) {
	case USB_TYPE_STANDARD:
		switch (ctrl->bRequest) {
		case USB_REQ_GET_DESCRIPTOR:
			switch (ctrl->wValue >> 8) {
			case USB_DT_DEVICE:
				*response_data = (char*)index->dev;
				*response_length = sizeof(*index->dev);
				return true;
			case USB_DT_CONFIG:
				*response_data = (char*)index->config;
				*response_length = index->config_length;
				return true;
			case USB_DT_STRING:
				str_idx = (uint8_t)ctrl->wValue;
				if (descs && str_idx < descs->strs_len) {
					*response_data = descs->strs[str_idx].str;
					*response_length = descs->strs[str_idx].len;
					return true;
				}
				if (str_idx == 0) {
					*response_data = (char*)&default_lang_id[0];
					*response_length = default_lang_id[0];
					return true;
				}
				*response_data = (char*)&default_string[0];
				*response_length = default_string[0];
				return true;
			case USB_DT_BOS:
				*response_data = descs->bos;
				*response_length = descs->bos_len;
				return true;
			case USB_DT_DEVICE_QUALIFIER:
				if (!descs->qual) {
					qual->bLength = sizeof(*qual);
					qual->bDescriptorType = USB_DT_DEVICE_QUALIFIER;
					qual->bcdUSB = index->dev->bcdUSB;
					qual->bDeviceClass = index->dev->bDeviceClass;
					qual->bDeviceSubClass = index->dev->bDeviceSubClass;
					qual->bDeviceProtocol = index->dev->bDeviceProtocol;
					qual->bMaxPacketSize0 = index->dev->bMaxPacketSize0;
					qual->bNumConfigurations = index->dev->bNumConfigurations;
					qual->bRESERVED = 0;
					*response_data = (char*)qual;
					*response_length = sizeof(*qual);
					return true;
				}
				*response_data = descs->qual;
				*response_length = descs->qual_len;
				return true;
			default:
				break;
			}
			break;
		default:
			break;
		}
		break;
	default:
		break;
	}
	return false;
}

typedef bool (*lookup_connect_out_response_t)(int fd, const struct vusb_connect_descriptors* descs,
					      const struct usb_ctrlrequest* ctrl, bool* done);

static bool lookup_connect_response_out_generic(int fd, const struct vusb_connect_descriptors* descs,
						const struct usb_ctrlrequest* ctrl, bool* done)
{
	switch (ctrl->bRequestType & USB_TYPE_MASK) {
	case USB_TYPE_STANDARD:
		switch (ctrl->bRequest) {
		case USB_REQ_SET_CONFIGURATION:
			*done = true;
			return true;
		default:
			break;
		}
		break;
	}
	return false;
}

struct vusb_descriptor {
	uint8_t req_type;
	uint8_t desc_type;
	uint32_t len;
	char data[0];
} __attribute__((packed));

struct vusb_descriptors {
	uint32_t len;
	struct vusb_descriptor* generic;
	struct vusb_descriptor* descs[0];
} __attribute__((packed));

struct vusb_response {
	uint8_t type;
	uint8_t req;
	uint32_t len;
	char data[0];
} __attribute__((packed));

struct vusb_responses {
	uint32_t len;
	struct vusb_response* generic;
	struct vusb_response* resps[0];
} __attribute__((packed));

static bool lookup_control_response(const struct vusb_descriptors* descs, const struct vusb_responses* resps,
				    struct usb_ctrlrequest* ctrl, char** response_data, uint32_t* response_length)
{
	int descs_num = 0;
	int resps_num = 0;
	if (descs)
		descs_num = (descs->len - offsetof(struct vusb_descriptors, descs)) / sizeof(descs->descs[0]);
	if (resps)
		resps_num = (resps->len - offsetof(struct vusb_responses, resps)) / sizeof(resps->resps[0]);
	uint8_t req = ctrl->bRequest;
	uint8_t req_type = ctrl->bRequestType & USB_TYPE_MASK;
	uint8_t desc_type = ctrl->wValue >> 8;
	if (req == USB_REQ_GET_DESCRIPTOR) {
		int i;
		for (i = 0; i < descs_num; i++) {
			struct vusb_descriptor* desc = descs->descs[i];
			if (!desc)
				continue;
			if (desc->req_type == req_type && desc->desc_type == desc_type) {
				*response_length = desc->len;
				if (*response_length != 0)
					*response_data = &desc->data[0];
				else
					*response_data = NULL;
				return true;
			}
		}
		if (descs && descs->generic) {
			*response_data = &descs->generic->data[0];
			*response_length = descs->generic->len;
			return true;
		}
	} else {
		int i;
		for (i = 0; i < resps_num; i++) {
			struct vusb_response* resp = resps->resps[i];
			if (!resp)
				continue;
			if (resp->type == req_type && resp->req == req) {
				*response_length = resp->len;
				if (*response_length != 0)
					*response_data = &resp->data[0];
				else
					*response_data = NULL;
				return true;
			}
		}
		if (resps && resps->generic) {
			*response_data = &resps->generic->data[0];
			*response_length = resps->generic->len;
			return true;
		}
	}
	return false;
}

#define UDC_NAME_LENGTH_MAX 128

struct usb_raw_init {
	__u8 driver_name[UDC_NAME_LENGTH_MAX];
	__u8 device_name[UDC_NAME_LENGTH_MAX];
	__u8 speed;
};

enum usb_raw_event_type {
	USB_RAW_EVENT_INVALID = 0,
	USB_RAW_EVENT_CONNECT = 1,
	USB_RAW_EVENT_CONTROL = 2,
};

struct usb_raw_event {
	__u32 type;
	__u32 length;
	__u8 data[0];
};

struct usb_raw_ep_io {
	__u16 ep;
	__u16 flags;
	__u32 length;
	__u8 data[0];
};

#define USB_RAW_EPS_NUM_MAX 30
#define USB_RAW_EP_NAME_MAX 16
#define USB_RAW_EP_ADDR_ANY 0xff

struct usb_raw_ep_caps {
	__u32 type_control : 1;
	__u32 type_iso : 1;
	__u32 type_bulk : 1;
	__u32 type_int : 1;
	__u32 dir_in : 1;
	__u32 dir_out : 1;
};

struct usb_raw_ep_limits {
	__u16 maxpacket_limit;
	__u16 max_streams;
	__u32 reserved;
};

struct usb_raw_ep_info {
	__u8 name[USB_RAW_EP_NAME_MAX];
	__u32 addr;
	struct usb_raw_ep_caps caps;
	struct usb_raw_ep_limits limits;
};

struct usb_raw_eps_info {
	struct usb_raw_ep_info eps[USB_RAW_EPS_NUM_MAX];
};

#define USB_RAW_IOCTL_INIT _IOW('U', 0, struct usb_raw_init)
#define USB_RAW_IOCTL_RUN _IO('U', 1)
#define USB_RAW_IOCTL_EVENT_FETCH _IOR('U', 2, struct usb_raw_event)
#define USB_RAW_IOCTL_EP0_WRITE _IOW('U', 3, struct usb_raw_ep_io)
#define USB_RAW_IOCTL_EP0_READ _IOWR('U', 4, struct usb_raw_ep_io)
#define USB_RAW_IOCTL_EP_ENABLE _IOW('U', 5, struct usb_endpoint_descriptor)
#define USB_RAW_IOCTL_EP_DISABLE _IOW('U', 6, __u32)
#define USB_RAW_IOCTL_EP_WRITE _IOW('U', 7, struct usb_raw_ep_io)
#define USB_RAW_IOCTL_EP_READ _IOWR('U', 8, struct usb_raw_ep_io)
#define USB_RAW_IOCTL_CONFIGURE _IO('U', 9)
#define USB_RAW_IOCTL_VBUS_DRAW _IOW('U', 10, __u32)
#define USB_RAW_IOCTL_EPS_INFO _IOR('U', 11, struct usb_raw_eps_info)
#define USB_RAW_IOCTL_EP0_STALL _IO('U', 12)
#define USB_RAW_IOCTL_EP_SET_HALT _IOW('U', 13, __u32)
#define USB_RAW_IOCTL_EP_CLEAR_HALT _IOW('U', 14, __u32)
#define USB_RAW_IOCTL_EP_SET_WEDGE _IOW('U', 15, __u32)

static int usb_raw_open()
{
	return open("/dev/raw-gadget", O_RDWR);
}

static int usb_raw_init(int fd, uint32_t speed, const char* driver, const char* device)
{
	struct usb_raw_init arg;
	strncpy((char*)&arg.driver_name[0], driver, sizeof(arg.driver_name));
	strncpy((char*)&arg.device_name[0], device, sizeof(arg.device_name));
	arg.speed = speed;
	return ioctl(fd, USB_RAW_IOCTL_INIT, &arg);
}

static int usb_raw_run(int fd)
{
	return ioctl(fd, USB_RAW_IOCTL_RUN, 0);
}

static int usb_raw_ep_write(int fd, struct usb_raw_ep_io* io)
{
	return ioctl(fd, USB_RAW_IOCTL_EP_WRITE, io);
}

static int usb_raw_configure(int fd)
{
	return ioctl(fd, USB_RAW_IOCTL_CONFIGURE, 0);
}

static int usb_raw_vbus_draw(int fd, uint32_t power)
{
	return ioctl(fd, USB_RAW_IOCTL_VBUS_DRAW, power);
}

static int usb_raw_ep0_write(int fd, struct usb_raw_ep_io* io)
{
	return ioctl(fd, USB_RAW_IOCTL_EP0_WRITE, io);
}

static int usb_raw_ep0_read(int fd, struct usb_raw_ep_io* io)
{
	return ioctl(fd, USB_RAW_IOCTL_EP0_READ, io);
}

static int usb_raw_event_fetch(int fd, struct usb_raw_event* event)
{
	return ioctl(fd, USB_RAW_IOCTL_EVENT_FETCH, event);
}

static int usb_raw_ep_enable(int fd, struct usb_endpoint_descriptor* desc)
{
	return ioctl(fd, USB_RAW_IOCTL_EP_ENABLE, desc);
}

static int usb_raw_ep_disable(int fd, int ep)
{
	return ioctl(fd, USB_RAW_IOCTL_EP_DISABLE, ep);
}

static int usb_raw_ep0_stall(int fd)
{
	return ioctl(fd, USB_RAW_IOCTL_EP0_STALL, 0);
}

static int lookup_interface(int fd, uint8_t bInterfaceNumber, uint8_t bAlternateSetting)
{
	struct usb_device_index* index = lookup_usb_index(fd);
	if (!index)
		return -1;
	for (int i = 0; i < index->ifaces_num; i++) {
		if (index->ifaces[i].bInterfaceNumber == bInterfaceNumber &&
		    index->ifaces[i].bAlternateSetting == bAlternateSetting)
			return i;
	}
	return -1;
}

static int lookup_endpoint(int fd, uint8_t bEndpointAddress)
{
	struct usb_device_index* index = lookup_usb_index(fd);
	if (!index)
		return -1;
	if (index->iface_cur < 0)
		return -1;
	for (int ep = 0; ep < index->ifaces[index->iface_cur].eps_num; ep++)
		if (index->ifaces[index->iface_cur].eps[ep].desc.bEndpointAddress == bEndpointAddress)
			return index->ifaces[index->iface_cur].eps[ep].handle;
	return -1;
}

#define USB_MAX_PACKET_SIZE 4096

struct usb_raw_control_event {
	struct usb_raw_event inner;
	struct usb_ctrlrequest ctrl;
	char data[USB_MAX_PACKET_SIZE];
};

struct usb_raw_ep_io_data {
	struct usb_raw_ep_io inner;
	char data[USB_MAX_PACKET_SIZE];
};

static void set_interface(int fd, int n)
{
	struct usb_device_index* index = lookup_usb_index(fd);
	if (!index)
		return;
	if (index->iface_cur >= 0 && index->iface_cur < index->ifaces_num) {
		for (int ep = 0; ep < index->ifaces[index->iface_cur].eps_num; ep++) {
			int rv = usb_raw_ep_disable(fd, index->ifaces[index->iface_cur].eps[ep].handle);
			if (rv < 0) {
			} else {
			}
		}
	}
	if (n >= 0 && n < index->ifaces_num) {
		for (int ep = 0; ep < index->ifaces[n].eps_num; ep++) {
			int rv = usb_raw_ep_enable(fd, &index->ifaces[n].eps[ep].desc);
			if (rv < 0) {
			} else {
				index->ifaces[n].eps[ep].handle = rv;
			}
		}
		index->iface_cur = n;
	}
}

static int configure_device(int fd)
{
	struct usb_device_index* index = lookup_usb_index(fd);
	if (!index)
		return -1;
	int rv = usb_raw_vbus_draw(fd, index->bMaxPower);
	if (rv < 0) {
		return rv;
	}
	rv = usb_raw_configure(fd);
	if (rv < 0) {
		return rv;
	}
	set_interface(fd, 0);
	return 0;
}

static volatile long syz_usb_connect_impl(uint64_t speed, uint64_t dev_len, const char* dev,
					  const struct vusb_connect_descriptors* descs,
					  lookup_connect_out_response_t lookup_connect_response_out)
{
	if (!dev) {
		return -1;
	}
	int fd = usb_raw_open();
	if (fd < 0) {
		return fd;
	}
	if (fd >= MAX_FDS) {
		close(fd);
		return -1;
	}
	struct usb_device_index* index = add_usb_index(fd, dev, dev_len);
	if (!index) {
		return -1;
	}
	char device[32];
	sprintf(&device[0], "dummy_udc.%llu", procid);
	int rv = usb_raw_init(fd, speed, "dummy_udc", &device[0]);
	if (rv < 0) {
		return rv;
	}
	rv = usb_raw_run(fd);
	if (rv < 0) {
		return rv;
	}
	bool done = false;
	while (!done) {
		struct usb_raw_control_event event;
		event.inner.type = 0;
		event.inner.length = sizeof(event.ctrl);
		rv = usb_raw_event_fetch(fd, (struct usb_raw_event*)&event);
		if (rv < 0) {
			return rv;
		}
		if (event.inner.type != USB_RAW_EVENT_CONTROL)
			continue;
		char* response_data = NULL;
		uint32_t response_length = 0;
		struct usb_qualifier_descriptor qual;
		if (event.ctrl.bRequestType & USB_DIR_IN) {
			if (!lookup_connect_response_in(fd, descs, &event.ctrl, &qual, &response_data, &response_length)) {
				usb_raw_ep0_stall(fd);
				continue;
			}
		} else {
			if (!lookup_connect_response_out(fd, descs, &event.ctrl, &done)) {
				usb_raw_ep0_stall(fd);
				continue;
			}
			response_data = NULL;
			response_length = event.ctrl.wLength;
		}
		if ((event.ctrl.bRequestType & USB_TYPE_MASK) == USB_TYPE_STANDARD &&
		    event.ctrl.bRequest == USB_REQ_SET_CONFIGURATION) {
			rv = configure_device(fd);
			if (rv < 0) {
				return rv;
			}
		}
		struct usb_raw_ep_io_data response;
		response.inner.ep = 0;
		response.inner.flags = 0;
		if (response_length > sizeof(response.data))
			response_length = 0;
		if (event.ctrl.wLength < response_length)
			response_length = event.ctrl.wLength;
		response.inner.length = response_length;
		if (response_data)
			memcpy(&response.data[0], response_data, response_length);
		else
			memset(&response.data[0], 0, response_length);
		if (event.ctrl.bRequestType & USB_DIR_IN) {
			rv = usb_raw_ep0_write(fd, (struct usb_raw_ep_io*)&response);
		} else {
			rv = usb_raw_ep0_read(fd, (struct usb_raw_ep_io*)&response);
		}
		if (rv < 0) {
			return rv;
		}
	}
	sleep_ms(200);
	return fd;
}

static volatile long syz_usb_connect(volatile long a0, volatile long a1, volatile long a2, volatile long a3)
{
	uint64_t speed = a0;
	uint64_t dev_len = a1;
	const char* dev = (const char*)a2;
	const struct vusb_connect_descriptors* descs = (const struct vusb_connect_descriptors*)a3;
	return syz_usb_connect_impl(speed, dev_len, dev, descs, &lookup_connect_response_out_generic);
}

static volatile long syz_usb_control_io(volatile long a0, volatile long a1, volatile long a2)
{
	int fd = a0;
	const struct vusb_descriptors* descs = (const struct vusb_descriptors*)a1;
	const struct vusb_responses* resps = (const struct vusb_responses*)a2;
	struct usb_raw_control_event event;
	event.inner.type = 0;
	event.inner.length = USB_MAX_PACKET_SIZE;
	int rv = usb_raw_event_fetch(fd, (struct usb_raw_event*)&event);
	if (rv < 0) {
		return rv;
	}
	if (event.inner.type != USB_RAW_EVENT_CONTROL) {
		return -1;
	}
	char* response_data = NULL;
	uint32_t response_length = 0;
	if ((event.ctrl.bRequestType & USB_DIR_IN) && event.ctrl.wLength) {
		if (!lookup_control_response(descs, resps, &event.ctrl, &response_data, &response_length)) {
			usb_raw_ep0_stall(fd);
			return -1;
		}
	} else {
		if ((event.ctrl.bRequestType & USB_TYPE_MASK) == USB_TYPE_STANDARD ||
		    event.ctrl.bRequest == USB_REQ_SET_INTERFACE) {
			int iface_num = event.ctrl.wIndex;
			int alt_set = event.ctrl.wValue;
			int iface_index = lookup_interface(fd, iface_num, alt_set);
			if (iface_index < 0) {
			} else {
				set_interface(fd, iface_index);
			}
		}
		response_length = event.ctrl.wLength;
	}
	struct usb_raw_ep_io_data response;
	response.inner.ep = 0;
	response.inner.flags = 0;
	if (response_length > sizeof(response.data))
		response_length = 0;
	if (event.ctrl.wLength < response_length)
		response_length = event.ctrl.wLength;
	if ((event.ctrl.bRequestType & USB_DIR_IN) && !event.ctrl.wLength) {
		response_length = USB_MAX_PACKET_SIZE;
	}
	response.inner.length = response_length;
	if (response_data)
		memcpy(&response.data[0], response_data, response_length);
	else
		memset(&response.data[0], 0, response_length);
	if ((event.ctrl.bRequestType & USB_DIR_IN) && event.ctrl.wLength) {
		rv = usb_raw_ep0_write(fd, (struct usb_raw_ep_io*)&response);
	} else {
		rv = usb_raw_ep0_read(fd, (struct usb_raw_ep_io*)&response);
	}
	if (rv < 0) {
		return rv;
	}
	sleep_ms(200);
	return 0;
}

static volatile long syz_usb_ep_write(volatile long a0, volatile long a1, volatile long a2, volatile long a3)
{
	int fd = a0;
	uint8_t ep = a1;
	uint32_t len = a2;
	char* data = (char*)a3;
	int ep_handle = lookup_endpoint(fd, ep);
	if (ep_handle < 0) {
		return -1;
	}
	struct usb_raw_ep_io_data io_data;
	io_data.inner.ep = ep_handle;
	io_data.inner.flags = 0;
	if (len > sizeof(io_data.data))
		len = sizeof(io_data.data);
	io_data.inner.length = len;
	memcpy(&io_data.data[0], data, len);
	int rv = usb_raw_ep_write(fd, (struct usb_raw_ep_io*)&io_data);
	if (rv < 0) {
		return rv;
	}
	sleep_ms(200);
	return 0;
}

static volatile long syz_usb_disconnect(volatile long a0)
{
	int fd = a0;
	int rv = close(fd);
	sleep_ms(200);
	return rv;
}

uint64_t r[2] = {0xffffffffffffffff, 0xffffffffffffffff};

int main(void)
{
		syscall(__NR_mmap, /*addr=*/0x1ffffffff000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
	syscall(__NR_mmap, /*addr=*/0x200000000000ul, /*len=*/0x1000000ul, /*prot=PROT_WRITE|PROT_READ|PROT_EXEC*/7ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
	syscall(__NR_mmap, /*addr=*/0x200001000000ul, /*len=*/0x1000ul, /*prot=*/0ul, /*flags=MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE*/0x32ul, /*fd=*/(intptr_t)-1, /*offset=*/0ul);
	const char* reason;
	(void)reason;
				intptr_t res = 0;
	if (write(1, "executing program\n", sizeof("executing program\n") - 1)) {}
//  syz_usb_connect$hid arguments: [
//    speed: usb_device_speed = 0x0 (8 bytes)
//    dev_len: len = 0x36 (8 bytes)
//    dev: ptr[inout, array[ANYUNION]] {
//      array[ANYUNION] {
//        union ANYUNION {
//          ANYBLOB: buffer: {12 01 00 00 00 00 00 40 26 09 33 33 40 00 00 00 00 01 09 02 24 00 01 00 00 00 00 09 04 00 00 01 03 01 00 00 09 21 00 00 00 01 22 01 00 09 05 81 03 08} (length 0x32)
//        }
//      }
//    }
//    conn_descs: nil
//  ]
//  returns fd_usb_hid
memcpy((void*)0x200000000000, "... [truncated large byte array] ...", 50);
	res = -1;
res = syz_usb_connect(/*speed=*/0, /*dev_len=*/0x36, /*dev=*/0x200000000000, /*conn_descs=*/0);
	if (res != -1)
		r[0] = res;
//  syz_usb_disconnect arguments: [
//    fd: fd_usb (resource)
//  ]
syz_usb_disconnect(/*fd=*/r[0]);
//  syz_usb_connect$hid arguments: [
//    speed: usb_device_speed = 0x3 (8 bytes)
//    dev_len: len = 0x36 (8 bytes)
//    dev: ptr[in, usb_device_descriptor_hid] {
//      usb_device_descriptor_hid {
//        inner: usb_device_descriptor_verbose_t[flags[usb_versions, int16], 0, 0, 0, flags[usb_device_max_packet_sizes, int8], 0, 0, 64, array[usb_config_descriptor_hid, 1]] {
//          bLength: const = 0x12 (1 bytes)
//          bDescriptorType: const = 0x1 (1 bytes)
//          bcdUSB: usb_versions = 0x0 (2 bytes)
//          bDeviceClass: const = 0x0 (1 bytes)
//          bDeviceSubClass: const = 0x0 (1 bytes)
//          bDeviceProtocol: const = 0x0 (1 bytes)
//          bMaxPacketSize0: usb_device_max_packet_sizes = 0x10 (1 bytes)
//          idVendor: const = 0x4d8 (2 bytes)
//          idProduct: const = 0xdd (2 bytes)
//          bcdDevice: const = 0x0 (2 bytes)
//          iManufacturer: const = 0x0 (1 bytes)
//          iProduct: const = 0x0 (1 bytes)
//          iSerialNumber: const = 0x0 (1 bytes)
//          bNumConfigurations: len = 0x1 (1 bytes)
//          configs: array[usb_config_descriptor_hid] {
//            usb_config_descriptor_hid {
//              inner: usb_config_descriptor_verbose_t[const[1, int8], len[interfaces, int8], int8, flags[usb_config_attributes, int8], int8, void, array[usb_interface_descriptor_hid, 1]] {
//                bLength: const = 0x9 (1 bytes)
//                bDescriptorType: const = 0x2 (1 bytes)
//                wTotalLength: len = 0x24 (2 bytes)
//                bNumInterfaces: len = 0x1 (1 bytes)
//                bConfigurationValue: const = 0x0 (1 bytes)
//                iConfiguration: int8 = 0x0 (1 bytes)
//                bmAttributes: usb_config_attributes = 0x0 (1 bytes)
//                bMaxPower: int8 = 0x0 (1 bytes)
//                extra: buffer: {} (length 0x0)
//                interfaces: array[usb_interface_descriptor_hid] {
//                  usb_interface_descriptor_hid {
//                    inner: usb_interface_descriptor_verbose_t[const[0, int8], int8, int8[1:2], const[USB_CLASS_HID, int8], const[USB_INTERFACE_SUBCLASS_BOOT, int8], flags[usb_hid_protocols, int8], int8, usb_hid_descriptor_hid, usb_endpoint_descriptors_hid] {
//                      bLength: const = 0x9 (1 bytes)
//                      bDescriptorType: const = 0x4 (1 bytes)
//                      bInterfaceNumber: const = 0x0 (1 bytes)
//                      bAlternateSetting: int8 = 0x0 (1 bytes)
//                      bNumEndpoints: int8 = 0x0 (1 bytes)
//                      bInterfaceClass: const = 0x3 (1 bytes)
//                      bInterfaceSubClass: const = 0x1 (1 bytes)
//                      bInterfaceProtocol: usb_hid_protocols = 0x0 (1 bytes)
//                      iInterface: int8 = 0x0 (1 bytes)
//                      extra: usb_hid_descriptor_hid {
//                        bLength: len = 0x0 (1 bytes)
//                        bDescriptorType: const = 0x21 (1 bytes)
//                        bcdHID: int16 = 0x0 (2 bytes)
//                        bCountryCode: int8 = 0x0 (1 bytes)
//                        bNumDescriptors: const = 0x1 (1 bytes)
//                        report_desc: usb_hid_class_descriptor_report {
//                          bDescriptorType: const = 0x22 (1 bytes)
//                          wDescriptorLength: int16 = 0x0 (2 bytes)
//                        }
//                      }
//                      endpoints: usb_endpoint_descriptors_hid {
//                        in: usb_endpoint_descriptor_hid_in {
//                          inner: usb_endpoint_descriptor_verbose_t[const[USB_ENDPOINT_HID_IN_ADDRESS, int8], const[USB_ENDPOINT_HID_ATTRIBUTES, int8], flags[usb_endpoint_max_packet_sizes, int16], int8, int8, int8, void] {
//                            bLength: const = 0x9 (1 bytes)
//                            bDescriptorType: const = 0x5 (1 bytes)
//                            bEndpointAddress: const = 0x81 (1 bytes)
//                            bmAttributes: const = 0x3 (1 bytes)
//                            wMaxPacketSize: usb_endpoint_max_packet_sizes = 0x0 (2 bytes)
//                            bInterval: int8 = 0x0 (1 bytes)
//                            bRefresh: int8 = 0x0 (1 bytes)
//                            bSynchAddress: int8 = 0x0 (1 bytes)
//                            extra: buffer: {} (length 0x0)
//                          }
//                        }
//                        out: array[usb_endpoint_descriptor_hid_out] {
//                        }
//                      }
//                    }
//                  }
//                }
//              }
//            }
//          }
//        }
//      }
//    }
//    conn_descs: nil
//  ]
//  returns fd_usb_hid
*(uint8_t*)0x200000000000 = 0x12;
*(uint8_t*)0x200000000001 = 1;
*(uint16_t*)0x200000000002 = 0;
*(uint8_t*)0x200000000004 = 0;
*(uint8_t*)0x200000000005 = 0;
*(uint8_t*)0x200000000006 = 0;
*(uint8_t*)0x200000000007 = 0x10;
*(uint16_t*)0x200000000008 = 0x4d8;
*(uint16_t*)0x20000000000a = 0xdd;
*(uint16_t*)0x20000000000c = 0;
*(uint8_t*)0x20000000000e = 0;
*(uint8_t*)0x20000000000f = 0;
*(uint8_t*)0x200000000010 = 0;
*(uint8_t*)0x200000000011 = 1;
*(uint8_t*)0x200000000012 = 9;
*(uint8_t*)0x200000000013 = 2;
*(uint16_t*)0x200000000014 = 0x24;
*(uint8_t*)0x200000000016 = 1;
*(uint8_t*)0x200000000017 = 0;
*(uint8_t*)0x200000000018 = 0;
*(uint8_t*)0x200000000019 = 0;
*(uint8_t*)0x20000000001a = 0;
*(uint8_t*)0x20000000001b = 9;
*(uint8_t*)0x20000000001c = 4;
*(uint8_t*)0x20000000001d = 0;
*(uint8_t*)0x20000000001e = 0;
*(uint8_t*)0x20000000001f = 0;
*(uint8_t*)0x200000000020 = 3;
*(uint8_t*)0x200000000021 = 1;
*(uint8_t*)0x200000000022 = 0;
*(uint8_t*)0x200000000023 = 0;
*(uint8_t*)0x200000000024 = 0;
*(uint8_t*)0x200000000025 = 0x21;
*(uint16_t*)0x200000000026 = 0;
*(uint8_t*)0x200000000028 = 0;
*(uint8_t*)0x200000000029 = 1;
*(uint8_t*)0x20000000002a = 0x22;
*(uint16_t*)0x20000000002b = 0;
*(uint8_t*)0x20000000002d = 9;
*(uint8_t*)0x20000000002e = 5;
*(uint8_t*)0x20000000002f = 0x81;
*(uint8_t*)0x200000000030 = 3;
*(uint16_t*)0x200000000031 = 0;
*(uint8_t*)0x200000000033 = 0;
*(uint8_t*)0x200000000034 = 0;
*(uint8_t*)0x200000000035 = 0;
	res = -1;
res = syz_usb_connect(/*speed=USB_SPEED_HIGH*/3, /*dev_len=*/0x36, /*dev=*/0x200000000000, /*conn_descs=*/0);
	if (res != -1)
		r[1] = res;
//  syz_usb_control_io arguments: [
//    fd: fd_usb (resource)
//    descs: nil
//    resps: nil
//  ]
syz_usb_control_io(/*fd=*/r[1], /*descs=*/0, /*resps=*/0);
//  syz_usb_control_io arguments: [
//    fd: fd_usb (resource)
//    descs: ptr[in, vusb_descriptors] {
//      vusb_descriptors {
//        len: len = 0x2c (4 bytes)
//        generic: ptr[inout, array[ANYUNION]] {
//          array[ANYUNION] {
//            union ANYUNION {
//              ANYBLOB: buffer: {00 00 08 00 00 00 08 04 82} (length 0x9)
//            }
//          }
//        }
//        string: nil
//        bos: nil
//        hub_hs: nil
//        hub_ss: nil
//      }
//    }
//    resps: nil
//  ]
*(uint32_t*)0x2000000003c0 = 0x2c;
*(uint64_t*)0x2000000003c4 = 0x200000000100;
memcpy((void*)0x200000000100, "\x00\x00\x08\x00\x00\x00\x08\x04\x82", 9);
*(uint64_t*)0x2000000003cc = 0;
*(uint64_t*)0x2000000003d4 = 0;
*(uint64_t*)0x2000000003dc = 0;
*(uint64_t*)0x2000000003e4 = 0;
syz_usb_control_io(/*fd=*/r[1], /*descs=*/0x2000000003c0, /*resps=*/0);
//  syz_usb_ep_write arguments: [
//    fd: fd_usb (resource)
//    ep: int8 = 0x81 (1 bytes)
//    len: len = 0x1 (8 bytes)
//    data: ptr[in, buffer] {
//      buffer: {50 62 7b} (length 0x3)
//    }
//  ]
memcpy((void*)0x200000000040, "Pb{", 3);
syz_usb_ep_write(/*fd=*/r[0], /*ep=*/0x81, /*len=*/1, /*data=*/0x200000000040);
	return 0;
}

An analysis of the crash report and the source code reveals that the root cause is an **out-of-bounds read due to a negative array index** in `mcp2221_raw_event()`, combined with a lack of bounds checking on the incoming HID report size.

### Detailed Explanation

1. **Uninitialized State**: 
   When the `mcp2221` device is probed, its state structure is allocated using `devm_kzalloc()`, which zero-initializes all fields. The `mcp->gp_idx` field (a `u8`) is initialized to `0`. It is only updated to a valid positive offset (e.g., 3, 7, 11, or 15) when the GPIO subsystem invokes the driver's GPIO operations like `mcp_gpio_set()`.

2. **The Vulnerability**:
   If the device sends an `MCP2221_GPIO_SET` (0x50) input report *before* any GPIO operations are performed (or if a malicious device/reproducer injects one), `mcp2221_raw_event()` processes the report while `mcp->gp_idx` is still `0`.
   
   Looking at `drivers/hid/hid-mcp2221.c` around line 964:
   ```c
   960:		case MCP2221_GPIO_SET:
   961:			switch (data[1]) {
   962:			case MCP2221_SUCCESS:
   963:				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
   964:					(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
   ```
   Because `mcp->gp_idx` is `0`, the expression `mcp->gp_idx - 1` promotes the `u8` to an `int`, resulting in `-1`. This causes the code to access `data[-1]`.

3. **Memory Layout and the KASAN Report**:
   The `data` pointer passed to `mcp2221_raw_event()` points to the URB transfer buffer, which is allocated by the USB core via `kmalloc()` (e.g., from the `kmalloc-64` cache). 
   
   In the crashing scenario, the SLUB allocator placed this 64-byte buffer at the very beginning of a new page, exactly at address `ffff888111fe8000`. 
   
   When the code evaluates `data[-1]`, it reads the address `ffff888111fe7fff`. This address is the last byte of the *previous* physical page. As shown in the KASAN report, the previous page (`pfn:0x111fe0`) was an order-3 slab page belonging to the `task_struct` cache. The last `task_struct` object in that page ended at `ffff888111fe7500`, and the remainder of the page was SLUB padding/redzone (filled with `fc`).
   
   KASAN intercepted the read at `ffff888111fe7fff` and correctly reported it as a slab-out-of-bounds read located 2815 bytes to the right of the `task_struct` object.

   ```text
    ffff888111fe7f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
   >ffff888111fe7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                   ^ (data[-1] at ffff888111fe7fff)
    ffff888111fe8000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  <-- data (urb->transfer_buffer)
   ```

### How to Fix

To fix this bug, `mcp2221_raw_event()` needs two corrections:
1. **Validate `mcp->gp_idx`**: Ensure that `mcp->gp_idx` is valid (e.g., `mcp->gp_idx > 0`) before using it as an array index.
2. **Bounds Checking**: The function completely lacks bounds checking on the `size` parameter. It blindly accesses `data[0]`, `data[1]`, and various other offsets (like `data[50]` in the `MCP2221_I2C_PARAM_OR_STATUS` case). It should verify that `size` is large enough for the specific report being processed before accessing the `data` array.

gemini-3.1-pro-preview

							input: 18290
							output: 24
							thoughts: 220
						

**KASAN Slab-Out-of-Bounds Read in MCP2221 Driver**

Okay, so I'm looking at a KASAN report, specifically a slab-out-of-bounds read within the `mcp2221_raw_event` function. It's happening in `drivers/hid/hid-mcp2221.c` at line 964. The crash itself involves reading a single byte from address `ffff888111fe7fff`.

The stack trace tells the story. The problem originates in `mcp2221_raw_event`, which then calls `__hid_input_report`, and that leads to `hid_irq_in`. So, the data coming from the USB interrupt handler in `hid-core` is likely the trigger. I need to focus on what `mcp2221_raw_event` is doing with the incoming data. Line 964 is the critical area, obviously, so let's examine the code surrounding that line and figure out where the bounds check is failing, or where the offset calculation is wrong. We'll need to figure out what data is being passed in, what it's trying to access, and how the driver is interpreting it. This likely involves understanding the MCP2221's HID report descriptor and how it maps to the driver's internal data structures.

map[Expression:mcp2221_raw_event]

map[Output:drivers/hid/hid-mcp2221.c=820=static int mcp_get_i2c_eng_state(struct mcp2221 *mcp,
--
drivers/hid/hid-mcp2221.c-857- */
drivers/hid/hid-mcp2221.c:858:static int mcp2221_raw_event(struct hid_device *hdev,
drivers/hid/hid-mcp2221.c-859-				struct hid_report *report, u8 *data, int size)
--
drivers/hid/hid-mcp2221.c=1352=static struct hid_driver mcp2221_driver = {
--
drivers/hid/hid-mcp2221.c-1356-	.remove		= mcp2221_remove,
drivers/hid/hid-mcp2221.c:1357:	.raw_event	= mcp2221_raw_event,
drivers/hid/hid-mcp2221.c-1358-};
]

gemini-3.1-pro-preview

							input: 19131
							output: 53
							thoughts: 27
						

Here's a summary of my thought process:

**Diving into the MCP2221 HID Driver**

Okay, let's get down to brass tacks. I need to understand what's happening within the `drivers/hid/hid-mcp2221.c` driver, specifically around line 964. My initial hypothesis is that something interesting is happening related to device interaction or perhaps error handling. Given my experience, I'm expecting to find either a critical function call, a decision point based on device state, or a section of code tied to a specific interrupt or event. The line number acts as a very specific anchor that should allow me to pinpoint a particular function, conditional statement, or important variable assignment within that area of the code. I'm expecting to quickly deduce the purpose of that piece of code once I've got my eyes on it.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp2221_raw_event]

map[SourceCode: 849:	/*
 850:	 * MCP2221 uses interrupt endpoint for input reports. This function
 851:	 * is called by HID layer when it receives i/p report from mcp2221,
 852:	 * which is actually a response to the previously sent command.
 853:	 *
 854:	 * MCP2221A firmware specific return codes are parsed and 0 or
 855:	 * appropriate negative error code is returned. Delayed response
 856:	 * results in timeout error and stray reponses results in -EIO.
 857:	 */
 858:	static int mcp2221_raw_event(struct hid_device *hdev,
 859:					struct hid_report *report, u8 *data, int size)
 860:	{
 861:		u8 *buf;
 862:		struct mcp2221 *mcp = hid_get_drvdata(hdev);
 863:	
 864:		switch (data[0]) {
 865:	
 866:		case MCP2221_I2C_WR_DATA:
 867:		case MCP2221_I2C_WR_NO_STOP:
 868:		case MCP2221_I2C_RD_DATA:
 869:		case MCP2221_I2C_RD_RPT_START:
 870:			switch (data[1]) {
 871:			case MCP2221_SUCCESS:
 872:				mcp->status = 0;
 873:				break;
 874:			default:
 875:				mcp->status = mcp_get_i2c_eng_state(mcp, data, 2);
 876:			}
 877:			complete(&mcp->wait_in_report);
 878:			break;
 879:	
 880:		case MCP2221_I2C_PARAM_OR_STATUS:
 881:			switch (data[1]) {
 882:			case MCP2221_SUCCESS:
 883:				if ((mcp->txbuf[3] == MCP2221_I2C_SET_SPEED) &&
 884:					(data[3] != MCP2221_I2C_SET_SPEED)) {
 885:					mcp->status = -EAGAIN;
 886:					break;
 887:				}
 888:				if (data[20] & MCP2221_I2C_MASK_ADDR_NACK) {
 889:					mcp->status = -ENXIO;
 890:					break;
 891:				}
 892:				mcp->status = mcp_get_i2c_eng_state(mcp, data, 8);
 893:	#if IS_REACHABLE(CONFIG_IIO)
 894:				memcpy(&mcp->adc_values, &data[50], sizeof(mcp->adc_values));
 895:	#endif
 896:				break;
 897:			default:
 898:				mcp->status = -EIO;
 899:			}
 900:			complete(&mcp->wait_in_report);
 901:			break;
 902:	
 903:		case MCP2221_I2C_GET_DATA:
 904:			switch (data[1]) {
 905:			case MCP2221_SUCCESS:
 906:				if (data[2] == MCP2221_I2C_ADDR_NACK) {
 907:					mcp->status = -ENXIO;
 908:					break;
 909:				}
 910:				if (!mcp_get_i2c_eng_state(mcp, data, 2)
 911:					&& (data[3] == 0)) {
 912:					mcp->status = 0;
 913:					break;
 914:				}
 915:				if (data[3] == 127) {
 916:					mcp->status = -EIO;
 917:					break;
 918:				}
 919:				if (data[2] == MCP2221_I2C_READ_COMPL ||
 920:				    data[2] == MCP2221_I2C_READ_PARTIAL) {
 921:					if (!mcp->rxbuf || mcp->rxbuf_idx < 0 || data[3] > 60) {
 922:						mcp->status = -EINVAL;
 923:						break;
 924:					}
 925:					if (mcp->rxbuf_idx + data[3] > mcp->rxbuf_size) {
 926:						mcp->status = -EINVAL;
 927:						break;
 928:					}
 929:					buf = mcp->rxbuf;
 930:					memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
 931:					mcp->rxbuf_idx = mcp->rxbuf_idx + data[3];
 932:					mcp->status = 0;
 933:					break;
 934:				}
 935:				mcp->status = -EIO;
 936:				break;
 937:			default:
 938:				mcp->status = -EIO;
 939:			}
 940:			complete(&mcp->wait_in_report);
 941:			break;
 942:	
 943:		case MCP2221_GPIO_GET:
 944:			switch (data[1]) {
 945:			case MCP2221_SUCCESS:
 946:				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
 947:					(data[mcp->gp_idx + 1] == MCP2221_ALT_F_NOT_GPIOD)) {
 948:					mcp->status = -ENOENT;
 949:				} else {
 950:					mcp->status = !!data[mcp->gp_idx];
 951:					mcp->gpio_dir = data[mcp->gp_idx + 1];
 952:				}
 953:				break;
 954:			default:
 955:				mcp->status = -EAGAIN;
 956:			}
 957:			complete(&mcp->wait_in_report);
 958:			break;
 959:	
 960:		case MCP2221_GPIO_SET:
 961:			switch (data[1]) {
 962:			case MCP2221_SUCCESS:
 963:				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
 964:					(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
 965:					mcp->status = -ENOENT;
 966:				} else {
 967:					mcp->status = 0;
 968:				}
 969:				break;
 970:			default:
 971:				mcp->status = -EAGAIN;
 972:			}
 973:			complete(&mcp->wait_in_report);
 974:			break;
 975:	
 976:		case MCP2221_SET_SRAM_SETTINGS:
 977:			switch (data[1]) {
 978:			case MCP2221_SUCCESS:
 979:				mcp->status = 0;
 980:				break;
 981:			default:
 982:				mcp->status = -EAGAIN;
 983:			}
 984:			complete(&mcp->wait_in_report);
 985:			break;
 986:	
 987:		case MCP2221_GET_SRAM_SETTINGS:
 988:			switch (data[1]) {
 989:			case MCP2221_SUCCESS:
 990:				memcpy(&mcp->mode, &data[22], 4);
 991:	#if IS_REACHABLE(CONFIG_IIO)
 992:				mcp->dac_value = data[6] & GENMASK(4, 0);
 993:	#endif
 994:				mcp->status = 0;
 995:				break;
 996:			default:
 997:				mcp->status = -EAGAIN;
 998:			}
 999:			complete(&mcp->wait_in_report);
1000:			break;
1001:	
1002:		case MCP2221_READ_FLASH_DATA:
1003:			switch (data[1]) {
1004:			case MCP2221_SUCCESS:
1005:				mcp->status = 0;
1006:	
1007:				/* Only handles CHIP SETTINGS subpage currently */
1008:				if (mcp->txbuf[1] != 0) {
1009:					mcp->status = -EIO;
1010:					break;
1011:				}
1012:	
1013:	#if IS_REACHABLE(CONFIG_IIO)
1014:				{
1015:					u8 tmp;
1016:					/* DAC scale value */
1017:					tmp = FIELD_GET(GENMASK(7, 6), data[6]);
1018:					if ((data[6] & BIT(5)) && tmp)
1019:						mcp->dac_scale = tmp + 4;
1020:					else
1021:						mcp->dac_scale = 5;
1022:	
1023:					/* ADC scale value */
1024:					tmp = FIELD_GET(GENMASK(4, 3), data[7]);
1025:					if ((data[7] & BIT(2)) && tmp)
1026:						mcp->adc_scale = tmp - 1;
1027:					else
1028:						mcp->adc_scale = 0;
1029:				}
1030:	#endif
1031:	
1032:				break;
1033:			default:
1034:				mcp->status = -EAGAIN;
1035:			}
1036:			complete(&mcp->wait_in_report);
1037:			break;
1038:	
1039:		default:
1040:			mcp->status = -EIO;
1041:			complete(&mcp->wait_in_report);
1042:		}
1043:	
1044:		return 1;
1045:	}
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 22436
							output: 44
							thoughts: 557
						

**Analyzing a Potential Out-of-Bounds Read in MCP2221 GPIO Handling**

Okay, so I'm looking at this crash report, and it immediately flags a slab-out-of-bounds read, specifically on line 964 within the MCP2221 GPIO handling code. The error reports a read of size 1 at address `ffff888111fe7fff`. That address is apparently 2815 bytes past the end of an allocated 7296-byte region, according to the kernel output, which is associated with a `task_struct`.

Initially, I was thinking `data` was related to the `task_struct`, but this doesn't quite make sense. `data` is a `u8` pointer, and the error report indicates the object at `ffff888111fe5880` belongs to the cache `task_struct`, which is odd. The report says the buggy address `ffff888111fe7fff` is located *2815* bytes to the right of allocated memory region [ffff888111fe5880, ffff888111fe7500].

Now, the math isn't quite adding up. `ffff888111fe7fff` is *not* `ffff888111fe5880 + 2815`, it's actually `ffff888111fe5880 + 10111`. However, I can see that `ffff888111fe7500` *is* the end of the `task_struct`. Hmm, so the crash is happening *far* past the end of the reported `task_struct`. 

I think the crash is in the context of the HID report. I need to trace where the `data` pointer comes from. It's related to HID report data. Okay, let's trace `data` back... in `__hid_input_report`, I can see that `data` is *not* `report->field[0]->value`. It looks like `data` is the raw report data passed to `raw_event`. Okay, I need to check `__hid_input_report` in `drivers/hid/hid-core.c` and figure out how this `data` is passed in and what the expected bounds are to pinpoint this out-of-bounds access.

map[ContextFile:drivers/hid/hid-core.c IncludeLines:true Name:__hid_input_report]

map[SourceCode:2109:	static int __hid_input_report(struct hid_device *hid, enum hid_report_type type,
2110:				      u8 *data, size_t bufsize, u32 size, int interrupt, u64 source,
2111:				      bool from_bpf, bool lock_already_taken)
2112:	{
2113:		struct hid_report_enum *report_enum;
2114:		struct hid_driver *hdrv;
2115:		struct hid_report *report;
2116:		int ret = 0;
2117:	
2118:		if (!hid)
2119:			return -ENODEV;
2120:	
2121:		ret = down_trylock(&hid->driver_input_lock);
2122:		if (lock_already_taken && !ret) {
2123:			up(&hid->driver_input_lock);
2124:			return -EINVAL;
2125:		} else if (!lock_already_taken && ret) {
2126:			return -EBUSY;
2127:		}
2128:	
2129:		if (!hid->driver) {
2130:			ret = -ENODEV;
2131:			goto unlock;
2132:		}
2133:		report_enum = hid->report_enum + type;
2134:		hdrv = hid->driver;
2135:	
2136:		data = dispatch_hid_bpf_device_event(hid, type, data, &bufsize, &size, interrupt,
2137:						     source, from_bpf);
2138:		if (IS_ERR(data)) {
2139:			ret = PTR_ERR(data);
2140:			goto unlock;
2141:		}
2142:	
2143:		if (!size) {
2144:			dbg_hid("empty report\n");
2145:			ret = -1;
2146:			goto unlock;
2147:		}
2148:	
2149:		/* Avoid unnecessary overhead if debugfs is disabled */
2150:		if (!list_empty(&hid->debug_list))
2151:			hid_dump_report(hid, type, data, size);
2152:	
2153:		report = hid_get_report(report_enum, data);
2154:	
2155:		if (!report) {
2156:			ret = -1;
2157:			goto unlock;
2158:		}
2159:	
2160:		if (hdrv && hdrv->raw_event && hid_match_report(hid, report)) {
2161:			ret = hdrv->raw_event(hid, report, data, size);
2162:			if (ret < 0)
2163:				goto unlock;
2164:		}
2165:	
2166:		ret = hid_report_raw_event(hid, type, data, bufsize, size, interrupt);
2167:	
2168:	unlock:
2169:		if (!lock_already_taken)
2170:			up(&hid->driver_input_lock);
2171:		return ret;
2172:	}
 SourceFile:drivers/hid/hid-core.c]

gemini-3.1-pro-preview

							input: 24502
							output: 47
							thoughts: 42
						

Here's my understanding of the situation, given that I'm looking at this from an expert's perspective:

**Deciphering the HID Input Report Flow**

Okay, so I'm looking at the core of the USB HID input handling, specifically within the kernel. Let's break down what's happening. The crucial `data` buffer, that's the payload being passed to the `__hid_input_report` function. It's the raw data, the actual input report from the HID device that needs to be interpreted and presented to the appropriate system components. The context, and from this, likely originates within `hid_irq_in` in `drivers/hid/usbhid/hid-core.c`.

map[ContextFile:drivers/hid/usbhid/hid-core.c IncludeLines:true Name:hid_irq_in]

map[SourceCode: 273:	static void hid_irq_in(struct urb *urb)
 274:	{
 275:		struct hid_device	*hid = urb->context;
 276:		struct usbhid_device	*usbhid = hid->driver_data;
 277:		int			status;
 278:	
 279:		switch (urb->status) {
 280:		case 0:			/* success */
 281:			usbhid->retry_delay = 0;
 282:			if (!test_bit(HID_OPENED, &usbhid->iofl))
 283:				break;
 284:			usbhid_mark_busy(usbhid);
 285:			if (!test_bit(HID_RESUME_RUNNING, &usbhid->iofl)) {
 286:				hid_safe_input_report(urb->context, HID_INPUT_REPORT,
 287:						      urb->transfer_buffer, urb->transfer_buffer_length,
 288:						      urb->actual_length, 1);
 289:				/*
 290:				 * autosuspend refused while keys are pressed
 291:				 * because most keyboards don't wake up when
 292:				 * a key is released
 293:				 */
 294:				if (hid_check_keys_pressed(hid))
 295:					set_bit(HID_KEYS_PRESSED, &usbhid->iofl);
 296:				else
 297:					clear_bit(HID_KEYS_PRESSED, &usbhid->iofl);
 298:			}
 299:			break;
 300:		case -EPIPE:		/* stall */
 301:			usbhid_mark_busy(usbhid);
 302:			clear_bit(HID_IN_RUNNING, &usbhid->iofl);
 303:			set_bit(HID_CLEAR_HALT, &usbhid->iofl);
 304:			schedule_work(&usbhid->reset_work);
 305:			return;
 306:		case -ECONNRESET:	/* unlink */
 307:		case -ENOENT:
 308:		case -ESHUTDOWN:	/* unplug */
 309:			clear_bit(HID_IN_RUNNING, &usbhid->iofl);
 310:			return;
 311:		case -EILSEQ:		/* protocol error or unplug */
 312:		case -EPROTO:		/* protocol error or unplug */
 313:		case -ETIME:		/* protocol error or unplug */
 314:		case -ETIMEDOUT:	/* Should never happen, but... */
 315:			usbhid_mark_busy(usbhid);
 316:			clear_bit(HID_IN_RUNNING, &usbhid->iofl);
 317:			hid_io_error(hid);
 318:			return;
 319:		default:		/* error */
 320:			hid_warn(urb->dev, "input irq status %d received\n",
 321:				 urb->status);
 322:		}
 323:	
 324:		status = usb_submit_urb(urb, GFP_ATOMIC);
 325:		if (status) {
 326:			clear_bit(HID_IN_RUNNING, &usbhid->iofl);
 327:			if (status != -EPERM) {
 328:				hid_err(hid, "can't resubmit intr, %s-%s/input%d, status %d\n",
 329:					hid_to_usb_dev(hid)->bus->bus_name,
 330:					hid_to_usb_dev(hid)->devpath,
 331:					usbhid->ifnum, status);
 332:				hid_io_error(hid);
 333:			}
 334:		}
 335:	}
 SourceFile:drivers/hid/usbhid/hid-core.c]

gemini-3.1-pro-preview

							input: 25824
							output: 28
							thoughts: 234
						

**Debugging a Suspected USB HID Crash**

Okay, so I'm tracking down this crash that seems to be originating within the `mcp2221_raw_event` function. It looks like the issue is related to how the driver handles data from USB input reports. I see that `hid_safe_input_report` calls `__hid_input_report`, and the size passed to that function is `urb->actual_length`. That sounds normal enough.

Now, the crash itself is happening within a `switch` statement that appears to be dealing with GPIO configuration via the MCP2221 controller. Specifically, line 963 and 964 are using `data[mcp->gp_idx]` and `data[mcp->gp_idx - 1]`. The `data` buffer? That's coming directly from `urb->transfer_buffer`.  Aha! `mcp->gp_idx` is the critical piece of this puzzle. It's an index into the `data` buffer, and it looks like a value that isn't being checked could be the root cause. This is a classic buffer overflow scenario if `mcp->gp_idx` is out of bounds.

My next step is clear. I need to find all the places where `mcp->gp_idx` is set to fully understand how it could be set to a bad value. The source code is calling out to other functions that determine the index.

map[Name:mcp2221::gp_idx]

map[References:[map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:mcp2221_raw_event SourceFile:drivers/hid/hid-mcp2221.c SourceLine:946] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:mcp2221_raw_event SourceFile:drivers/hid/hid-mcp2221.c SourceLine:947] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:mcp2221_raw_event SourceFile:drivers/hid/hid-mcp2221.c SourceLine:950] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:mcp2221_raw_event SourceFile:drivers/hid/hid-mcp2221.c SourceLine:951] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:mcp2221_raw_event SourceFile:drivers/hid/hid-mcp2221.c SourceLine:963] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:mcp2221_raw_event SourceFile:drivers/hid/hid-mcp2221.c SourceLine:964] map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_dir_set SourceFile:drivers/hid/hid-mcp2221.c SourceLine:755] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_dir_set SourceFile:drivers/hid/hid-mcp2221.c SourceLine:757] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_dir_set SourceFile:drivers/hid/hid-mcp2221.c SourceLine:758] map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_get SourceFile:drivers/hid/hid-mcp2221.c SourceLine:720] map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_get_direction SourceFile:drivers/hid/hid-mcp2221.c SourceLine:803] map[ReferenceKind:writes ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_set SourceFile:drivers/hid/hid-mcp2221.c SourceLine:737] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_set SourceFile:drivers/hid/hid-mcp2221.c SourceLine:739] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_set SourceFile:drivers/hid/hid-mcp2221.c SourceLine:740]] TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 27249
							output: 49
							thoughts: 40
						

Okay, let's dive into this. Here's how I'd approach that driver investigation:

**Investigating `mcp_gpio_set` and `mcp_gpio_dir_set` in `drivers/hid/hid-mcp2221.c`**

Alright, time to get my hands dirty. I need to understand how the MCP2221 GPIOs are controlled within the Linux kernel, specifically within the `hid-mcp2221` driver. My immediate goal is to understand the functions `mcp_gpio_set` and `mcp_gpio_dir_set`. I'll be digging into the code at `drivers/hid/hid-mcp2221.c` to see how these functions work. I need to quickly grasp how the GPIO lines are configured (input/output) and then how their logical state is subsequently set. I'll be paying close attention to any underlying USB communication calls, packet structures, and error handling related to interacting with the MCP2221 device itself. The goal is a clear understanding of the control flow: From function call to bit level manipulation on the MCP2221.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp_gpio_set]

map[SourceCode: 729:	static int mcp_gpio_set(struct gpio_chip *gc, unsigned int offset, int value)
 730:	{
 731:		struct mcp2221 *mcp = gpiochip_get_data(gc);
 732:		int ret;
 733:	
 734:		memset(mcp->txbuf, 0, 18);
 735:		mcp->txbuf[0] = MCP2221_GPIO_SET;
 736:	
 737:		mcp->gp_idx = offsetof(struct mcp_set_gpio, gpio[offset].value);
 738:	
 739:		mcp->txbuf[mcp->gp_idx - 1] = 1;
 740:		mcp->txbuf[mcp->gp_idx] = !!value;
 741:	
 742:		mutex_lock(&mcp->lock);
 743:		ret = mcp_send_data_req_status(mcp, mcp->txbuf, 18);
 744:		mutex_unlock(&mcp->lock);
 745:	
 746:		return ret;
 747:	}
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 27950
							output: 49
							thoughts: 45
						

Okay, let me think this through.

**Analyzing the `mcp->gp_idx` Calculation**

Hmm, hold on a second. I'm seeing that `mcp->gp_idx` is derived using `offsetof(struct mcp_set_gpio, gpio[offset].value)`. Right, so this suggests we're working with a structure, `struct mcp_set_gpio`, where we're calculating an offset. I need to refresh my memory on that structure. Let me picture it... I need to consider how `gpio[offset].value` is arranged within it. What's the relationship between the `offset`, the structure definition, and the final index? I need to analyze how that offset is being interpreted within the context of the GPIO array. Understanding that should give me insight into the underlying memory layout and, ultimately, what `gp_idx` represents in relation to the GPIO configuration data. Right, let me look at `struct mcp_set_gpio` itself...

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp_set_gpio]

map[SourceCode:  95:	/* MCP GPIO set command layout */
  96:	struct mcp_set_gpio {
  97:		u8 cmd;
  98:		u8 dummy;
  99:		struct {
 100:			u8 change_value;
 101:			u8 value;
 102:			u8 change_direction;
 103:			u8 direction;
 104:		} gpio[MCP_NGPIO];
 105:	} __packed;
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 28421
							output: 53
							thoughts: 463
						

**Analyzing Potential Out-of-Bounds Read in MCP2221 Driver**

Okay, so I'm digging into this `mcp2221_raw_event` function. It seems like `MCP_NGPIO` is likely equal to 4, which is a common assumption. Now, thinking about the structure layout, `offsetof(struct mcp_set_gpio, gpio[offset].value)` calculates the offset. That should equate to `2 + offset * 4 + 1`. This means when the `offset` is 0, we're looking at an index of 3 in the `gp_idx` array. With an `offset` of 1, `gp_idx` becomes 7. Continuing, an offset of 2 implies an `gp_idx` of 11, and with an offset of 3 it's 15.

Now, looking at the code snippet in `mcp2221_raw_event` with `MCP2221_GPIO_SET`, I see a potentially vulnerable area. The code is checking `data[mcp->gp_idx]` based on some success code. Wait, `data` is the input report. And the critical point is: how big is that input report? The report size is determined by the HID descriptor, which is crucial.

Aha! In that syzkaller reproducer, the IN endpoint's `wMaxPacketSize` is reported as 0. This is a potential red flag. Zero packet size in an IN endpoint? That doesn't make sense! However, `size` passed to `mcp2221_raw_event` is `urb->actual_length`. That variable holds what actually arrived. If `urb->actual_length` is small (e.g., just 1 byte), accessing `data[mcp->gp_idx]` could trigger an out-of-bounds read. This is definitely something I need to check. I need to see if `mcp2221_raw_event` actually checks `size` before accessing the `data` array. A missing size check here could lead to a serious vulnerability. Let's see if there's any validation, or if it is just assuming that the `actual_length` will always be big enough.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp2221_raw_event]

map[SourceCode: 849:	/*
 850:	 * MCP2221 uses interrupt endpoint for input reports. This function
 851:	 * is called by HID layer when it receives i/p report from mcp2221,
 852:	 * which is actually a response to the previously sent command.
 853:	 *
 854:	 * MCP2221A firmware specific return codes are parsed and 0 or
 855:	 * appropriate negative error code is returned. Delayed response
 856:	 * results in timeout error and stray reponses results in -EIO.
 857:	 */
 858:	static int mcp2221_raw_event(struct hid_device *hdev,
 859:					struct hid_report *report, u8 *data, int size)
 860:	{
 861:		u8 *buf;
 862:		struct mcp2221 *mcp = hid_get_drvdata(hdev);
 863:	
 864:		switch (data[0]) {
 865:	
 866:		case MCP2221_I2C_WR_DATA:
 867:		case MCP2221_I2C_WR_NO_STOP:
 868:		case MCP2221_I2C_RD_DATA:
 869:		case MCP2221_I2C_RD_RPT_START:
 870:			switch (data[1]) {
 871:			case MCP2221_SUCCESS:
 872:				mcp->status = 0;
 873:				break;
 874:			default:
 875:				mcp->status = mcp_get_i2c_eng_state(mcp, data, 2);
 876:			}
 877:			complete(&mcp->wait_in_report);
 878:			break;
 879:	
 880:		case MCP2221_I2C_PARAM_OR_STATUS:
 881:			switch (data[1]) {
 882:			case MCP2221_SUCCESS:
 883:				if ((mcp->txbuf[3] == MCP2221_I2C_SET_SPEED) &&
 884:					(data[3] != MCP2221_I2C_SET_SPEED)) {
 885:					mcp->status = -EAGAIN;
 886:					break;
 887:				}
 888:				if (data[20] & MCP2221_I2C_MASK_ADDR_NACK) {
 889:					mcp->status = -ENXIO;
 890:					break;
 891:				}
 892:				mcp->status = mcp_get_i2c_eng_state(mcp, data, 8);
 893:	#if IS_REACHABLE(CONFIG_IIO)
 894:				memcpy(&mcp->adc_values, &data[50], sizeof(mcp->adc_values));
 895:	#endif
 896:				break;
 897:			default:
 898:				mcp->status = -EIO;
 899:			}
 900:			complete(&mcp->wait_in_report);
 901:			break;
 902:	
 903:		case MCP2221_I2C_GET_DATA:
 904:			switch (data[1]) {
 905:			case MCP2221_SUCCESS:
 906:				if (data[2] == MCP2221_I2C_ADDR_NACK) {
 907:					mcp->status = -ENXIO;
 908:					break;
 909:				}
 910:				if (!mcp_get_i2c_eng_state(mcp, data, 2)
 911:					&& (data[3] == 0)) {
 912:					mcp->status = 0;
 913:					break;
 914:				}
 915:				if (data[3] == 127) {
 916:					mcp->status = -EIO;
 917:					break;
 918:				}
 919:				if (data[2] == MCP2221_I2C_READ_COMPL ||
 920:				    data[2] == MCP2221_I2C_READ_PARTIAL) {
 921:					if (!mcp->rxbuf || mcp->rxbuf_idx < 0 || data[3] > 60) {
 922:						mcp->status = -EINVAL;
 923:						break;
 924:					}
 925:					if (mcp->rxbuf_idx + data[3] > mcp->rxbuf_size) {
 926:						mcp->status = -EINVAL;
 927:						break;
 928:					}
 929:					buf = mcp->rxbuf;
 930:					memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
 931:					mcp->rxbuf_idx = mcp->rxbuf_idx + data[3];
 932:					mcp->status = 0;
 933:					break;
 934:				}
 935:				mcp->status = -EIO;
 936:				break;
 937:			default:
 938:				mcp->status = -EIO;
 939:			}
 940:			complete(&mcp->wait_in_report);
 941:			break;
 942:	
 943:		case MCP2221_GPIO_GET:
 944:			switch (data[1]) {
 945:			case MCP2221_SUCCESS:
 946:				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
 947:					(data[mcp->gp_idx + 1] == MCP2221_ALT_F_NOT_GPIOD)) {
 948:					mcp->status = -ENOENT;
 949:				} else {
 950:					mcp->status = !!data[mcp->gp_idx];
 951:					mcp->gpio_dir = data[mcp->gp_idx + 1];
 952:				}
 953:				break;
 954:			default:
 955:				mcp->status = -EAGAIN;
 956:			}
 957:			complete(&mcp->wait_in_report);
 958:			break;
 959:	
 960:		case MCP2221_GPIO_SET:
 961:			switch (data[1]) {
 962:			case MCP2221_SUCCESS:
 963:				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
 964:					(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
 965:					mcp->status = -ENOENT;
 966:				} else {
 967:					mcp->status = 0;
 968:				}
 969:				break;
 970:			default:
 971:				mcp->status = -EAGAIN;
 972:			}
 973:			complete(&mcp->wait_in_report);
 974:			break;
 975:	
 976:		case MCP2221_SET_SRAM_SETTINGS:
 977:			switch (data[1]) {
 978:			case MCP2221_SUCCESS:
 979:				mcp->status = 0;
 980:				break;
 981:			default:
 982:				mcp->status = -EAGAIN;
 983:			}
 984:			complete(&mcp->wait_in_report);
 985:			break;
 986:	
 987:		case MCP2221_GET_SRAM_SETTINGS:
 988:			switch (data[1]) {
 989:			case MCP2221_SUCCESS:
 990:				memcpy(&mcp->mode, &data[22], 4);
 991:	#if IS_REACHABLE(CONFIG_IIO)
 992:				mcp->dac_value = data[6] & GENMASK(4, 0);
 993:	#endif
 994:				mcp->status = 0;
 995:				break;
 996:			default:
 997:				mcp->status = -EAGAIN;
 998:			}
 999:			complete(&mcp->wait_in_report);
1000:			break;
1001:	
1002:		case MCP2221_READ_FLASH_DATA:
1003:			switch (data[1]) {
1004:			case MCP2221_SUCCESS:
1005:				mcp->status = 0;
1006:	
1007:				/* Only handles CHIP SETTINGS subpage currently */
1008:				if (mcp->txbuf[1] != 0) {
1009:					mcp->status = -EIO;
1010:					break;
1011:				}
1012:	
1013:	#if IS_REACHABLE(CONFIG_IIO)
1014:				{
1015:					u8 tmp;
1016:					/* DAC scale value */
1017:					tmp = FIELD_GET(GENMASK(7, 6), data[6]);
1018:					if ((data[6] & BIT(5)) && tmp)
1019:						mcp->dac_scale = tmp + 4;
1020:					else
1021:						mcp->dac_scale = 5;
1022:	
1023:					/* ADC scale value */
1024:					tmp = FIELD_GET(GENMASK(4, 3), data[7]);
1025:					if ((data[7] & BIT(2)) && tmp)
1026:						mcp->adc_scale = tmp - 1;
1027:					else
1028:						mcp->adc_scale = 0;
1029:				}
1030:	#endif
1031:	
1032:				break;
1033:			default:
1034:				mcp->status = -EAGAIN;
1035:			}
1036:			complete(&mcp->wait_in_report);
1037:			break;
1038:	
1039:		default:
1040:			mcp->status = -EIO;
1041:			complete(&mcp->wait_in_report);
1042:		}
1043:	
1044:		return 1;
1045:	}
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 32469
							output: 46
							thoughts: 132
						

**Concerning Potential Buffer Overflows in MCP2221 Driver**

Okay, so I'm looking at this `mcp2221_raw_event` function, and my initial concern is immediately jumping out at me. I'm seeing no boundary check for the `size` parameter. It just blithely accesses `data[0]`, `data[1]`, and even `data[mcp->gp_idx]`. Clearly, if the reported `size` is smaller than any of those accessed indices, we've got a classic out-of-bounds read vulnerability staring us in the face. This is precisely the kind of thing that leads to security holes.

Right, so `data` is tied to `urb->transfer_buffer`. Okay. Now, where is `urb->transfer_buffer` allocated and sized? This means I need to go trace its origin. It looks like `hid_alloc_buffers` is the likely candidate. I'll need to check the allocation and sizing logic within that function, located in `drivers/hid/usbhid/hid-core.c`, to see if the allocation size is properly handled. I need to understand how the allocation size interacts with the `size` parameter in the `mcp2221_raw_event` function. This is a critical point that needs a thorough investigation to ensure no unexpected behaviors are possible.

map[ContextFile:drivers/hid/usbhid/hid-core.c IncludeLines:true Name:hid_alloc_buffers]

map[SourceCode: 854:	static int hid_alloc_buffers(struct usb_device *dev, struct hid_device *hid)
 855:	{
 856:		struct usbhid_device *usbhid = hid->driver_data;
 857:	
 858:		usbhid->inbuf = usb_alloc_coherent(dev, usbhid->bufsize, GFP_KERNEL,
 859:				&usbhid->inbuf_dma);
 860:		usbhid->outbuf = usb_alloc_coherent(dev, usbhid->bufsize, GFP_KERNEL,
 861:				&usbhid->outbuf_dma);
 862:		usbhid->cr = kmalloc_obj(*usbhid->cr);
 863:		usbhid->ctrlbuf = usb_alloc_coherent(dev, usbhid->bufsize, GFP_KERNEL,
 864:				&usbhid->ctrlbuf_dma);
 865:		if (!usbhid->inbuf || !usbhid->outbuf || !usbhid->cr ||
 866:				!usbhid->ctrlbuf)
 867:			return -1;
 868:	
 869:		return 0;
 870:	}
 SourceFile:drivers/hid/usbhid/hid-core.c]

gemini-3.1-pro-preview

							input: 33286
							output: 45
							thoughts: 16
						

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

**My Internal USB HID Buffer Calculation**

Alright, so the `usbhid->bufsize`, that's the buffer size for USB HID (Human Interface Device) transfers, and I remember that's calculated during the `usbhid_start` function. That's the setup stage, right? Before any actual data transfer can happen, I need to figure out how much memory to allocate for the buffer. It's not a static value; the size depends on some factors. I have to think, what parameters are involved in determining the initial `bufsize`? Is it driven by the HID descriptor, perhaps? Or is there some negotiation involved during device enumeration that affects it? I should re-examine the `usbhid_start` code path in more detail. I need to make sure I understand the logic that results in that calculation to see if there's an opportunity to optimize things based on known device characteristics or potential traffic patterns. Gotta review how the endpoint descriptors and HID reports impact the allocation.

map[ContextFile:drivers/hid/usbhid/hid-core.c IncludeLines:true Name:usbhid_start]

map[SourceCode:1081:	static int usbhid_start(struct hid_device *hid)
1082:	{
1083:		struct usb_interface *intf = to_usb_interface(hid->dev.parent);
1084:		struct usb_host_interface *interface = intf->cur_altsetting;
1085:		struct usb_device *dev = interface_to_usbdev(intf);
1086:		struct usbhid_device *usbhid = hid->driver_data;
1087:		unsigned int n, insize = 0;
1088:		int ret;
1089:	
1090:		mutex_lock(&usbhid->mutex);
1091:	
1092:		clear_bit(HID_DISCONNECTED, &usbhid->iofl);
1093:	
1094:		usbhid->bufsize = HID_MIN_BUFFER_SIZE;
1095:		hid_find_max_report(hid, HID_INPUT_REPORT, &usbhid->bufsize);
1096:		hid_find_max_report(hid, HID_OUTPUT_REPORT, &usbhid->bufsize);
1097:		hid_find_max_report(hid, HID_FEATURE_REPORT, &usbhid->bufsize);
1098:	
1099:		if (usbhid->bufsize > HID_MAX_BUFFER_SIZE)
1100:			usbhid->bufsize = HID_MAX_BUFFER_SIZE;
1101:	
1102:		hid_find_max_report(hid, HID_INPUT_REPORT, &insize);
1103:	
1104:		if (insize > HID_MAX_BUFFER_SIZE)
1105:			insize = HID_MAX_BUFFER_SIZE;
1106:	
1107:		if (hid_alloc_buffers(dev, hid)) {
1108:			ret = -ENOMEM;
1109:			goto fail;
1110:		}
1111:	
1112:		for (n = 0; n < interface->desc.bNumEndpoints; n++) {
1113:			struct usb_endpoint_descriptor *endpoint;
1114:			int pipe;
1115:			int interval;
1116:	
1117:			endpoint = &interface->endpoint[n].desc;
1118:			if (!usb_endpoint_xfer_int(endpoint))
1119:				continue;
1120:	
1121:			interval = endpoint->bInterval;
1122:	
1123:			/* Some vendors give fullspeed interval on highspeed devices */
1124:			if (hid->quirks & HID_QUIRK_FULLSPEED_INTERVAL &&
1125:			    dev->speed == USB_SPEED_HIGH) {
1126:				interval = fls(endpoint->bInterval*8);
1127:				pr_info("%s: Fixing fullspeed to highspeed interval: %d -> %d\n",
1128:					hid->name, endpoint->bInterval, interval);
1129:			}
1130:	
1131:			/* Change the polling interval of mice, joysticks
1132:			 * and keyboards.
1133:			 */
1134:			switch (hid->collection->usage) {
1135:			case HID_GD_MOUSE:
1136:				if (hid_mousepoll_interval > 0)
1137:					interval = hid_mousepoll_interval;
1138:				break;
1139:			case HID_GD_JOYSTICK:
1140:				if (hid_jspoll_interval > 0)
1141:					interval = hid_jspoll_interval;
1142:				break;
1143:			case HID_GD_KEYBOARD:
1144:				if (hid_kbpoll_interval > 0)
1145:					interval = hid_kbpoll_interval;
1146:				break;
1147:			}
1148:	
1149:			ret = -ENOMEM;
1150:			if (usb_endpoint_dir_in(endpoint)) {
1151:				if (usbhid->urbin)
1152:					continue;
1153:				if (!(usbhid->urbin = usb_alloc_urb(0, GFP_KERNEL)))
1154:					goto fail;
1155:				pipe = usb_rcvintpipe(dev, endpoint->bEndpointAddress);
1156:				usb_fill_int_urb(usbhid->urbin, dev, pipe, usbhid->inbuf, insize,
1157:						 hid_irq_in, hid, interval);
1158:				usbhid->urbin->transfer_dma = usbhid->inbuf_dma;
1159:				usbhid->urbin->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
1160:			} else {
1161:				if (usbhid->urbout)
1162:					continue;
1163:				if (!(usbhid->urbout = usb_alloc_urb(0, GFP_KERNEL)))
1164:					goto fail;
1165:				pipe = usb_sndintpipe(dev, endpoint->bEndpointAddress);
1166:				usb_fill_int_urb(usbhid->urbout, dev, pipe, usbhid->outbuf, 0,
1167:						 hid_irq_out, hid, interval);
1168:				usbhid->urbout->transfer_dma = usbhid->outbuf_dma;
1169:				usbhid->urbout->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
1170:			}
1171:		}
1172:	
1173:		usbhid->urbctrl = usb_alloc_urb(0, GFP_KERNEL);
1174:		if (!usbhid->urbctrl) {
1175:			ret = -ENOMEM;
1176:			goto fail;
1177:		}
1178:	
1179:		usb_fill_control_urb(usbhid->urbctrl, dev, 0, (void *) usbhid->cr,
1180:				     usbhid->ctrlbuf, 1, hid_ctrl, hid);
1181:		usbhid->urbctrl->transfer_dma = usbhid->ctrlbuf_dma;
1182:		usbhid->urbctrl->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
1183:	
1184:		set_bit(HID_STARTED, &usbhid->iofl);
1185:	
1186:		if (hid->quirks & HID_QUIRK_ALWAYS_POLL) {
1187:			ret = usb_autopm_get_interface(usbhid->intf);
1188:			if (ret)
1189:				goto fail;
1190:			set_bit(HID_IN_POLLING, &usbhid->iofl);
1191:			usbhid->intf->needs_remote_wakeup = 1;
1192:			ret = hid_start_in(hid);
1193:			if (ret) {
1194:				dev_err(&hid->dev,
1195:					"failed to start in urb: %d\n", ret);
1196:			}
1197:			usb_autopm_put_interface(usbhid->intf);
1198:		}
1199:	
1200:		/* Some keyboards don't work until their LEDs have been set.
1201:		 * Since BIOSes do set the LEDs, it must be safe for any device
1202:		 * that supports the keyboard boot protocol.
1203:		 * In addition, enable remote wakeup by default for all keyboard
1204:		 * devices supporting the boot protocol.
1205:		 */
1206:		if (interface->desc.bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT &&
1207:				interface->desc.bInterfaceProtocol ==
1208:					USB_INTERFACE_PROTOCOL_KEYBOARD) {
1209:			usbhid_set_leds(hid);
1210:			device_set_wakeup_enable(&dev->dev, 1);
1211:		}
1212:	
1213:		mutex_unlock(&usbhid->mutex);
1214:		return 0;
1215:	
1216:	fail:
1217:		usb_free_urb(usbhid->urbin);
1218:		usb_free_urb(usbhid->urbout);
1219:		usb_free_urb(usbhid->urbctrl);
1220:		usbhid->urbin = NULL;
1221:		usbhid->urbout = NULL;
1222:		usbhid->urbctrl = NULL;
1223:		hid_free_buffers(dev, hid);
1224:		mutex_unlock(&usbhid->mutex);
1225:		return ret;
1226:	}
 SourceFile:drivers/hid/usbhid/hid-core.c]

gemini-3.1-pro-preview

							input: 35978
							output: 44
							thoughts: 604
						

**Analyzing the USB HID Buffer Overflow**

Okay, let's break this down. My initial thought process is following the flow of the USB HID buffer allocation and use, specifically related to the `mcp2221_raw_event` function. First, the size of the buffer, `usbhid->bufsize`, is determined by `hid_find_max_report`. Then, `insize` is also calculated via this function, using `HID_INPUT_REPORT`. Hmm, a bit redundant, isn't it?

The key here, as pointed out, is that an empty or very small report descriptor, which is what we have in the syzkaller reproducer, means `insize` could be zero or minuscule. The `usb_alloc_coherent` then uses this `usbhid->bufsize` to allocate memory, and if that's small, `usbhid->inbuf` will be small. The syzkaller reproducer gives us:

```c
//                        report_desc: usb_hid_class_descriptor_report {
//                          bDescriptorType: const = 0x22 (1 bytes)
//                          wDescriptorLength: int16 = 0x0 (2 bytes)
//                        }
```

The crucial thing here is that the report descriptor length is 0! `hid_find_max_report` is going to return 0, which means `usbhid->bufsize` will default to `HID_MIN_BUFFER_SIZE`, which is 64.  So, we end up with a 64-byte `usbhid->inbuf`.

Now, the problem arises in `mcp2221_raw_event`, where `data[mcp->gp_idx]` is accessed.  `mcp->gp_idx` is calculated using `offsetof(struct mcp_set_gpio, gpio[offset].value)`. For `offset = 3`, `gp_idx` is 15. That is less than 64. So there should not be a buffer overflow, right?

But, the crash report is saying something entirely different. It points to a crash within a `task_struct`.

Specifically, the crash report states:
"The buggy address belongs to the object at ffff888111fe5880 which belongs to the cache task_struct of size 7296"
"The buggy address is located 2815 bytes to the right of allocated 7296-byte region [ffff888111fe5880, ffff888111fe7500)"
The buggy address `ffff888111fe7fff`.  Calculating the offset from the base address, we have `ffff888111fe7fff` - `ffff888111fe5880` = 10111. The crash is within a `task_struct`, which is allocated from the `task_struct` cache. 

So the core problem: Why is `data` pointing to the `task_struct` instead of the allocated HID buffer? We need to go back and carefully re-examine `__hid_input_report`. There must be a memory corruption happening.

map[ContextFile:drivers/hid/hid-core.c IncludeLines:true Name:__hid_input_report]

map[SourceCode:2109:	static int __hid_input_report(struct hid_device *hid, enum hid_report_type type,
2110:				      u8 *data, size_t bufsize, u32 size, int interrupt, u64 source,
2111:				      bool from_bpf, bool lock_already_taken)
2112:	{
2113:		struct hid_report_enum *report_enum;
2114:		struct hid_driver *hdrv;
2115:		struct hid_report *report;
2116:		int ret = 0;
2117:	
2118:		if (!hid)
2119:			return -ENODEV;
2120:	
2121:		ret = down_trylock(&hid->driver_input_lock);
2122:		if (lock_already_taken && !ret) {
2123:			up(&hid->driver_input_lock);
2124:			return -EINVAL;
2125:		} else if (!lock_already_taken && ret) {
2126:			return -EBUSY;
2127:		}
2128:	
2129:		if (!hid->driver) {
2130:			ret = -ENODEV;
2131:			goto unlock;
2132:		}
2133:		report_enum = hid->report_enum + type;
2134:		hdrv = hid->driver;
2135:	
2136:		data = dispatch_hid_bpf_device_event(hid, type, data, &bufsize, &size, interrupt,
2137:						     source, from_bpf);
2138:		if (IS_ERR(data)) {
2139:			ret = PTR_ERR(data);
2140:			goto unlock;
2141:		}
2142:	
2143:		if (!size) {
2144:			dbg_hid("empty report\n");
2145:			ret = -1;
2146:			goto unlock;
2147:		}
2148:	
2149:		/* Avoid unnecessary overhead if debugfs is disabled */
2150:		if (!list_empty(&hid->debug_list))
2151:			hid_dump_report(hid, type, data, size);
2152:	
2153:		report = hid_get_report(report_enum, data);
2154:	
2155:		if (!report) {
2156:			ret = -1;
2157:			goto unlock;
2158:		}
2159:	
2160:		if (hdrv && hdrv->raw_event && hid_match_report(hid, report)) {
2161:			ret = hdrv->raw_event(hid, report, data, size);
2162:			if (ret < 0)
2163:				goto unlock;
2164:		}
2165:	
2166:		ret = hid_report_raw_event(hid, type, data, bufsize, size, interrupt);
2167:	
2168:	unlock:
2169:		if (!lock_already_taken)
2170:			up(&hid->driver_input_lock);
2171:		return ret;
2172:	}
 SourceFile:drivers/hid/hid-core.c]

gemini-3.1-pro-preview

							input: 38260
							output: 48
							thoughts: 37
						

Okay, let's see. My first thought is: **Hang on a second... `dispatch_hid_bpf_device_event` can *modify* the `data` itself?** This is unexpected. I need to be absolutely certain about this. Let's delve into the implementation of `dispatch_hid_bpf_device_event` right away and scrutinize it closely. I have to verify that assumption. I'll need to go through it with a fine-toothed comb to understand the possible side effects and any limitations. The implications are potentially significant, depending on how `data` is being used downstream. This demands immediate attention.

map[ContextFile:drivers/hid/hid-core.c IncludeLines:true Name:dispatch_hid_bpf_device_event]

map[SourceCode: 218:	static inline u8 *dispatch_hid_bpf_device_event(struct hid_device *hid, enum hid_report_type type,
 219:							u8 *data, size_t *buf_size, u32 *size,
 220:							int interrupt, u64 source, bool from_bpf)
 221:	{
 222:		return data;
 223:	}
 SourceFile:include/linux/hid_bpf.h]

gemini-3.1-pro-preview

							input: 38626
							output: 54
							thoughts: 48
						

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

**Diving into the HID BPF Details**

Hmm, I'm just looking at `dispatch_hid_bpf_device_event`. It's clearly defined in `include/linux/hid_bpf.h`. The definition mentions that when BPF is disabled, the function returns `data`. That's straightforward enough. But here's the kicker, what's happening if BPF *is* enabled? The documentation seems a bit light there. I'm going to have to dig deeper into the implementation or follow the execution path in the kernel code to understand the flow when the BPF filter is actually active. I need to know precisely what `dispatch_hid_bpf_device_event` is doing, and whether that "data" is the same, or if it has been transformed. Is the function even still returning data? This could involve further investigation into how the BPF program interacts with the HID event processing. Gotta figure out the control flow here.

map[ContextFile:drivers/hid/bpf/hid_bpf_dispatch.c IncludeLines:true Name:dispatch_hid_bpf_device_event]

map[SourceCode: 218:	static inline u8 *dispatch_hid_bpf_device_event(struct hid_device *hid, enum hid_report_type type,
 219:							u8 *data, size_t *buf_size, u32 *size,
 220:							int interrupt, u64 source, bool from_bpf)
 221:	{
 222:		return data;
 223:	}
 SourceFile:include/linux/hid_bpf.h]

gemini-3.1-pro-preview

							input: 39097
							output: 54
							thoughts: 36
						

Okay, let's see. My first thought is:

**Examining HID BPF Dispatch**

Hang on a moment. Before I dig too deep, I should probably check the source for `dispatch_hid_bpf_device_event`. It's likely in the `drivers/hid/bpf` area, and considering its name, the main dispatch logic will probably be in `hid_bpf_dispatch.c`. Yeah, that's where I need to start. I'll search for it there. That'll give me the core entry point and context. From there, I can understand how the BPF filter is actually applied to HID events.

map[ContextFile:drivers/hid/bpf/hid_bpf_dispatch.c IncludeLines:true Name:dispatch_hid_bpf_device_event]

map[SourceCode: 218:	static inline u8 *dispatch_hid_bpf_device_event(struct hid_device *hid, enum hid_report_type type,
 219:							u8 *data, size_t *buf_size, u32 *size,
 220:							int interrupt, u64 source, bool from_bpf)
 221:	{
 222:		return data;
 223:	}
 SourceFile:include/linux/hid_bpf.h]

gemini-3.1-pro-preview

							input: 39472
							output: 24
							thoughts: 8
						

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

**Quick and Dirty: The Power of `grep`**

Alright, so I'm facing this problem, and my first instinct? Let's just `grep` it. No need to overcomplicate things initially, right? We're often dealing with textual data, log files, or configuration files – and `grep` is still one of the most efficient tools in the shed for a quick-and-dirty scan. I'm thinking of it as a sanity check, a rapid way to either confirm my suspicion or at least narrow down the scope. Before I start reaching for more sophisticated parsing tools or diving into writing a custom script, let's see what a basic search turns up. It's about finding that needle in the haystack – or, at least, reducing the haystack to a manageable pile. Time is precious, and `grep` can be surprisingly effective for a first pass.

map[Expression:dispatch_hid_bpf_device_event]

map[Output:drivers/hid/bpf/hid_bpf_dispatch.c=25=u8 *
drivers/hid/bpf/hid_bpf_dispatch.c:26:dispatch_hid_bpf_device_event(struct hid_device *hdev, enum hid_report_type type, u8 *data,
drivers/hid/bpf/hid_bpf_dispatch.c-27-			      size_t *buf_size, u32 *size, int interrupt, u64 source,
--
drivers/hid/bpf/hid_bpf_dispatch.c-80-}
drivers/hid/bpf/hid_bpf_dispatch.c:81:EXPORT_SYMBOL_GPL(dispatch_hid_bpf_device_event);
drivers/hid/bpf/hid_bpf_dispatch.c-82-
--
drivers/hid/hid-core.c=2109=static int __hid_input_report(struct hid_device *hid, enum hid_report_type type,
--
drivers/hid/hid-core.c-2135-
drivers/hid/hid-core.c:2136:	data = dispatch_hid_bpf_device_event(hid, type, data, &bufsize, &size, interrupt,
drivers/hid/hid-core.c-2137-					     source, from_bpf);
--
include/linux/hid_bpf.h=187=struct hid_bpf {
--
include/linux/hid_bpf.h-201-#ifdef CONFIG_HID_BPF
include/linux/hid_bpf.h:202:u8 *dispatch_hid_bpf_device_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
include/linux/hid_bpf.h-203-				  size_t *buf_size, u32 *size, int interrupt, u64 source,
--
include/linux/hid_bpf.h=216=const u8 *call_hid_bpf_rdesc_fixup(struct hid_device *hdev, const u8 *rdesc, unsigned int *size);
include/linux/hid_bpf.h-217-#else /* CONFIG_HID_BPF */
include/linux/hid_bpf.h:218:static inline u8 *dispatch_hid_bpf_device_event(struct hid_device *hid, enum hid_report_type type,
include/linux/hid_bpf.h-219-						u8 *data, size_t *buf_size, u32 *size,
]

gemini-3.1-pro-preview

							input: 40358
							output: 54
							thoughts: 34
						

Here's my take on the thought process, as requested:

**Diving into `dispatch_hid_bpf_device_event`**

Okay, time to dig into this function, `dispatch_hid_bpf_device_event`, located in `drivers/hid/bpf/hid_bpf_dispatch.c`. I'm curious to see how the HID BPF infrastructure is actually handling events at the device level. This function is the core of event dispatch, so it's the right place to start. I expect it'll be where the BPF programs get their first opportunity to see data. From there, I'll assess how it handles those events within the context of the device driver and system, making sure it follows the kernel's design philosophy and, ideally, offers efficient processing. I'm keen to see if this handles the low-level aspects, like accessing the raw HID reports and managing any synchronization or locking involved in the process. I'm also interested in how it interacts with the broader event handling, such as `input_report_key`, `input_event`, etc.

map[ContextFile:drivers/hid/bpf/hid_bpf_dispatch.c IncludeLines:true Name:dispatch_hid_bpf_device_event]

map[SourceCode: 218:	static inline u8 *dispatch_hid_bpf_device_event(struct hid_device *hid, enum hid_report_type type,
 219:							u8 *data, size_t *buf_size, u32 *size,
 220:							int interrupt, u64 source, bool from_bpf)
 221:	{
 222:		return data;
 223:	}
 SourceFile:include/linux/hid_bpf.h]

gemini-3.1-pro-preview

							input: 40825
							output: 30
							thoughts: 25
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Diving into the HID BPF Dispatch**

Okay, hold on a second. Before I get any further into this, I need to get a clear picture of exactly how the BPF filtering is applied within the HID subsystem. The high-level overview is fine, but I'm going to need to dig directly into `drivers/hid/bpf/hid_bpf_dispatch.c`. I need to understand the exact mechanics of the dispatch process: the data structures used, the function calls involved in evaluating the BPF program, how the events are actually filtered or modified, and crucially, how this interacts with the regular HID event handling path. I want to see how the kernel code handles the BPF program's returned value, how it uses it to make decisions, and if there are any subtle interactions with other kernel components that I should be aware of. I'm looking for potential bottlenecks, points of customization, and areas where optimizations or edge case handling might be crucial. I expect this will be the best way to develop an understanding of what could be improved.

map[File:drivers/hid/bpf/hid_bpf_dispatch.c]

map[Contents:// SPDX-License-Identifier: GPL-2.0-only

/*
 *  HID-BPF support for Linux
 *
 *  Copyright (c) 2022-2024 Benjamin Tissoires
 */

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/bitops.h>
#include <linux/btf.h>
#include <linux/btf_ids.h>
#include <linux/filter.h>
#include <linux/hid.h>
#include <linux/hid_bpf.h>
#include <linux/init.h>
#include <linux/kfifo.h>
#include <linux/minmax.h>
#include <linux/module.h>
#include "hid_bpf_dispatch.h"

const struct hid_ops *hid_ops;
EXPORT_SYMBOL(hid_ops);

u8 *
dispatch_hid_bpf_device_event(struct hid_device *hdev, enum hid_report_type type, u8 *data,
			      size_t *buf_size, u32 *size, int interrupt, u64 source,
			      bool from_bpf)
{
	struct hid_bpf_ctx_kern ctx_kern = {
		.ctx = {
			.hid = hdev,
			.allocated_size = hdev->bpf.allocated_data,
			.size = *size,
		},
		.data = hdev->bpf.device_data,
		.from_bpf = from_bpf,
	};
	struct hid_bpf_ops *e;
	int ret;

	if (unlikely(hdev->bpf.destroyed))
		return ERR_PTR(-ENODEV);

	if (type >= HID_REPORT_TYPES)
		return ERR_PTR(-EINVAL);

	/* no program has been attached yet */
	if (!hdev->bpf.device_data)
		return data;

	memset(ctx_kern.data, 0, hdev->bpf.allocated_data);
	memcpy(ctx_kern.data, data, *size);

	rcu_read_lock();
	list_for_each_entry_rcu(e, &hdev->bpf.prog_list, list) {
		if (e->hid_device_event) {
			ret = e->hid_device_event(&ctx_kern.ctx, type, source);
			if (ret < 0) {
				rcu_read_unlock();
				return ERR_PTR(ret);
			}

			if (ret)
				ctx_kern.ctx.size = ret;
		}
	}
	rcu_read_unlock();

	ret = ctx_kern.ctx.size;
	if (ret) {
		if (ret > ctx_kern.ctx.allocated_size)
			return ERR_PTR(-EINVAL);

		*size = ret;
	}

	*buf_size = ctx_kern.ctx.allocated_size;
	return ctx_kern.data;
}
EXPORT_SYMBOL_GPL(dispatch_hid_bpf_device_event);

int dispatch_hid_bpf_raw_requests(struct hid_device *hdev,
				  unsigned char reportnum, u8 *buf,
				  u32 size, enum hid_report_type rtype,
				  enum hid_class_request reqtype,
				  u64 source, bool from_bpf)
{
	struct hid_bpf_ctx_kern ctx_kern = {
		.ctx = {
			.hid = hdev,
			.allocated_size = size,
			.size = size,
		},
		.data = buf,
		.from_bpf = from_bpf,
	};
	struct hid_bpf_ops *e;
	int ret, idx;

	if (unlikely(hdev->bpf.destroyed))
		return -ENODEV;

	if (rtype >= HID_REPORT_TYPES)
		return -EINVAL;

	idx = srcu_read_lock(&hdev->bpf.srcu);
	list_for_each_entry_srcu(e, &hdev->bpf.prog_list, list,
				 srcu_read_lock_held(&hdev->bpf.srcu)) {
		if (!e->hid_hw_request)
			continue;

		ret = e->hid_hw_request(&ctx_kern.ctx, reportnum, rtype, reqtype, source);
		if (ret)
			goto out;
	}
	ret = 0;

out:
	srcu_read_unlock(&hdev->bpf.srcu, idx);
	return ret;
}
EXPORT_SYMBOL_GPL(dispatch_hid_bpf_raw_requests);

int dispatch_hid_bpf_output_report(struct hid_device *hdev,
				   __u8 *buf, u32 size, u64 source,
				   bool from_bpf)
{
	struct hid_bpf_ctx_kern ctx_kern = {
		.ctx = {
			.hid = hdev,
			.allocated_size = size,
			.size = size,
		},
		.data = buf,
		.from_bpf = from_bpf,
	};
	struct hid_bpf_ops *e;
	int ret, idx;

	if (unlikely(hdev->bpf.destroyed))
		return -ENODEV;

	idx = srcu_read_lock(&hdev->bpf.srcu);
	list_for_each_entry_srcu(e, &hdev->bpf.prog_list, list,
				 srcu_read_lock_held(&hdev->bpf.srcu)) {
		if (!e->hid_hw_output_report)
			continue;

		ret = e->hid_hw_output_report(&ctx_kern.ctx, source);
		if (ret)
			goto out;
	}
	ret = 0;

out:
	srcu_read_unlock(&hdev->bpf.srcu, idx);
	return ret;
}
EXPORT_SYMBOL_GPL(dispatch_hid_bpf_output_report);

const u8 *call_hid_bpf_rdesc_fixup(struct hid_device *hdev, const u8 *rdesc, unsigned int *size)
{
	int ret;
	struct hid_bpf_ctx_kern ctx_kern = {
		.ctx = {
			.hid = hdev,
			.size = *size,
			.allocated_size = HID_MAX_DESCRIPTOR_SIZE,
		},
	};

	if (!hdev->bpf.rdesc_ops)
		goto ignore_bpf;

	ctx_kern.data = kzalloc(ctx_kern.ctx.allocated_size, GFP_KERNEL);
	if (!ctx_kern.data)
		goto ignore_bpf;

	memcpy(ctx_kern.data, rdesc, min_t(unsigned int, *size, HID_MAX_DESCRIPTOR_SIZE));

	ret = hdev->bpf.rdesc_ops->hid_rdesc_fixup(&ctx_kern.ctx);
	if (ret < 0)
		goto ignore_bpf;

	if (ret) {
		if (ret > ctx_kern.ctx.allocated_size)
			goto ignore_bpf;

		*size = ret;
	}

	return krealloc(ctx_kern.data, *size, GFP_KERNEL);

 ignore_bpf:
	kfree(ctx_kern.data);
	return rdesc;
}
EXPORT_SYMBOL_GPL(call_hid_bpf_rdesc_fixup);

static int device_match_id(struct device *dev, const void *id)
{
	struct hid_device *hdev = to_hid_device(dev);

	return hdev->id == *(int *)id;
}

struct hid_device *hid_get_device(unsigned int hid_id)
{
	struct device *dev;

	if (!hid_ops)
		return ERR_PTR(-EINVAL);

	dev = bus_find_device(hid_ops->bus_type, NULL, &hid_id, device_match_id);
	if (!dev)
		return ERR_PTR(-EINVAL);

	return to_hid_device(dev);
}

void hid_put_device(struct hid_device *hid)
{
	put_device(&hid->dev);
}

static int __hid_bpf_allocate_data(struct hid_device *hdev, u8 **data, u32 *size)
{
	u8 *alloc_data;
	unsigned int i, j, max_report_len = 0;
	size_t alloc_size = 0;

	/* compute the maximum report length for this device */
	for (i = 0; i < HID_REPORT_TYPES; i++) {
		struct hid_report_enum *report_enum = hdev->report_enum + i;

		for (j = 0; j < HID_MAX_IDS; j++) {
			struct hid_report *report = report_enum->report_id_hash[j];

			if (report)
				max_report_len = max(max_report_len, hid_report_len(report));
		}
	}

	/*
	 * Give us a little bit of extra space and some predictability in the
	 * buffer length we create. This way, we can tell users that they can
	 * work on chunks of 64 bytes of memory without having the bpf verifier
	 * scream at them.
	 */
	alloc_size = DIV_ROUND_UP(max_report_len, 64) * 64;

	alloc_data = kzalloc(alloc_size, GFP_KERNEL);
	if (!alloc_data)
		return -ENOMEM;

	*data = alloc_data;
	*size = alloc_size;

	return 0;
}

int hid_bpf_allocate_event_data(struct hid_device *hdev)
{
	/* hdev->bpf.device_data is already allocated, abort */
	if (hdev->bpf.device_data)
		return 0;

	return __hid_bpf_allocate_data(hdev, &hdev->bpf.device_data, &hdev->bpf.allocated_data);
}

int hid_bpf_reconnect(struct hid_device *hdev)
{
	if (!test_and_set_bit(ffs(HID_STAT_REPROBED), &hdev->status)) {
		/* trigger call to call_hid_bpf_rdesc_fixup() during the next probe */
		hdev->bpf_rsize = 0;
		return device_reprobe(&hdev->dev);
	}

	return 0;
}

/* Disables missing prototype warnings */
__bpf_kfunc_start_defs();

/**
 * hid_bpf_get_data - Get the kernel memory pointer associated with the context @ctx
 *
 * @ctx: The HID-BPF context
 * @offset: The offset within the memory
 * @rdwr_buf_size: the const size of the buffer
 *
 * @returns %NULL on error, an %__u8 memory pointer on success
 */
__bpf_kfunc __u8 *
hid_bpf_get_data(struct hid_bpf_ctx *ctx, unsigned int offset, const size_t rdwr_buf_size)
{
	struct hid_bpf_ctx_kern *ctx_kern;

	ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);

	if (rdwr_buf_size + offset > ctx->allocated_size)
		return NULL;

	return ctx_kern->data + offset;
}

/**
 * hid_bpf_allocate_context - Allocate a context to the given HID device
 *
 * @hid_id: the system unique identifier of the HID device
 *
 * @returns A pointer to &struct hid_bpf_ctx on success, %NULL on error.
 */
__bpf_kfunc struct hid_bpf_ctx *
hid_bpf_allocate_context(unsigned int hid_id)
{
	struct hid_device *hdev;
	struct hid_bpf_ctx_kern *ctx_kern = NULL;

	hdev = hid_get_device(hid_id);
	if (IS_ERR(hdev))
		return NULL;

	ctx_kern = kzalloc_obj(*ctx_kern);
	if (!ctx_kern) {
		hid_put_device(hdev);
		return NULL;
	}

	ctx_kern->ctx.hid = hdev;

	return &ctx_kern->ctx;
}

/**
 * hid_bpf_release_context - Release the previously allocated context @ctx
 *
 * @ctx: the HID-BPF context to release
 *
 */
__bpf_kfunc void
hid_bpf_release_context(struct hid_bpf_ctx *ctx)
{
	struct hid_bpf_ctx_kern *ctx_kern;
	struct hid_device *hid;

	ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);
	hid = (struct hid_device *)ctx_kern->ctx.hid; /* ignore const */

	kfree(ctx_kern);

	/* get_device() is called by bus_find_device() */
	hid_put_device(hid);
}

static int
__hid_bpf_hw_check_params(struct hid_bpf_ctx *ctx, __u8 *buf, size_t *buf__sz,
			  enum hid_report_type rtype)
{
	struct hid_report_enum *report_enum;
	struct hid_report *report;
	u32 report_len;

	/* check arguments */
	if (!hid_ops)
		return -EINVAL;

	switch (rtype) {
	case HID_INPUT_REPORT:
	case HID_OUTPUT_REPORT:
	case HID_FEATURE_REPORT:
		break;
	default:
		return -EINVAL;
	}

	if (*buf__sz < 1)
		return -EINVAL;

	report_enum = ctx->hid->report_enum + rtype;
	report = hid_ops->hid_get_report(report_enum, buf);
	if (!report)
		return -EINVAL;

	report_len = hid_report_len(report);

	if (*buf__sz > report_len)
		*buf__sz = report_len;

	return 0;
}

/**
 * hid_bpf_hw_request - Communicate with a HID device
 *
 * @ctx: the HID-BPF context previously allocated in hid_bpf_allocate_context()
 * @buf: a %PTR_TO_MEM buffer
 * @buf__sz: the size of the data to transfer
 * @rtype: the type of the report (%HID_INPUT_REPORT, %HID_FEATURE_REPORT, %HID_OUTPUT_REPORT)
 * @reqtype: the type of the request (%HID_REQ_GET_REPORT, %HID_REQ_SET_REPORT, ...)
 *
 * @returns %0 on success, a negative error code otherwise.
 */
__bpf_kfunc int
hid_bpf_hw_request(struct hid_bpf_ctx *ctx, __u8 *buf, size_t buf__sz,
		   enum hid_report_type rtype, enum hid_class_request reqtype)
{
	struct hid_bpf_ctx_kern *ctx_kern;
	size_t size = buf__sz;
	u8 *dma_data;
	int ret;

	ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);

	if (ctx_kern->from_bpf)
		return -EDEADLOCK;

	/* check arguments */
	ret = __hid_bpf_hw_check_params(ctx, buf, &size, rtype);
	if (ret)
		return ret;

	switch (reqtype) {
	case HID_REQ_GET_REPORT:
	case HID_REQ_GET_IDLE:
	case HID_REQ_GET_PROTOCOL:
	case HID_REQ_SET_REPORT:
	case HID_REQ_SET_IDLE:
	case HID_REQ_SET_PROTOCOL:
		break;
	default:
		return -EINVAL;
	}

	dma_data = kmemdup(buf, size, GFP_KERNEL);
	if (!dma_data)
		return -ENOMEM;

	ret = hid_ops->hid_hw_raw_request(ctx->hid,
					      dma_data[0],
					      dma_data,
					      size,
					      rtype,
					      reqtype,
					      (u64)(long)ctx,
					      true); /* prevent infinite recursions */

	if (ret > size)
		ret = size;
	if (ret > 0)
		memcpy(buf, dma_data, ret);

	kfree(dma_data);
	return ret;
}

/**
 * hid_bpf_hw_output_report - Send an output report to a HID device
 *
 * @ctx: the HID-BPF context previously allocated in hid_bpf_allocate_context()
 * @buf: a %PTR_TO_MEM buffer
 * @buf__sz: the size of the data to transfer
 *
 * Returns the number of bytes transferred on success, a negative error code otherwise.
 */
__bpf_kfunc int
hid_bpf_hw_output_report(struct hid_bpf_ctx *ctx, __u8 *buf, size_t buf__sz)
{
	struct hid_bpf_ctx_kern *ctx_kern;
	size_t size = buf__sz;
	u8 *dma_data;
	int ret;

	ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);
	if (ctx_kern->from_bpf)
		return -EDEADLOCK;

	/* check arguments */
	ret = __hid_bpf_hw_check_params(ctx, buf, &size, HID_OUTPUT_REPORT);
	if (ret)
		return ret;

	dma_data = kmemdup(buf, size, GFP_KERNEL);
	if (!dma_data)
		return -ENOMEM;

	ret = hid_ops->hid_hw_output_report(ctx->hid, dma_data, size, (u64)(long)ctx, true);

	kfree(dma_data);
	return ret;
}

static int
__hid_bpf_input_report(struct hid_bpf_ctx *ctx, enum hid_report_type type, u8 *buf,
		       size_t size, bool lock_already_taken)
{
	struct hid_bpf_ctx_kern *ctx_kern;
	int ret;

	ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);
	if (ctx_kern->from_bpf)
		return -EDEADLOCK;

	/* check arguments */
	ret = __hid_bpf_hw_check_params(ctx, buf, &size, type);
	if (ret)
		return ret;

	return hid_ops->hid_input_report(ctx->hid, type, buf, size, size, 0, (u64)(long)ctx, true,
					 lock_already_taken);
}

/**
 * hid_bpf_try_input_report - Inject a HID report in the kernel from a HID device
 *
 * @ctx: the HID-BPF context previously allocated in hid_bpf_allocate_context()
 * @type: the type of the report (%HID_INPUT_REPORT, %HID_FEATURE_REPORT, %HID_OUTPUT_REPORT)
 * @buf: a %PTR_TO_MEM buffer
 * @buf__sz: the size of the data to transfer
 *
 * Returns %0 on success, a negative error code otherwise. This function will immediately
 * fail if the device is not available, thus can be safely used in IRQ context.
 */
__bpf_kfunc int
hid_bpf_try_input_report(struct hid_bpf_ctx *ctx, enum hid_report_type type, u8 *buf,
			 const size_t buf__sz)
{
	struct hid_bpf_ctx_kern *ctx_kern;
	bool from_hid_event_hook;

	ctx_kern = container_of(ctx, struct hid_bpf_ctx_kern, ctx);
	from_hid_event_hook = ctx_kern->data && ctx_kern->data == ctx->hid->bpf.device_data;

	return __hid_bpf_input_report(ctx, type, buf, buf__sz, from_hid_event_hook);
}

/**
 * hid_bpf_input_report - Inject a HID report in the kernel from a HID device
 *
 * @ctx: the HID-BPF context previously allocated in hid_bpf_allocate_context()
 * @type: the type of the report (%HID_INPUT_REPORT, %HID_FEATURE_REPORT, %HID_OUTPUT_REPORT)
 * @buf: a %PTR_TO_MEM buffer
 * @buf__sz: the size of the data to transfer
 *
 * Returns %0 on success, a negative error code otherwise. This function will wait for the
 * device to be available before injecting the event, thus needs to be called in sleepable
 * context.
 */
__bpf_kfunc int
hid_bpf_input_report(struct hid_bpf_ctx *ctx, enum hid_report_type type, u8 *buf,
		     const size_t buf__sz)
{
	int ret;

	ret = down_interruptible(&ctx->hid->driver_input_lock);
	if (ret)
		return ret;

	/* check arguments */
	ret = __hid_bpf_input_report(ctx, type, buf, buf__sz, true /* lock_already_taken */);

	up(&ctx->hid->driver_input_lock);

	return ret;
}
__bpf_kfunc_end_defs();

/*
 * The following set contains all functions we agree BPF programs
 * can use.
 */
BTF_KFUNCS_START(hid_bpf_kfunc_ids)
BTF_ID_FLAGS(func, hid_bpf_get_data, KF_RET_NULL)
BTF_ID_FLAGS(func, hid_bpf_allocate_context, KF_ACQUIRE | KF_RET_NULL | KF_SLEEPABLE)
BTF_ID_FLAGS(func, hid_bpf_release_context, KF_RELEASE | KF_SLEEPABLE)
BTF_ID_FLAGS(func, hid_bpf_hw_request, KF_SLEEPABLE)
BTF_ID_FLAGS(func, hid_bpf_hw_output_report, KF_SLEEPABLE)
BTF_ID_FLAGS(func, hid_bpf_input_report, KF_SLEEPABLE)
BTF_ID_FLAGS(func, hid_bpf_try_input_report)
BTF_KFUNCS_END(hid_bpf_kfunc_ids)

static const struct btf_kfunc_id_set hid_bpf_kfunc_set = {
	.owner = THIS_MODULE,
	.set   = &hid_bpf_kfunc_ids,
};

/* for syscall HID-BPF */
BTF_KFUNCS_START(hid_bpf_syscall_kfunc_ids)
BTF_ID_FLAGS(func, hid_bpf_allocate_context, KF_ACQUIRE | KF_RET_NULL)
BTF_ID_FLAGS(func, hid_bpf_release_context, KF_RELEASE)
BTF_ID_FLAGS(func, hid_bpf_hw_request)
BTF_ID_FLAGS(func, hid_bpf_hw_output_report)
BTF_ID_FLAGS(func, hid_bpf_input_report)
BTF_KFUNCS_END(hid_bpf_syscall_kfunc_ids)

static const struct btf_kfunc_id_set hid_bpf_syscall_kfunc_set = {
	.owner = THIS_MODULE,
	.set   = &hid_bpf_syscall_kfunc_ids,
};

int hid_bpf_connect_device(struct hid_device *hdev)
{
	bool need_to_allocate = false;
	struct hid_bpf_ops *e;

	rcu_read_lock();
	list_for_each_entry_rcu(e, &hdev->bpf.prog_list, list) {
		if (e->hid_device_event) {
			need_to_allocate = true;
			break;
		}
	}
	rcu_read_unlock();

	/* only allocate BPF data if there are programs attached */
	if (!need_to_allocate)
		return 0;

	return hid_bpf_allocate_event_data(hdev);
}
EXPORT_SYMBOL_GPL(hid_bpf_connect_device);

void hid_bpf_disconnect_device(struct hid_device *hdev)
{
	kfree(hdev->bpf.device_data);
	hdev->bpf.device_data = NULL;
	hdev->bpf.allocated_data = 0;
}
EXPORT_SYMBOL_GPL(hid_bpf_disconnect_device);

void hid_bpf_destroy_device(struct hid_device *hdev)
{
	if (!hdev)
		return;

	/* mark the device as destroyed in bpf so we don't reattach it */
	hdev->bpf.destroyed = true;

	__hid_bpf_ops_destroy_device(hdev);

	synchronize_srcu(&hdev->bpf.srcu);
	cleanup_srcu_struct(&hdev->bpf.srcu);
}
EXPORT_SYMBOL_GPL(hid_bpf_destroy_device);

int hid_bpf_device_init(struct hid_device *hdev)
{
	INIT_LIST_HEAD(&hdev->bpf.prog_list);
	mutex_init(&hdev->bpf.prog_list_lock);
	return init_srcu_struct(&hdev->bpf.srcu);
}
EXPORT_SYMBOL_GPL(hid_bpf_device_init);

static int __init hid_bpf_init(void)
{
	int err;

	/* Note: if we exit with an error any time here, we would entirely break HID, which
	 * is probably not something we want. So we log an error and return success.
	 *
	 * This is not a big deal: nobody will be able to use the functionality.
	 */

	err = register_btf_kfunc_id_set(BPF_PROG_TYPE_STRUCT_OPS, &hid_bpf_kfunc_set);
	if (err) {
		pr_warn("error while setting HID BPF tracing kfuncs: %d", err);
		return 0;
	}

	err = register_btf_kfunc_id_set(BPF_PROG_TYPE_SYSCALL, &hid_bpf_syscall_kfunc_set);
	if (err) {
		pr_warn("error while setting HID BPF syscall kfuncs: %d", err);
		return 0;
	}

	return 0;
}

late_initcall(hid_bpf_init);
MODULE_AUTHOR("Benjamin Tissoires");
MODULE_LICENSE("GPL");
]

gemini-3.1-pro-preview

							input: 47758
							output: 46
							thoughts: 441
						

**Investigating a Potential HID BPF Device Event Bug**

Okay, here's what's running through my head. I'm looking at `dispatch_hid_bpf_device_event`. My initial thought is that it allocates `hdev->bpf.device_data` and copies the input `data` there, making it the destination. But hang on, didn't `__hid_bpf_allocate_data` actually allocate `hdev->bpf.device_data`?

Let me see that allocation again:
```c
    alloc_size = DIV_ROUND_UP(max_report_len, 64) * 64;

    alloc_data = kzalloc(alloc_size, GFP_KERNEL);
```
Right, so the allocation size is based on the maximum report length. Ah, if `max_report_len` is zero, `alloc_size` is *also* zero! And, if `alloc_size` is zero, `kzalloc(0, GFP_KERNEL)` returns `ZERO_SIZE_PTR`, which, if I recall correctly, is essentially 0x10. I know this is a known quirk.

So, if that's the case, and `kzalloc(0)` returns this special value, here is how the code proceeds:
```c
	if (!hdev->bpf.device_data)
		return data;

	memset(ctx_kern.data, 0, hdev->bpf.allocated_data);
	memcpy(ctx_kern.data, data, *size);
```
So, if `hdev->bpf.device_data` isn't allocated, the function simply *returns* the original input `data`. In this particular case, `data` is the `urb->transfer_buffer`. Right, and `urb->transfer_buffer` is allocated by `usb_alloc_coherent`. `usb_alloc_coherent` then calls `dma_alloc_coherent`.

Now, the crash dump is suggesting that the buggy address "belongs to the object at ffff888111fe5880 which belongs to the cache task_struct of size 7296". So that `task_struct` is allocated by `kmem_cache_alloc_node`. But why in the world would `data` be pointing to a `task_struct`? Something's not lining up here. I need to go back and check `hid_alloc_buffers` again, and make sure that buffer is correctly associated with the correct device context. I'm missing a key piece of information!

map[ContextFile:drivers/hid/usbhid/hid-core.c IncludeLines:true Name:hid_alloc_buffers]

map[SourceCode: 854:	static int hid_alloc_buffers(struct usb_device *dev, struct hid_device *hid)
 855:	{
 856:		struct usbhid_device *usbhid = hid->driver_data;
 857:	
 858:		usbhid->inbuf = usb_alloc_coherent(dev, usbhid->bufsize, GFP_KERNEL,
 859:				&usbhid->inbuf_dma);
 860:		usbhid->outbuf = usb_alloc_coherent(dev, usbhid->bufsize, GFP_KERNEL,
 861:				&usbhid->outbuf_dma);
 862:		usbhid->cr = kmalloc_obj(*usbhid->cr);
 863:		usbhid->ctrlbuf = usb_alloc_coherent(dev, usbhid->bufsize, GFP_KERNEL,
 864:				&usbhid->ctrlbuf_dma);
 865:		if (!usbhid->inbuf || !usbhid->outbuf || !usbhid->cr ||
 866:				!usbhid->ctrlbuf)
 867:			return -1;
 868:	
 869:		return 0;
 870:	}
 SourceFile:drivers/hid/usbhid/hid-core.c]

gemini-3.1-pro-preview

							input: 49158
							output: 50
							thoughts: 68
						

**Investigating Potential Memory Allocation Issues in the Syzkaller Virtual USB Controller**

Okay, hold on a minute. I'm thinking about how the `usb_alloc_coherent` function, which is critical for memory management within the `dummy_hcd` driver – you know, the virtual USB controller that Syzkaller relies on for fuzzing – might be allocating memory under the hood. It's likely using something like `kmalloc` or a similar kernel memory allocator, and this could be an area we need to understand better for potential fuzzing implications. Let me drill down on that function.

To get a clearer picture of what's happening, I need to look closely at the memory allocation functions implemented within the `dummy_hcd.c` source file. Specifically, I'll need to check the implementations of either `dummy_alloc_buffer` (if it exists and is relevant), or, more generally, `dma_alloc_coherent` to see exactly how memory is being requested and managed. This is key to figuring out the memory characteristics. I need to understand these allocations thoroughly to ensure proper fuzzing coverage.

requested entity does not exist

map[ContextFile:drivers/usb/gadget/udc/dummy_hcd.c IncludeLines:true Name:dummy_alloc_buffer]

map[SourceCode: SourceFile:]

gemini-3.1-pro-preview

							input: 49533
							output: 17
							thoughts: 18
						

Here's a summary of my thought process:

**Diving into the Coherent Allocation Logic**

Okay, so I need to understand how coherent memory allocation is handled, specifically within this `dummy_hcd.c` file. My initial thought is to jump directly into the code and locate the implementation or use of the `alloc_coherent` function. I'm assuming that function is going to be the central point to understand how coherent memory is managed. It's likely going to involve some interaction with DMA, and I need to see exactly how they've set things up. Is it using a specific DMA API, or a custom approach? What kind of memory pools or mappings are being used? I'm expecting to see details around cache flushing and synchronization, all critical for coherent memory operation.

map[Expression:alloc_coherent]

map[Output:
Full output is too long, showing 500 out of 12804 lines.
Use more precise expression if possible.

[Documentation/core-api/dma-api-howto.rst=424=you should do::
 --
 Documentation/core-api/dma-api-howto.rst-427-
 Documentation/core-api/dma-api-howto.rst:428:	cpu_addr = dma_alloc_coherent(dev, size, &dma_handle, gfp);
 Documentation/core-api/dma-api-howto.rst-429-
 --
 Documentation/core-api/dma-api-howto.rst=445=dma_pool interface as well.
 Documentation/core-api/dma-api-howto.rst-446-
 Documentation/core-api/dma-api-howto.rst:447:dma_alloc_coherent() returns two values: the virtual address which you
 Documentation/core-api/dma-api-howto.rst-448-can use to access it from the CPU and dma_handle which you pass to the
 --
 Documentation/core-api/dma-api-howto.rst=462=where dev, size are the same as in the above call and cpu_addr and
 Documentation/core-api/dma-api-howto.rst:463:dma_handle are the values dma_alloc_coherent() returned to you.
 Documentation/core-api/dma-api-howto.rst-464-This function may not be called in interrupt context.
 --
 Documentation/core-api/dma-api-howto.rst=466=If your driver needs lots of smaller memory regions, you can write
 Documentation/core-api/dma-api-howto.rst:467:custom code to subdivide pages returned by dma_alloc_coherent(),
 Documentation/core-api/dma-api-howto.rst-468-or you can use the dma_pool API to do that.  A dma_pool is like
 Documentation/core-api/dma-api-howto.rst:469:a kmem_cache, but it uses dma_alloc_coherent(), not __get_free_pages().
 Documentation/core-api/dma-api-howto.rst-470-Also, it understands common hardware constraints for alignment,
 --
 Documentation/core-api/dma-api-howto.rst=484=must not cross 4KByte boundaries (but at that time it may be better to
 Documentation/core-api/dma-api-howto.rst:485:use dma_alloc_coherent() directly instead).
 Documentation/core-api/dma-api-howto.rst-486-
 --
 Documentation/core-api/dma-api-howto.rst=491=flags are GFP_KERNEL if blocking is permitted (not in_interrupt nor
 Documentation/core-api/dma-api-howto.rst:492:holding SMP locks), GFP_ATOMIC otherwise.  Like dma_alloc_coherent(),
 Documentation/core-api/dma-api-howto.rst-493-this returns two values, cpu_addr and dma_handle.
 --
 Documentation/core-api/dma-api-howto.rst=786=failure can be determined by:
 Documentation/core-api/dma-api-howto.rst-787-
 Documentation/core-api/dma-api-howto.rst:788:- checking if dma_alloc_coherent() returns NULL or dma_map_sg returns 0
 Documentation/core-api/dma-api-howto.rst-789-
 --
 Documentation/core-api/dma-api.rst=27=Part Ia - Using large DMA-coherent buffers
 --
 Documentation/core-api/dma-api.rst-32-	void *
 Documentation/core-api/dma-api.rst:33:	dma_alloc_coherent(struct device *dev, size_t size,
 Documentation/core-api/dma-api.rst-34-			   dma_addr_t *dma_handle, gfp_t flag)
 --
 Documentation/core-api/dma-api.rst=66=Free a previously allocated region of coherent memory.  dev, size and dma_handle
 Documentation/core-api/dma-api.rst:67:must all be the same as those passed into dma_alloc_coherent().  cpu_addr must
 Documentation/core-api/dma-api.rst:68:be the virtual address returned by dma_alloc_coherent().
 Documentation/core-api/dma-api.rst-69-
 --
 Documentation/core-api/dma-api.rst=80=descriptors or I/O buffers.  Rather than allocating in units of a page
 Documentation/core-api/dma-api.rst:81:or more using dma_alloc_coherent(), you can use DMA pools.  These work
 Documentation/core-api/dma-api.rst-82-much like a struct kmem_cache, except that they use the DMA-coherent allocator,
 --
 Documentation/driver-api/driver-model/devres.rst=58=drivers using devres.  For example, coherent DMA memory is acquired
 Documentation/driver-api/driver-model/devres.rst:59:using dma_alloc_coherent().  The managed version is called
 Documentation/driver-api/driver-model/devres.rst:60:dmam_alloc_coherent().  It is identical to dma_alloc_coherent() except
 Documentation/driver-api/driver-model/devres.rst-61-for the DMA memory allocated using it is managed and will be
 --
 Documentation/driver-api/driver-model/devres.rst=63=the following::
 --
 Documentation/driver-api/driver-model/devres.rst-77-
 Documentation/driver-api/driver-model/devres.rst:78:  dmam_alloc_coherent(dev, size, dma_handle, gfp)
 Documentation/driver-api/driver-model/devres.rst-79-  {
 --
 Documentation/driver-api/driver-model/devres.rst-86-	/* alloc DMA memory as usual */
 Documentation/driver-api/driver-model/devres.rst:87:	vaddr = dma_alloc_coherent(...);
 Documentation/driver-api/driver-model/devres.rst-88-	...
 --
 Documentation/driver-api/driver-model/devres.rst-98-
 Documentation/driver-api/driver-model/devres.rst:99:If a driver uses dmam_alloc_coherent(), the area is guaranteed to be
 Documentation/driver-api/driver-model/devres.rst-100-freed whether initialization fails half-way or the device gets
 --
 Documentation/driver-api/driver-model/devres.rst=103=looks like the following::
 --
 Documentation/driver-api/driver-model/devres.rst-112-
 Documentation/driver-api/driver-model/devres.rst:113:	d->ring = dmam_alloc_coherent(...);
 Documentation/driver-api/driver-model/devres.rst-114-	if (!d->ring)
 --
 Documentation/driver-api/driver-model/devres.rst=257=DMA
 Documentation/driver-api/driver-model/devres.rst-258-  dmaenginem_async_device_register()
 Documentation/driver-api/driver-model/devres.rst:259:  dmam_alloc_coherent()
 Documentation/driver-api/driver-model/devres.rst-260-  dmam_alloc_attrs()
 --
 Documentation/driver-api/usb/dma.rst=37=and effects like cache-trashing can impose subtle penalties.
 --
 Documentation/driver-api/usb/dma.rst-48-
 Documentation/driver-api/usb/dma.rst:49:	void *usb_alloc_coherent (struct usb_device *dev, size_t size,
 Documentation/driver-api/usb/dma.rst-50-		int mem_flags, dma_addr_t *dma);
 --
 Documentation/driver-api/usb/writing_musb_glue_layer.rst=509=defines the width of the DMA mask that is going to be used, and
 Documentation/driver-api/usb/writing_musb_glue_layer.rst-510-``coherent_dma_mask`` (line 26) has the same purpose but for the
 Documentation/driver-api/usb/writing_musb_glue_layer.rst:511:``alloc_coherent`` DMA mappings: in both cases we are using a 32 bits mask.
 Documentation/driver-api/usb/writing_musb_glue_layer.rst-512-Then the resource field (line 29) is simply a pointer to the resource
 --
 Documentation/memory-barriers.txt=2559=guarantees:
 --
 Documentation/memory-barriers.txt-2582-	   propagated to, the same thread. This ensures that writes by the CPU
 Documentation/memory-barriers.txt:2583:	   to an outbound DMA buffer allocated by dma_alloc_coherent() will be
 Documentation/memory-barriers.txt-2584-	   visible to a DMA engine when the CPU writes to its MMIO control
 --
 Documentation/memory-barriers.txt-2589-	   ensures that reads by the CPU from an incoming DMA buffer allocated
 Documentation/memory-barriers.txt:2590:	   by dma_alloc_coherent() will not see stale data after reading from
 Documentation/memory-barriers.txt-2591-	   the DMA engine's MMIO status register to establish that the DMA
 --
 Documentation/process/deprecated.rst=78=be used::
 Documentation/process/deprecated.rst-79-
 Documentation/process/deprecated.rst:80:	bar = dma_alloc_coherent(dev, array_size(count, size), &dma, GFP_KERNEL);
 Documentation/process/deprecated.rst-81-
 --
 Documentation/scsi/ChangeLog.arcmsr-22-** 1.20.00.06    3/12/2005       Erich Chen     fix with arcmsr_pci_unmap_dma "unsigned long" cast,
 Documentation/scsi/ChangeLog.arcmsr:23:**						modify PCCB POOL allocated by "dma_alloc_coherent"
 Documentation/scsi/ChangeLog.arcmsr-24-**						(Kornel Wieliczek's comment)
 --
 Documentation/scsi/ChangeLog.megaraid_sas=437=waiting for depending on cmd completion from isr path.
 --
 Documentation/scsi/ChangeLog.megaraid_sas-447-	1. Memory Manager for IOCTL removed for 2.6 kernels.
 Documentation/scsi/ChangeLog.megaraid_sas:448:	   pci_alloc_consistent replaced by dma_alloc_coherent. With this
 Documentation/scsi/ChangeLog.megaraid_sas-449-	   change there is no need of memory manager in the driver code
 --
 Documentation/scsi/ChangeLog.megaraid_sas-460-	It does, but the DMA API was expanded to cope with this exact case, so
 Documentation/scsi/ChangeLog.megaraid_sas:461:	use dma_alloc_coherent() directly in the megaraid code instead.  The dev
 Documentation/scsi/ChangeLog.megaraid_sas-462-	is just &pci_dev->dev.
 --
 Documentation/translations/it_IT/process/deprecated.rst=87=le funzioni del tipo *saturate-on-overflow*::
 Documentation/translations/it_IT/process/deprecated.rst-88-
 Documentation/translations/it_IT/process/deprecated.rst:89:	bar = dma_alloc_coherent(dev, array_size(count, size), &dma, GFP_KERNEL);
 Documentation/translations/it_IT/process/deprecated.rst-90-
 --
 Documentation/translations/sp_SP/memory-barriers.txt=2650=grados de garantías de orden:
 --
 Documentation/translations/sp_SP/memory-barriers.txt-2674-	   que las escrituras de la CPU a un búfer DMA de salida asignadas por
 Documentation/translations/sp_SP/memory-barriers.txt:2675:           dma_alloc_coherent() serán visibles para un motor ("engine") DMA
 Documentation/translations/sp_SP/memory-barriers.txt-2676-           cuando la CPU escriba en sus registros de control MMIO, para activar
 --
 Documentation/translations/sp_SP/memory-barriers.txt-2682-           la CPU desde un búfer DMA entrantes asignadas por
 Documentation/translations/sp_SP/memory-barriers.txt:2683:           dma_alloc_coherent(), no verán datos obsoletos después de leer el
 Documentation/translations/sp_SP/memory-barriers.txt-2684-           registro de estado MMIO del motor DMA, para establecer que la
 --
 arch/alpha/kernel/pci_iommu.c=343=static void alpha_pci_unmap_phys(struct device *dev, dma_addr_t dma_addr,
 --
 arch/alpha/kernel/pci_iommu.c-404-
 arch/alpha/kernel/pci_iommu.c:405:static void *alpha_pci_alloc_coherent(struct device *dev, size_t size,
 arch/alpha/kernel/pci_iommu.c-406-				      dma_addr_t *dma_addrp, gfp_t gfp,
 --
 arch/alpha/kernel/pci_iommu.c=911=const struct dma_map_ops alpha_pci_ops = {
 arch/alpha/kernel/pci_iommu.c:912:	.alloc			= alpha_pci_alloc_coherent,
 arch/alpha/kernel/pci_iommu.c-913-	.free			= alpha_pci_free_coherent,
 --
 arch/hexagon/Kconfig=5=config HEXAGON
 --
 arch/hexagon/Kconfig-24-	select HAVE_PERF_EVENTS
 arch/hexagon/Kconfig:25:	# GENERIC_ALLOCATOR is used by dma_alloc_coherent()
 arch/hexagon/Kconfig-26-	select GENERIC_ALLOCATOR
 --
 arch/mips/lantiq/xway/dma.c=122=ltq_dma_alloc(struct ltq_dma_channel *ch)
 --
 arch/mips/lantiq/xway/dma.c-126-	ch->desc = 0;
 arch/mips/lantiq/xway/dma.c:127:	ch->desc_base = dma_alloc_coherent(ch->dev,
 arch/mips/lantiq/xway/dma.c-128-					   LTQ_DESC_NUM * LTQ_DESC_SIZE,
 --
 arch/mips/lantiq/xway/vmmc.c=27=static int vmmc_probe(struct platform_device *pdev)
 --
 arch/mips/lantiq/xway/vmmc.c-35-	cp1_base =
 arch/mips/lantiq/xway/vmmc.c:36:		(void *) CPHYSADDR(dma_alloc_coherent(&pdev->dev, CP1_SIZE,
 arch/mips/lantiq/xway/vmmc.c-37-						    &dma, GFP_KERNEL));
 --
 arch/powerpc/include/asm/iommu.h=266=extern void ppc_iommu_unmap_sg(struct iommu_table *tbl,
 --
 arch/powerpc/include/asm/iommu.h-271-
 arch/powerpc/include/asm/iommu.h:272:extern void *iommu_alloc_coherent(struct device *dev, struct iommu_table *tbl,
 arch/powerpc/include/asm/iommu.h-273-				  size_t size, dma_addr_t *dma_handle,
 --
 arch/powerpc/kernel/dma-iommu.c=76=bool arch_dma_free_direct(struct device *dev, dma_addr_t dma_handle)
 --
 arch/powerpc/kernel/dma-iommu.c-92- */
 arch/powerpc/kernel/dma-iommu.c:93:static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
 arch/powerpc/kernel/dma-iommu.c-94-				      dma_addr_t *dma_handle, gfp_t flag,
 --
 arch/powerpc/kernel/dma-iommu.c-96-{
 arch/powerpc/kernel/dma-iommu.c:97:	return iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
 arch/powerpc/kernel/dma-iommu.c-98-				    dma_handle, dev->coherent_dma_mask, flag,
 --
 arch/powerpc/kernel/dma-iommu.c=216=const struct dma_map_ops dma_iommu_ops = {
 arch/powerpc/kernel/dma-iommu.c:217:	.alloc			= dma_iommu_alloc_coherent,
 arch/powerpc/kernel/dma-iommu.c-218-	.free			= dma_iommu_free_coherent,
 --
 arch/powerpc/kernel/iommu.c=893=void iommu_unmap_phys(struct iommu_table *tbl, dma_addr_t dma_handle,
 --
 arch/powerpc/kernel/iommu.c-911- */
 arch/powerpc/kernel/iommu.c:912:void *iommu_alloc_coherent(struct device *dev, struct iommu_table *tbl,
 arch/powerpc/kernel/iommu.c-913-			   size_t size,	dma_addr_t *dma_handle,
 --
 arch/powerpc/platforms/pasemi/dma_lib.c=242=int pasemi_dma_alloc_ring(struct pasemi_dmachan *chan, int ring_size)
 --
 arch/powerpc/platforms/pasemi/dma_lib.c-247-
 arch/powerpc/platforms/pasemi/dma_lib.c:248:	chan->ring_virt = dma_alloc_coherent(&dma_pdev->dev,
 arch/powerpc/platforms/pasemi/dma_lib.c-249-					     ring_size * sizeof(u64),
 --
 arch/powerpc/platforms/pasemi/dma_lib.c=337=EXPORT_SYMBOL(pasemi_dma_stop_chan);
 --
 arch/powerpc/platforms/pasemi/dma_lib.c-344- * Allocate a buffer to be used by the DMA engine for read/write,
 arch/powerpc/platforms/pasemi/dma_lib.c:345: * similar to dma_alloc_coherent().
 arch/powerpc/platforms/pasemi/dma_lib.c-346- *
 --
 arch/powerpc/platforms/pasemi/dma_lib.c=349=void *pasemi_dma_alloc_buf(struct pasemi_dmachan *chan, int size,
 --
 arch/powerpc/platforms/pasemi/dma_lib.c-351-{
 arch/powerpc/platforms/pasemi/dma_lib.c:352:	return dma_alloc_coherent(&dma_pdev->dev, size, handle, GFP_KERNEL);
 arch/powerpc/platforms/pasemi/dma_lib.c-353-}
 --
 arch/powerpc/platforms/ps3/system-bus.c=499=core_initcall(ps3_system_bus_init);
 --
 arch/powerpc/platforms/ps3/system-bus.c-504- */
 arch/powerpc/platforms/ps3/system-bus.c:505:static void * ps3_alloc_coherent(struct device *_dev, size_t size,
 arch/powerpc/platforms/ps3/system-bus.c-506-				 dma_addr_t *dma_handle, gfp_t flag,
 --
 arch/powerpc/platforms/ps3/system-bus.c=692=static const struct dma_map_ops ps3_sb_dma_ops = {
 arch/powerpc/platforms/ps3/system-bus.c:693:	.alloc = ps3_alloc_coherent,
 arch/powerpc/platforms/ps3/system-bus.c-694-	.free = ps3_free_coherent,
 --
 arch/powerpc/platforms/ps3/system-bus.c=706=static const struct dma_map_ops ps3_ioc0_dma_ops = {
 arch/powerpc/platforms/ps3/system-bus.c:707:	.alloc = ps3_alloc_coherent,
 arch/powerpc/platforms/ps3/system-bus.c-708-	.free = ps3_free_coherent,
 --
 arch/powerpc/platforms/pseries/ibmebus.c=61=static const struct of_device_id ibmebus_matches[] __initconst = {
 --
 arch/powerpc/platforms/pseries/ibmebus.c-66-
 arch/powerpc/platforms/pseries/ibmebus.c:67:static void *ibmebus_alloc_coherent(struct device *dev,
 arch/powerpc/platforms/pseries/ibmebus.c-68-				    size_t size,
 --
 arch/powerpc/platforms/pseries/ibmebus.c=143=static const struct dma_map_ops ibmebus_dma_ops = {
 arch/powerpc/platforms/pseries/ibmebus.c:144:	.alloc              = ibmebus_alloc_coherent,
 arch/powerpc/platforms/pseries/ibmebus.c-145-	.free               = ibmebus_free_coherent,
 --
 arch/powerpc/platforms/pseries/vio.c=386=static void vio_cmo_balance(struct work_struct *work)
 --
 arch/powerpc/platforms/pseries/vio.c-481-
 arch/powerpc/platforms/pseries/vio.c:482:static void *vio_dma_iommu_alloc_coherent(struct device *dev, size_t size,
 arch/powerpc/platforms/pseries/vio.c-483-					  dma_addr_t *dma_handle, gfp_t flag,
 --
 arch/powerpc/platforms/pseries/vio.c-493-
 arch/powerpc/platforms/pseries/vio.c:494:	ret = iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
 arch/powerpc/platforms/pseries/vio.c-495-				    dma_handle, dev->coherent_dma_mask, flag,
 --
 arch/powerpc/platforms/pseries/vio.c=606=static const struct dma_map_ops vio_dma_mapping_ops = {
 arch/powerpc/platforms/pseries/vio.c:607:	.alloc             = vio_dma_iommu_alloc_coherent,
 arch/powerpc/platforms/pseries/vio.c-608-	.free              = vio_dma_iommu_free_coherent,
 --
 arch/powerpc/sysdev/fsl_rmu.c=543=int fsl_rio_port_write_init(struct fsl_rio_pw *pw)
 --
 arch/powerpc/sysdev/fsl_rmu.c-551-	/* Initialize port write */
 arch/powerpc/sysdev/fsl_rmu.c:552:	pw->port_write_msg.virt = dma_alloc_coherent(pw->dev,
 arch/powerpc/sysdev/fsl_rmu.c-553-					RIO_PW_MSG_SIZE,
 --
 arch/powerpc/sysdev/fsl_rmu.c=720=fsl_open_outb_mbox(struct rio_mport *mport, void *dev_id, int mbox, int entries)
 --
 arch/powerpc/sysdev/fsl_rmu.c-737-		rmu->msg_tx_ring.virt_buffer[i] =
 arch/powerpc/sysdev/fsl_rmu.c:738:			dma_alloc_coherent(priv->dev, RIO_MSG_BUFFER_SIZE,
 arch/powerpc/sysdev/fsl_rmu.c-739-				&rmu->msg_tx_ring.phys_buffer[i], GFP_KERNEL);
 --
 arch/powerpc/sysdev/fsl_rmu.c-754-	/* Initialize outbound message descriptor ring */
 arch/powerpc/sysdev/fsl_rmu.c:755:	rmu->msg_tx_ring.virt = dma_alloc_coherent(priv->dev,
 arch/powerpc/sysdev/fsl_rmu.c-756-						   rmu->msg_tx_ring.size * RIO_MSG_DESC_SIZE,
 --
 arch/powerpc/sysdev/fsl_rmu.c=852=fsl_open_inb_mbox(struct rio_mport *mport, void *dev_id, int mbox, int entries)
 --
 arch/powerpc/sysdev/fsl_rmu.c-871-	/* Initialize inbound message ring */
 arch/powerpc/sysdev/fsl_rmu.c:872:	rmu->msg_rx_ring.virt = dma_alloc_coherent(priv->dev,
 arch/powerpc/sysdev/fsl_rmu.c-873-				rmu->msg_rx_ring.size * RIO_MAX_MSG_SIZE,
 --
 arch/powerpc/sysdev/fsl_rmu.c=1027=int fsl_rio_doorbell_init(struct fsl_rio_dbell *dbell)
 --
 arch/powerpc/sysdev/fsl_rmu.c-1031-	/* Initialize inbound doorbells */
 arch/powerpc/sysdev/fsl_rmu.c:1032:	dbell->dbell_ring.virt = dma_alloc_coherent(dbell->dev, 512 *
 arch/powerpc/sysdev/fsl_rmu.c-1033-		DOORBELL_MESSAGE_SIZE, &dbell->dbell_ring.phys, GFP_KERNEL);
 --
 arch/sh/mm/consistent.c=37=int __init platform_resource_setup_memory(struct platform_device *pdev,
 --
 arch/sh/mm/consistent.c-53-
 arch/sh/mm/consistent.c:54:	buf = dma_alloc_coherent(&pdev->dev, memsize, &dma_handle, GFP_KERNEL);
 arch/sh/mm/consistent.c-55-	if (!buf) {
 --
 arch/sparc/kernel/iommu.c=188=static inline void iommu_free_ctx(struct iommu *iommu, int ctx)
 --
 arch/sparc/kernel/iommu.c-196-
 arch/sparc/kernel/iommu.c:197:static void *dma_4u_alloc_coherent(struct device *dev, size_t size,
 arch/sparc/kernel/iommu.c-198-				   dma_addr_t *dma_addrp, gfp_t gfp,
 --
 arch/sparc/kernel/iommu.c=763=static const struct dma_map_ops sun4u_dma_ops = {
 arch/sparc/kernel/iommu.c:764:	.alloc			= dma_4u_alloc_coherent,
 arch/sparc/kernel/iommu.c-765-	.free			= dma_4u_free_coherent,
 --
 arch/sparc/kernel/pci_sun4v.c=172=static inline long iommu_batch_end(u64 mask)
 --
 arch/sparc/kernel/pci_sun4v.c-180-
 arch/sparc/kernel/pci_sun4v.c:181:static void *dma_4v_alloc_coherent(struct device *dev, size_t size,
 arch/sparc/kernel/pci_sun4v.c-182-				   dma_addr_t *dma_addrp, gfp_t gfp,
 --
 arch/sparc/kernel/pci_sun4v.c=695=static const struct dma_map_ops sun4v_dma_ops = {
 arch/sparc/kernel/pci_sun4v.c:696:	.alloc				= dma_4v_alloc_coherent,
 arch/sparc/kernel/pci_sun4v.c-697-	.free				= dma_4v_free_coherent,
 --
 arch/x86/kernel/amd_gart_64.c=464=static void *
 arch/x86/kernel/amd_gart_64.c:465:gart_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_addr,
 arch/x86/kernel/amd_gart_64.c-466-		    gfp_t flag, unsigned long attrs)
 --
 arch/x86/kernel/amd_gart_64.c=673=static const struct dma_map_ops gart_dma_ops = {
 --
 arch/x86/kernel/amd_gart_64.c-677-	.unmap_phys			= gart_unmap_phys,
 arch/x86/kernel/amd_gart_64.c:678:	.alloc				= gart_alloc_coherent,
 arch/x86/kernel/amd_gart_64.c-679-	.free				= gart_free_coherent,
 --
 drivers/accel/habanalabs/common/command_buffer.c=103=static struct hl_cb *hl_cb_alloc(struct hl_device *hdev, u32 cb_size,
 --
 drivers/accel/habanalabs/common/command_buffer.c-137-	} else if (ctx_id == HL_KERNEL_ASID_ID) {
 drivers/accel/habanalabs/common/command_buffer.c:138:		p = hl_asic_dma_alloc_coherent(hdev, cb_size, &cb->bus_address, GFP_ATOMIC);
 drivers/accel/habanalabs/common/command_buffer.c-139-		if (!p)
 drivers/accel/habanalabs/common/command_buffer.c:140:			p = hl_asic_dma_alloc_coherent(hdev, cb_size, &cb->bus_address, GFP_KERNEL);
 drivers/accel/habanalabs/common/command_buffer.c-141-	} else {
 drivers/accel/habanalabs/common/command_buffer.c:142:		p = hl_asic_dma_alloc_coherent(hdev, cb_size, &cb->bus_address,
 drivers/accel/habanalabs/common/command_buffer.c-143-						GFP_USER | __GFP_ZERO);
 --
 drivers/accel/habanalabs/common/device.c=119=static void *hl_dma_alloc_common(struct hl_device *hdev, size_t size, dma_addr_t *dma_handle,
 --
 drivers/accel/habanalabs/common/device.c-126-	case DMA_ALLOC_COHERENT:
 drivers/accel/habanalabs/common/device.c:127:		ptr = hdev->asic_funcs->asic_dma_alloc_coherent(hdev, size, dma_handle, flag);
 drivers/accel/habanalabs/common/device.c-128-		break;
 --
 drivers/accel/habanalabs/common/device.c=141=static void hl_asic_dma_free_common(struct hl_device *hdev, size_t size, void *cpu_addr,
 --
 drivers/accel/habanalabs/common/device.c-159-
 drivers/accel/habanalabs/common/device.c:160:void *hl_asic_dma_alloc_coherent_caller(struct hl_device *hdev, size_t size, dma_addr_t *dma_handle,
 drivers/accel/habanalabs/common/device.c-161-					gfp_t flag, const char *caller)
 --
 drivers/accel/habanalabs/common/habanalabs.h=117=enum hl_mmu_page_table_location {
 --
 drivers/accel/habanalabs/common/habanalabs.h-149-/* DMA alloc/free wrappers */
 drivers/accel/habanalabs/common/habanalabs.h:150:#define hl_asic_dma_alloc_coherent(hdev, size, dma_handle, flags) \
 drivers/accel/habanalabs/common/habanalabs.h:151:	hl_asic_dma_alloc_coherent_caller(hdev, size, dma_handle, flags, __func__)
 drivers/accel/habanalabs/common/habanalabs.h-152-
 --
 drivers/accel/habanalabs/common/habanalabs.h=1510=struct engines_data {
 --
 drivers/accel/habanalabs/common/habanalabs.h-1538- *             properties.
 drivers/accel/habanalabs/common/habanalabs.h:1539: * @asic_dma_alloc_coherent: Allocate coherent DMA memory by calling
 drivers/accel/habanalabs/common/habanalabs.h:1540: *                           dma_alloc_coherent(). This is ASIC function because
 drivers/accel/habanalabs/common/habanalabs.h-1541- *                           its implementation is not trivial when the driver
 --
 drivers/accel/habanalabs/common/habanalabs.h=1645=struct hl_asic_funcs {
 --
 drivers/accel/habanalabs/common/habanalabs.h-1661-			struct hl_bd *bd);
 drivers/accel/habanalabs/common/habanalabs.h:1662:	void* (*asic_dma_alloc_coherent)(struct hl_device *hdev, size_t size,
 drivers/accel/habanalabs/common/habanalabs.h-1663-					dma_addr_t *dma_handle, gfp_t flag);
 --
 drivers/accel/habanalabs/common/habanalabs.h=3756=void hl_cpu_accessible_dma_pool_free(struct hl_device *hdev, size_t size, void *vaddr);
 drivers/accel/habanalabs/common/habanalabs.h:3757:void *hl_asic_dma_alloc_coherent_caller(struct hl_device *hdev, size_t size, dma_addr_t *dma_handle,
 drivers/accel/habanalabs/common/habanalabs.h-3758-					gfp_t flag, const char *caller);
 --
 drivers/accel/habanalabs/common/hw_queue.c=824=static int ext_and_cpu_queue_init(struct hl_device *hdev, struct hl_hw_queue *q,
 --
 drivers/accel/habanalabs/common/hw_queue.c-832-	else
 drivers/accel/habanalabs/common/hw_queue.c:833:		p = hl_asic_dma_alloc_coherent(hdev, HL_QUEUE_SIZE_IN_BYTES, &q->bus_address,
 drivers/accel/habanalabs/common/hw_queue.c-834-						GFP_KERNEL | __GFP_ZERO);
 --
 drivers/accel/habanalabs/common/hw_queue.c=895=static int hw_queue_init(struct hl_device *hdev, struct hl_hw_queue *q)
 --
 drivers/accel/habanalabs/common/hw_queue.c-898-
 drivers/accel/habanalabs/common/hw_queue.c:899:	p = hl_asic_dma_alloc_coherent(hdev, HL_QUEUE_SIZE_IN_BYTES, &q->bus_address,
 drivers/accel/habanalabs/common/hw_queue.c-900-					GFP_KERNEL | __GFP_ZERO);
 --
 drivers/accel/habanalabs/common/irq.c=596=int hl_cq_init(struct hl_device *hdev, struct hl_cq *q, u32 hw_queue_id)
 --
 drivers/accel/habanalabs/common/irq.c-599-
 drivers/accel/habanalabs/common/irq.c:600:	p = hl_asic_dma_alloc_coherent(hdev, HL_CQ_SIZE_IN_BYTES, &q->bus_address,
 drivers/accel/habanalabs/common/irq.c-601-					GFP_KERNEL | __GFP_ZERO);
 --
 drivers/accel/habanalabs/common/mmu/mmu.c=824=int hl_mmu_hr_init(struct hl_device *hdev, struct hl_mmu_hr_priv *hr_priv, u32 hop_table_size,
 --
 drivers/accel/habanalabs/common/mmu/mmu.c-834-	/*
 drivers/accel/habanalabs/common/mmu/mmu.c:835:	 * we set alloc size as PAGE_SIZE (sine dma_alloc_coherent allocation order/size is
 drivers/accel/habanalabs/common/mmu/mmu.c-836-	 * PAGE_SHIFT/PAGE_SIZE) in order to be able to control the allocations alignment.
 --
 drivers/accel/habanalabs/common/mmu/mmu.c-853-	for (i = 0 ; i < pgt_size ; i += pool_chunk_size) {
 drivers/accel/habanalabs/common/mmu/mmu.c:854:		virt_addr = (uintptr_t) hl_asic_dma_alloc_coherent(hdev, pool_chunk_size,
 drivers/accel/habanalabs/common/mmu/mmu.c-855-									&dma_addr,
 --
 drivers/accel/habanalabs/common/mmu/mmu.c=1064=struct pgt_info *hl_mmu_hr_alloc_hop(struct hl_ctx *ctx, struct hl_mmu_hr_priv *hr_priv,
 --
 drivers/accel/habanalabs/common/mmu/mmu.c-1086-		/* No memory in pool - get some and try again */
 drivers/accel/habanalabs/common/mmu/mmu.c:1087:		virt_addr = hl_asic_dma_alloc_coherent(hdev, SZ_2M, &phys_addr,
 drivers/accel/habanalabs/common/mmu/mmu.c-1088-							GFP_KERNEL | __GFP_ZERO);
 --
 drivers/accel/habanalabs/gaudi/gaudi.c=1049=static int gaudi_init_tpc_mem(struct hl_device *hdev)
 --
 drivers/accel/habanalabs/gaudi/gaudi.c-1070-	fw_size = fw->size;
 drivers/accel/habanalabs/gaudi/gaudi.c:1071:	cpu_addr = hl_asic_dma_alloc_coherent(hdev, fw_size, &dma_handle, GFP_KERNEL | __GFP_ZERO);
 drivers/accel/habanalabs/gaudi/gaudi.c-1072-	if (!cpu_addr) {
 --
 drivers/accel/habanalabs/gaudi/gaudi.c=1693=static int gaudi_alloc_cpu_accessible_dma_mem(struct hl_device *hdev)
 --
 drivers/accel/habanalabs/gaudi/gaudi.c-1708-	for (i = 0 ; i < GAUDI_ALLOC_CPU_MEM_RETRY_CNT ; i++) {
 drivers/accel/habanalabs/gaudi/gaudi.c:1709:		virt_addr_arr[i] = hl_asic_dma_alloc_coherent(hdev, HL_CPU_ACCESSIBLE_MEM_SIZE,
 drivers/accel/habanalabs/gaudi/gaudi.c-1710-								&dma_addr_arr[i],
 --
 drivers/accel/habanalabs/gaudi/gaudi.c=1760=static int gaudi_alloc_internal_qmans_pq_mem(struct hl_device *hdev)
 --
 drivers/accel/habanalabs/gaudi/gaudi.c-1790-
 drivers/accel/habanalabs/gaudi/gaudi.c:1791:		q->pq_kernel_addr = hl_asic_dma_alloc_coherent(hdev, q->pq_size, &q->pq_dma_addr,
 drivers/accel/habanalabs/gaudi/gaudi.c-1792-								GFP_KERNEL | __GFP_ZERO);
 --
 drivers/accel/habanalabs/gaudi/gaudi.c=4162=static int gaudi_mmap(struct hl_device *hdev, struct vm_area_struct *vma,
 --
 drivers/accel/habanalabs/gaudi/gaudi.c-4171-	/*
 drivers/accel/habanalabs/gaudi/gaudi.c:4172:	 * If dma_alloc_coherent() returns a vmalloc address, set VM_MIXEDMAP
 drivers/accel/habanalabs/gaudi/gaudi.c-4173-	 * so vm_insert_page() can handle it safely. Without this, the kernel
 --
 drivers/accel/habanalabs/gaudi/gaudi.c=4539=static void gaudi_pqe_write(struct hl_device *hdev, __le64 *pqe,
 --
 drivers/accel/habanalabs/gaudi/gaudi.c-4548-
 drivers/accel/habanalabs/gaudi/gaudi.c:4549:static void *gaudi_dma_alloc_coherent(struct hl_device *hdev, size_t size,
 drivers/accel/habanalabs/gaudi/gaudi.c-4550-					dma_addr_t *dma_handle, gfp_t flags)
 drivers/accel/habanalabs/gaudi/gaudi.c-4551-{
 drivers/accel/habanalabs/gaudi/gaudi.c:4552:	void *kernel_addr = dma_alloc_coherent(&hdev->pdev->dev, size,
 drivers/accel/habanalabs/gaudi/gaudi.c-4553-						dma_handle, flags);
 --
 drivers/accel/habanalabs/gaudi/gaudi.c=5935=static int gaudi_debugfs_read_dma(struct hl_device *hdev, u64 addr, u32 size,
 --
 drivers/accel/habanalabs/gaudi/gaudi.c-5945-
 drivers/accel/habanalabs/gaudi/gaudi.c:5946:	kernel_addr = hl_asic_dma_alloc_coherent(hdev, SZ_2M, &dma_addr, GFP_KERNEL | __GFP_ZERO);
 drivers/accel/habanalabs/gaudi/gaudi.c-5947-
 --
 drivers/accel/habanalabs/gaudi/gaudi.c=8304=static int gaudi_internal_cb_pool_init(struct hl_device *hdev,
 --
 drivers/accel/habanalabs/gaudi/gaudi.c-8312-
 drivers/accel/habanalabs/gaudi/gaudi.c:8313:	hdev->internal_cb_pool_virt_addr = hl_asic_dma_alloc_coherent(hdev,
 drivers/accel/habanalabs/gaudi/gaudi.c-8314-							HOST_SPACE_INTERNAL_CB_SZ,
 --
 drivers/accel/habanalabs/gaudi/gaudi.c=9130=static const struct hl_asic_funcs gaudi_funcs = {
 --
 drivers/accel/habanalabs/gaudi/gaudi.c-9144-	.pqe_write = gaudi_pqe_write,
 drivers/accel/habanalabs/gaudi/gaudi.c:9145:	.asic_dma_alloc_coherent = gaudi_dma_alloc_coherent,
 drivers/accel/habanalabs/gaudi/gaudi.c-9146-	.asic_dma_free_coherent = gaudi_dma_free_coherent,
 --
 drivers/accel/habanalabs/gaudi2/gaudi2.c=3795=static int gaudi2_alloc_cpu_accessible_dma_mem(struct hl_device *hdev)
 --
 drivers/accel/habanalabs/gaudi2/gaudi2.c-3806-	for (i = 0 ; i < GAUDI2_ALLOC_CPU_MEM_RETRY_CNT ; i++) {
 drivers/accel/habanalabs/gaudi2/gaudi2.c:3807:		virt_addr_arr[i] = hl_asic_dma_alloc_coherent(hdev, HL_CPU_ACCESSIBLE_MEM_SIZE,
 drivers/accel/habanalabs/gaudi2/gaudi2.c-3808-							&dma_addr_arr[i], GFP_KERNEL | __GFP_ZERO);
 --
 drivers/accel/habanalabs/gaudi2/gaudi2.c=6832=static int gaudi2_mmap(struct hl_device *hdev, struct vm_area_struct *vma,
 --
 drivers/accel/habanalabs/gaudi2/gaudi2.c-6841-	/*
 drivers/accel/habanalabs/gaudi2/gaudi2.c:6842:	 * If dma_alloc_coherent() returns a vmalloc address, set VM_MIXEDMAP
 drivers/accel/habanalabs/gaudi2/gaudi2.c-6843-	 * so vm_insert_page() can handle it safely. Without this, the kernel
 --
 drivers/accel/habanalabs/gaudi2/gaudi2.c=7069=static void gaudi2_pqe_write(struct hl_device *hdev, __le64 *pqe, struct hl_bd *bd)
 --
 drivers/accel/habanalabs/gaudi2/gaudi2.c-7077-
 drivers/accel/habanalabs/gaudi2/gaudi2.c:7078:static void *gaudi2_dma_alloc_coherent(struct hl_device *hdev, size_t size,
 drivers/accel/habanalabs/gaudi2/gaudi2.c-7079-				dma_addr_t *dma_handle, gfp_t flags)
 drivers/accel/habanalabs/gaudi2/gaudi2.c-7080-{
 drivers/accel/habanalabs/gaudi2/gaudi2.c:7081:	return dma_alloc_coherent(&hdev->pdev->dev, size, dma_handle, flags);
 drivers/accel/habanalabs/gaudi2/gaudi2.c-7082-}
 --
 drivers/accel/habanalabs/gaudi2/gaudi2.c=11027=static int gaudi2_debugfs_read_dma(struct hl_device *hdev, u64 addr, u32 size, void *blob_addr)
 --
 drivers/accel/habanalabs/gaudi2/gaudi2.c-11043-	/* Allocate buffers for read and for poll */
 drivers/accel/habanalabs/gaudi2/gaudi2.c:11044:	host_mem_virtual_addr = hl_asic_dma_alloc_coherent(hdev, SZ_2M, &host_mem_dma_addr,
 drivers/accel/habanalabs/gaudi2/gaudi2.c-11045-								GFP_KERNEL | __GFP_ZERO);
 --
 drivers/accel/habanalabs/gaudi2/gaudi2.c=11127=static int gaudi2_internal_cb_pool_init(struct hl_device *hdev, struct hl_ctx *ctx)
 --
 drivers/accel/habanalabs/gaudi2/gaudi2.c-11134-
 drivers/accel/habanalabs/gaudi2/gaudi2.c:11135:	hdev->internal_cb_pool_virt_addr = hl_asic_dma_alloc_coherent(hdev,
 drivers/accel/habanalabs/gaudi2/gaudi2.c-11136-								HOST_SPACE_INTERNAL_CB_SZ,
 --
 drivers/accel/habanalabs/gaudi2/gaudi2.c=11905=static const struct hl_asic_funcs gaudi2_funcs = {
 --
 drivers/accel/habanalabs/gaudi2/gaudi2.c-11919-	.pqe_write = gaudi2_pqe_write,
 drivers/accel/habanalabs/gaudi2/gaudi2.c:11920:	.asic_dma_alloc_coherent = gaudi2_dma_alloc_coherent,
 drivers/accel/habanalabs/gaudi2/gaudi2.c-11921-	.asic_dma_free_coherent = gaudi2_dma_free_coherent,
 --
 drivers/accel/habanalabs/goya/goya.c=966=static int goya_sw_init(struct hl_device *hdev)
 --
 drivers/accel/habanalabs/goya/goya.c-993-
 drivers/accel/habanalabs/goya/goya.c:994:	hdev->cpu_accessible_dma_mem = hl_asic_dma_alloc_coherent(hdev, HL_CPU_ACCESSIBLE_MEM_SIZE,
 drivers/accel/habanalabs/goya/goya.c-995-							&hdev->cpu_accessible_dma_address,
 --
 drivers/accel/habanalabs/goya/goya.c=2972=void goya_pqe_write(struct hl_device *hdev, __le64 *pqe, struct hl_bd *bd)
 --
 drivers/accel/habanalabs/goya/goya.c-2977-
 drivers/accel/habanalabs/goya/goya.c:2978:static void *goya_dma_alloc_coherent(struct hl_device *hdev, size_t size,
 drivers/accel/habanalabs/goya/goya.c-2979-					dma_addr_t *dma_handle, gfp_t flags)
 drivers/accel/habanalabs/goya/goya.c-2980-{
 drivers/accel/habanalabs/goya/goya.c:2981:	void *kernel_addr = dma_alloc_coherent(&hdev->pdev->dev, size,
 drivers/accel/habanalabs/goya/goya.c-2982-						dma_handle, flags);
 --
 drivers/accel/habanalabs/goya/goya.c=5431=static const struct hl_asic_funcs goya_funcs = {
 --
 drivers/accel/habanalabs/goya/goya.c-5445-	.pqe_write = goya_pqe_write,
 drivers/accel/habanalabs/goya/goya.c:5446:	.asic_dma_alloc_coherent = goya_dma_alloc_coherent,
 drivers/accel/habanalabs/goya/goya.c-5447-	.asic_dma_free_coherent = goya_dma_free_coherent,
 --
 drivers/accel/ivpu/ivpu_mmu.c=335=static int ivpu_mmu_cdtab_alloc(struct ivpu_device *vdev)
]
]

gemini-3.1-pro-preview

							input: 63002
							output: 43
							thoughts: 63
						

Here's my take on the thought process:

**USB Coherent Memory Allocation - A Quick Refresher**

Okay, so I'm trying to refresh my memory on the nitty-gritty of USB memory management, specifically how we're dealing with coherent memory allocation. Right, *`usb_alloc_coherent`*... is that just a convenience wrapper, or does it actually *do* something significantly different under the hood? It seems like it's a wrapper, but is it just calling *`dma_alloc_coherent`* directly, or is there some intelligent fallback to *`kmalloc`* depending on the platform or requirements?

Time to dig into the source code. Let's start with the obvious places – I'll check *`drivers/usb/core/usb.c`* and, if it's not there, *`drivers/usb/core/buffer.c`*. Those are the logical starting points for anything related to the core USB stack and buffer management, respectively. I'm hoping I can refresh myself on the specific implementation details, especially if it's got some conditional behavior based on system architecture or DMA capabilities. Gotta refresh my memory before I start making assumptions.

map[ContextFile:drivers/usb/core/buffer.c IncludeLines:true Name:usb_alloc_coherent]

map[SourceCode: 983:	/**
 984:	 * usb_alloc_coherent - allocate dma-consistent buffer for URB_NO_xxx_DMA_MAP
 985:	 * @dev: device the buffer will be used with
 986:	 * @size: requested buffer size
 987:	 * @mem_flags: affect whether allocation may block
 988:	 * @dma: used to return DMA address of buffer
 989:	 *
 990:	 * Return: Either null (indicating no buffer could be allocated), or the
 991:	 * cpu-space pointer to a buffer that may be used to perform DMA to the
 992:	 * specified device.  Such cpu-space buffers are returned along with the DMA
 993:	 * address (through the pointer provided).
 994:	 *
 995:	 * Note:
 996:	 * These buffers are used with URB_NO_xxx_DMA_MAP set in urb->transfer_flags
 997:	 * to avoid behaviors like using "DMA bounce buffers", or thrashing IOMMU
 998:	 * hardware during URB completion/resubmit.  The implementation varies between
 999:	 * platforms, depending on details of how DMA will work to this device.
1000:	 * Using these buffers also eliminates cacheline sharing problems on
1001:	 * architectures where CPU caches are not DMA-coherent.  On systems without
1002:	 * bus-snooping caches, these buffers are uncached.
1003:	 *
1004:	 * When the buffer is no longer used, free it with usb_free_coherent().
1005:	 */
1006:	void *usb_alloc_coherent(struct usb_device *dev, size_t size, gfp_t mem_flags,
1007:				 dma_addr_t *dma)
1008:	{
1009:		if (!dev || !dev->bus)
1010:			return NULL;
1011:		return hcd_buffer_alloc(dev->bus, size, mem_flags, dma);
1012:	}
 SourceFile:drivers/usb/core/usb.c]

gemini-3.1-pro-preview

							input: 63936
							output: 44
							thoughts: 12
						

Okay, here's my attempt at summarizing that thought process, keeping in mind I'm speaking to a fellow expert:

**Debugging `hcd_buffer_alloc`**

Right, let's dive in. I need to get into the details of this `hcd_buffer_alloc` function. Something isn't quite right, and the problem likely resides within its logic. My initial hunch is to scrutinize its internal workings. I need to understand exactly how it's allocating, managing, and returning these buffers. Is there a memory leak? Are we exhausting the available pool too quickly? Is a crucial mutex not being handled correctly? I'm going to carefully trace its execution path, paying close attention to any conditional branches or potential race conditions. I'll probably also want to cross-reference this function's implementation against the documentation and any associated header files to ensure I haven't missed a key detail. It's time to dig in and pinpoint the root cause.

map[ContextFile:drivers/usb/core/buffer.c IncludeLines:true Name:hcd_buffer_alloc]

map[SourceCode: 115:	void *hcd_buffer_alloc(
 116:		struct usb_bus		*bus,
 117:		size_t			size,
 118:		gfp_t			mem_flags,
 119:		dma_addr_t		*dma
 120:	)
 121:	{
 122:		struct usb_hcd		*hcd = bus_to_hcd(bus);
 123:		int			i;
 124:	
 125:		if (size == 0)
 126:			return NULL;
 127:	
 128:		if (hcd->localmem_pool)
 129:			return gen_pool_dma_alloc(hcd->localmem_pool, size, dma);
 130:	
 131:		/* some USB hosts just use PIO */
 132:		if (!hcd_uses_dma(hcd)) {
 133:			*dma = ~(dma_addr_t) 0;
 134:			return kmalloc(size, mem_flags);
 135:		}
 136:	
 137:		for (i = 0; i < HCD_BUFFER_POOLS; i++) {
 138:			if (size <= pool_max[i])
 139:				return dma_pool_alloc(hcd->pool[i], mem_flags, dma);
 140:		}
 141:		return dma_alloc_coherent(hcd->self.sysdev, size, dma, mem_flags);
 142:	}
 SourceFile:drivers/usb/core/buffer.c]

gemini-3.1-pro-preview

							input: 64663
							output: 43
							thoughts: 1564
						

**Analyzing the HID Driver Crash**

Okay, so I'm digging into this kernel crash related to the HID driver, specifically, the `mcp2221` driver. The crash occurs when accessing `data[0]` within `mcp2221_raw_event`, and the address points to a `task_struct`, which is obviously wrong. Let's see what's going on here.

The first clue is that the `dummy_hcd` doesn't use DMA, so the driver ends up calling `kmalloc(64, GFP_KERNEL)` to allocate a buffer for USB transactions, which should come from the `kmalloc-64` slab cache. But the crash log is talking about a `task_struct`. How does data end up pointing to a `task_struct`? Let's check `mcp2221_raw_event` again.

Looking into the `mcp2221_raw_event` function, the `data` pointer is actually the `urb->transfer_buffer`, which is the direct output from the USB transfer. Then let's consider the BPF path: if BPF is enabled, `dispatch_hid_bpf_device_event` is called. It checks `hdev->bpf.device_data`, allocates an appropriate size of memory if necessary, and copies the `data` there. I have to think about what is the allocation size?

I see that `__hid_bpf_allocate_data` is called, and `alloc_size` is calculated from `max_report_len`, which comes from the HID report descriptors. If the report descriptor length is 0, then the `alloc_size` would also be 0, and `kzalloc(0)` would return `ZERO_SIZE_PTR`. However, the crash address is not 0x10. It is a valid kernel address. So `alloc_size` must not be 0. So what's going on?

The crucial piece is the syzkaller reproducer. The report descriptor length is explicitly set to 0. This means `hid_parse` might fail and `max_report_len` is zero. But, the crash is still happening, so `mcp2221_raw_event` is still called. This function is called only if `hid_match_report(hid, report)` is true, and this is only true if `report` is non-NULL. But if there are zero reports, `hid_get_report` would return NULL and there's no way the `raw_event` function gets called!

Wait, wait... the reproducer uses `syz_usb_control_io`. This means the report descriptor is provided as a response to a control request, which explains why `hid_parse` might "succeed" if the response is valid. What is the response?

The generic response is 9 bytes: `00 00 08 00 00 00 08 04 82`. This doesn't look like a valid descriptor at all. The first byte is `00`, which, according to HID specs, is an invalid item type. Let's decode it: `00 00 08 00 00 00 08 04 82`. So `0x04` is `Usage Page`. `0x08` is `Usage`. `0x82` is `Input`. Looks like the HID report descriptor is invalid, which caused problems in the parsing stage. Need to check what happens in `hid_parse_report`.

map[ContextFile:drivers/hid/hid-core.c IncludeLines:true Name:hid_parse_report]

map[SourceCode: 995:	/**
 996:	 * hid_parse_report - parse device report
 997:	 *
 998:	 * @hid: hid device
 999:	 * @start: report start
1000:	 * @size: report size
1001:	 *
1002:	 * Allocate the device report as read by the bus driver. This function should
1003:	 * only be called from parse() in ll drivers.
1004:	 */
1005:	int hid_parse_report(struct hid_device *hid, const __u8 *start, unsigned size)
1006:	{
1007:		hid->dev_rdesc = kmemdup(start, size, GFP_KERNEL);
1008:		if (!hid->dev_rdesc)
1009:			return -ENOMEM;
1010:		hid->dev_rsize = size;
1011:		return 0;
1012:	}
 SourceFile:drivers/hid/hid-core.c]

gemini-3.1-pro-preview

							input: 67345
							output: 43
							thoughts: 37
						

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

**Unpacking the HID Report Descriptor Process**

Alright, let me just run through this again in my head. So, `hid_parse_report`... ah, right, it's the *descriptor* that's getting stored. It's not *actually* where the heavy lifting of interpretation happens, no, no. That initial parse just gets the data ready.

Now, where does the real work begin? Ah, yes, that's it! It's when `hid_device_probe` kicks in and calls `hid_open_report`. That's the critical juncture. That's where we get down to brass tacks: probing the device, and getting ready to dive into the data! `hid_open_report` must be the point where the descriptor gets used to do the actual mapping, decoding, and all that good stuff to figure out exactly what the device is going to be sending. Got it. That's the correct flow.

map[ContextFile:drivers/hid/hid-core.c IncludeLines:true Name:hid_open_report]

map[SourceCode:1332:	/**
1333:	 * hid_open_report - open a driver-specific device report
1334:	 *
1335:	 * @device: hid device
1336:	 *
1337:	 * Parse a report description into a hid_device structure. Reports are
1338:	 * enumerated, fields are attached to these reports.
1339:	 * 0 returned on success, otherwise nonzero error value.
1340:	 *
1341:	 * This function (or the equivalent hid_parse() macro) should only be
1342:	 * called from probe() in drivers, before starting the device.
1343:	 */
1344:	int hid_open_report(struct hid_device *device)
1345:	{
1346:		unsigned int size;
1347:		const u8 *start;
1348:		int error;
1349:	
1350:		if (WARN_ON(device->status & HID_STAT_PARSED))
1351:			return -EBUSY;
1352:	
1353:		start = device->bpf_rdesc;
1354:		if (WARN_ON(!start))
1355:			return -ENODEV;
1356:		size = device->bpf_rsize;
1357:	
1358:		if (device->driver->report_fixup) {
1359:			/*
1360:			 * device->driver->report_fixup() needs to work
1361:			 * on a copy of our report descriptor so it can
1362:			 * change it.
1363:			 */
1364:			u8 *buf __free(kfree) = kmemdup(start, size, GFP_KERNEL);
1365:	
1366:			if (!buf)
1367:				return -ENOMEM;
1368:	
1369:			start = device->driver->report_fixup(device, buf, &size);
1370:	
1371:			/*
1372:			 * The second kmemdup is required in case report_fixup() returns
1373:			 * a static read-only memory, but we have no idea if that memory
1374:			 * needs to be cleaned up or not at the end.
1375:			 */
1376:			start = kmemdup(start, size, GFP_KERNEL);
1377:			if (!start)
1378:				return -ENOMEM;
1379:		}
1380:	
1381:		device->rdesc = start;
1382:		device->rsize = size;
1383:	
1384:		error = hid_parse_collections(device);
1385:		if (error) {
1386:			hid_close_report(device);
1387:			return error;
1388:		}
1389:	
1390:		return 0;
1391:	}
 SourceFile:drivers/hid/hid-core.c]

gemini-3.1-pro-preview

							input: 68487
							output: 51
							thoughts: 33
						

Here's my thought process, as if I were analyzing that code:

**Diving into the Event Handling**

Okay, so I see `mcp2221_raw_event` being called. That's the signal to dig in. I need to understand what's happening at this low level. First, let's refresh our understanding of where this event comes from and what triggered it. I'm going to jump straight to the source and scrutinize `mcp2221_probe`. That's where it all begins, it seems, in order to get the full picture. I need to figure out what events may occur and under what conditions.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp2221_probe]

map[SourceCode:1237:	static int mcp2221_probe(struct hid_device *hdev,
1238:						const struct hid_device_id *id)
1239:	{
1240:		int ret;
1241:		struct mcp2221 *mcp;
1242:	
1243:		mcp = devm_kzalloc(&hdev->dev, sizeof(*mcp), GFP_KERNEL);
1244:		if (!mcp)
1245:			return -ENOMEM;
1246:	
1247:		ret = hid_parse(hdev);
1248:		if (ret) {
1249:			hid_err(hdev, "can't parse reports\n");
1250:			return ret;
1251:		}
1252:	
1253:		/*
1254:		 * This driver uses the .raw_event callback and therefore does not need any
1255:		 * HID_CONNECT_xxx flags.
1256:		 */
1257:		ret = hid_hw_start(hdev, 0);
1258:		if (ret) {
1259:			hid_err(hdev, "can't start hardware\n");
1260:			return ret;
1261:		}
1262:	
1263:		hid_info(hdev, "USB HID v%x.%02x Device [%s] on %s\n", hdev->version >> 8,
1264:				hdev->version & 0xff, hdev->name, hdev->phys);
1265:	
1266:		ret = hid_hw_open(hdev);
1267:		if (ret) {
1268:			hid_err(hdev, "can't open device\n");
1269:			hid_hw_stop(hdev);
1270:			return ret;
1271:		}
1272:	
1273:		mutex_init(&mcp->lock);
1274:		init_completion(&mcp->wait_in_report);
1275:		hid_set_drvdata(hdev, mcp);
1276:		mcp->hdev = hdev;
1277:	
1278:		ret = devm_add_action_or_reset(&hdev->dev, mcp2221_hid_unregister, hdev);
1279:		if (ret)
1280:			return ret;
1281:	
1282:		hid_device_io_start(hdev);
1283:	
1284:		/* Set I2C bus clock diviser */
1285:		if (i2c_clk_freq > 400)
1286:			i2c_clk_freq = 400;
1287:		if (i2c_clk_freq < 50)
1288:			i2c_clk_freq = 50;
1289:		mcp->cur_i2c_clk_div = (12000000 / (i2c_clk_freq * 1000)) - 3;
1290:		ret = mcp_set_i2c_speed(mcp);
1291:		if (ret) {
1292:			hid_err(hdev, "can't set i2c speed: %d\n", ret);
1293:			return ret;
1294:		}
1295:	
1296:		mcp->adapter.owner = THIS_MODULE;
1297:		mcp->adapter.class = I2C_CLASS_HWMON;
1298:		mcp->adapter.algo = &mcp_i2c_algo;
1299:		mcp->adapter.retries = 1;
1300:		mcp->adapter.dev.parent = &hdev->dev;
1301:		ACPI_COMPANION_SET(&mcp->adapter.dev, ACPI_COMPANION(hdev->dev.parent));
1302:		snprintf(mcp->adapter.name, sizeof(mcp->adapter.name),
1303:				"MCP2221 usb-i2c bridge");
1304:	
1305:		i2c_set_adapdata(&mcp->adapter, mcp);
1306:		ret = devm_i2c_add_adapter(&hdev->dev, &mcp->adapter);
1307:		if (ret) {
1308:			hid_err(hdev, "can't add usb-i2c adapter: %d\n", ret);
1309:			return ret;
1310:		}
1311:	
1312:	#if IS_REACHABLE(CONFIG_GPIOLIB)
1313:		/* Setup GPIO chip */
1314:		mcp->gc = devm_kzalloc(&hdev->dev, sizeof(*mcp->gc), GFP_KERNEL);
1315:		if (!mcp->gc)
1316:			return -ENOMEM;
1317:	
1318:		mcp->gc->label = "mcp2221_gpio";
1319:		mcp->gc->direction_input = mcp_gpio_direction_input;
1320:		mcp->gc->direction_output = mcp_gpio_direction_output;
1321:		mcp->gc->get_direction = mcp_gpio_get_direction;
1322:		mcp->gc->set = mcp_gpio_set;
1323:		mcp->gc->get = mcp_gpio_get;
1324:		mcp->gc->ngpio = MCP_NGPIO;
1325:		mcp->gc->base = -1;
1326:		mcp->gc->can_sleep = 1;
1327:		mcp->gc->parent = &hdev->dev;
1328:	
1329:		ret = devm_gpiochip_add_data(&hdev->dev, mcp->gc, mcp);
1330:		if (ret)
1331:			return ret;
1332:	
1333:		mcp2221_check_gpio_pinfunc(mcp);
1334:	#endif
1335:	
1336:	#if IS_REACHABLE(CONFIG_IIO)
1337:		if (!gpio_mode_enforce) {
1338:			INIT_DELAYED_WORK(&mcp->init_work, mcp_init_work);
1339:			schedule_delayed_work(&mcp->init_work, msecs_to_jiffies(100));
1340:		}
1341:	#endif
1342:	
1343:		return 0;
1344:	}
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 70576
							output: 49
							thoughts: 1472
						

**Analyzing the MCP2221 Driver Vulnerability**

Okay, let's break this down step by step. I'm looking at the `mcp2221_probe` function, which sets things in motion. It calls `hid_parse`, then `hid_hw_start`, `hid_hw_open`, and finally `mcp_set_i2c_speed`. `mcp_set_i2c_speed` sends a command to the device, specifically setting the I2C speed. This triggers the data transfer through `mcp_send_data_req_status`, which uses `hid_hw_output_report` to send the command and waits for a response via `wait_for_completion_timeout`.  The key thing is, if the device sends back an "IN" report, `mcp2221_raw_event` gets called to handle it.

Now, here's where it gets interesting. The syzkaller reproducer sends a single byte (0x50, `MCP2221_GPIO_SET`) on the IN endpoint 0x81. This is the crux of the issue.  In `mcp2221_raw_event`, it processes the incoming data.  Critically, the code checks `data[1]` within a switch statement based on the value of `data[0]` (which is 0x50 in this case). The size of the incoming data buffer is only 1 byte. The code accesses `data[1]`, which is an out-of-bounds access.

However, the buffer `data` is allocated with `kmalloc(64)`.  So, even though the reproducer sends only one byte, the `urb->transfer_buffer` (which `data` points to) is 64 bytes long, meaning accessing `data[1]` is still within allocated memory, which should not cause any issue.

The crash report reveals it's a slab-out-of-bounds read and mentions the crash is on an object belonging to the `task_struct` cache. The address causing the crash is a long way from the beginning of the `task_struct` object. This is strange!

The critical point is that I'm realizing `mcp->gp_idx` is uninitialized. The variable is part of struct `mcp2221`, and it's set in the `mcp_gpio_set` and `mcp_gpio_get` functions. *But*, if `mcp2221_raw_event` is called *before* either of those functions has been called, `mcp->gp_idx` will have its default value. Since `mcp` is allocated by `devm_kzalloc`, `gp_idx` is initialized to 0.

So, in the vulnerable code:

```c
				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
					(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
```

`mcp->gp_idx` is 0.  `data[mcp->gp_idx]` is `data[0]` is fine. But `data[mcp->gp_idx - 1]` becomes `data[-1]`!  Even if the memory is mapped, this is almost certainly an out-of-bounds access. This explains why KASAN reported an issue related to `task_struct`, even though the buffer itself is allocated in `kmalloc-64` cache.  The code is reading outside of the intended bounds of the `data` buffer, and the result of that read is used in the condition. The crash isn't happening in the `data` buffer, but it's *influenced* by the `data` content. The out of bounds read of `-1` in `data` somehow lead to memory corruption, possibly overwriting parts of the `task_struct` object. This confirms the vulnerability: an uninitialized variable leads to an out-of-bounds read. This is a very interesting find.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp2221]

map[SourceCode: 117:	/*
 118:	 * There is no way to distinguish responses. Therefore next command
 119:	 * is sent only after response to previous has been received. Mutex
 120:	 * lock is used for this purpose mainly.
 121:	 */
 122:	struct mcp2221 {
 123:		struct hid_device *hdev;
 124:		struct i2c_adapter adapter;
 125:		struct mutex lock;
 126:		struct completion wait_in_report;
 127:		struct delayed_work init_work;
 128:		u8 *rxbuf;
 129:		u8 txbuf[64];
 130:		int rxbuf_idx;
 131:		int rxbuf_size;
 132:		int status;
 133:		u8 cur_i2c_clk_div;
 134:		struct gpio_chip *gc;
 135:		u8 gp_idx;
 136:		u8 gpio_dir;
 137:		u8 mode[4];
 138:	#if IS_REACHABLE(CONFIG_IIO)
 139:		struct iio_chan_spec iio_channels[3];
 140:		u16 adc_values[3];
 141:		u8 adc_scale;
 142:		u8 dac_value;
 143:		u16 dac_scale;
 144:	#endif
 145:	};
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 73448
							output: 48
							thoughts: 401
						

**Analyzing a Potential Out-of-Bounds Memory Access**

Okay, so I'm looking at this code and immediately see a `u8 gp_idx;` declaration. The gears start turning. If `mcp->gp_idx` is zero, subtracting one results in `255`, right? And if we're dealing with a `u8 *data`, then `data[255]` is being accessed!  My initial alarm bells are going off.

Now, let's step back.  The `data` pointer is connected to `urb->transfer_buffer`, which, as I recall, is allocated with `kmalloc(64)`.  That means accessing `data[255]` would put us 191 bytes past the end of the 64-byte allocation.  Definitely a problem.

Wait a second, if that allocation uses `kmalloc(64)`, it comes from the `kmalloc-64` cache. Why is KASAN reporting that the memory belongs to `task_struct`? Something is not quite right.

Ah, I see... `data` might *not* actually be `urb->transfer_buffer`. I need to track down how `data` gets assigned. Let me examine `__hid_input_report`.

```c
2136:   data = dispatch_hid_bpf_device_event(hid, type, data, &bufsize, &size, interrupt,
2137:   source, from_bpf);
```

Okay, I see it. If BPF isn't enabled, then `data` is `urb->transfer_buffer`. But, what if BPF *is* enabled? What is that `dispatch_hid_bpf_device_event` function doing? Where does `data` come from? Is it possible that `data` could point to something other than `urb->transfer_buffer`?  Could it be `report->field[0]->value`? No, the code is passing `data` to `__hid_input_report`.

I'm getting ahead of myself, let's go back and examine `hid_irq_in` again.

```c
286:   hid_safe_input_report(urb->context, HID_INPUT_REPORT,
287:       urb->transfer_buffer, urb->transfer_buffer_length,
288:       urb->actual_length, 1);
```

Ah, that's it! `hid_safe_input_report` looks like the place where the data is actually used. Is it a macro? A function? I need to check the definition to figure out what it does.

map[ContextFile:drivers/hid/usbhid/hid-core.c IncludeLines:true Name:hid_safe_input_report]

map[SourceCode:2195:	/**
2196:	 * hid_safe_input_report - report data from lower layer (usb, bt...)
2197:	 *
2198:	 * @hid: hid device
2199:	 * @type: HID report type (HID_*_REPORT)
2200:	 * @data: report contents
2201:	 * @bufsize: allocated size of the data buffer
2202:	 * @size: useful size of data parameter
2203:	 * @interrupt: distinguish between interrupt and control transfers
2204:	 *
2205:	 * This is data entry for lower layers.
2206:	 * Please use this function instead of the non safe version because we provide
2207:	 * here the size of the buffer, allowing hid-core to make smarter decisions
2208:	 * regarding the incoming buffer.
2209:	 */
2210:	int hid_safe_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data,
2211:				  size_t bufsize, u32 size, int interrupt)
2212:	{
2213:		return __hid_input_report(hid, type, data, bufsize, size, interrupt, 0,
2214:					  false, /* from_bpf */
2215:					  false /* lock_already_taken */);
2216:	}
 SourceFile:drivers/hid/hid-core.c]

gemini-3.1-pro-preview

							input: 74881
							output: 51
							thoughts: 3078
						

**Analyzing a KASAN Slab-Out-of-Bounds Error in USB HID Handling**

Okay, so I'm digging into this KASAN report, trying to understand why we're seeing a slab-out-of-bounds error. The report says the bad access is in an area that the kernel thinks belongs to a `task_struct`, but the code *should* be accessing `urb->transfer_buffer`. I'm going through the allocation flow here. Initially, it looked like `data` was just a pointer to `urb->transfer_buffer`, which is allocated with `kmalloc(64)`. That should be in the `kmalloc-64` cache. But the KASAN report specifically points to a location that's part of a `task_struct` object. That makes no sense.

I then revisited the code where `usbhid->bufsize` is calculated. It seemed that if `usbhid->bufsize` gets a value of zero (even though it's initialized to `HID_MIN_BUFFER_SIZE`), the allocated buffer size could be zero, but that's impossible because it's initialized to at least 64. However, I notice that the problematic address is the last byte of a page that is part of an order-3 page for `task_struct` cache. This is strange!

The KASAN report says the buggy address is the last byte of a page, but that page was allocated via `alloc_task_struct_node` and its type is `f5(slab)`. So the page belongs to the `task_struct` cache. How can I possibly write into the end of a `task_struct` object if the code is actually dealing with the USB buffer? The KASAN report is pretty clear about the allocation, but `data` should be a `urb->transfer_buffer` which is allocated through `usb_alloc_coherent`. This is a DMA-like allocation. But wait! `dummy_hcd` does NOT use DMA, which means it calls `kmalloc`! So the allocation method depends on this.

It turns out that `dummy_hcd` uses PIO and calls `kmalloc` internally. So it's still possible that the `kmalloc(64)` call returns an address within an order-3 page of the `task_struct` slab.

I need to investigate the report descriptor. The reproducer sets `wDescriptorLength` to 0. But then a descriptor is provided via control transfer. The contents seem invalid. The report descriptor is `00 00 08 00 00 00 08 04 82`.

If this is the report descriptor, let's parse the descriptor. If `00` is repeated, then each one is an `Input`, since there are no report sizes and counts specified.
The size is zero. The report descriptor looks like a sequence of `Input` and `Output` items, not valid at all. This means report size is zero! Then, `usbhid->bufsize` defaults to 64, and the memory allocated is also 64.

But if it's 64, why is there an out-of-bounds access?

Maybe the actual `data` passed to `hid_safe_input_report` and later to the functions like `mcp2221_raw_event` is NOT `urb->transfer_buffer`. But in `hid_irq_in`, `urb->transfer_buffer` is the pointer. I still can't see how `urb->transfer_buffer` can be the problem here. I check if `hcd_uses_dma` is used. Aha! `dummy_hcd` does *not* use DMA.

I need to think more about this. Maybe there is a BPF related memory corruption, and the BPF code is returning the wrong pointer. Let me look at that code path.

map[ContextFile:drivers/usb/gadget/udc/dummy_hcd.c IncludeLines:true Name:dummy_hcd_probe]

map[SourceCode:2683:	static int dummy_hcd_probe(struct platform_device *pdev)
2684:	{
2685:		struct dummy		*dum;
2686:		struct usb_hcd		*hs_hcd;
2687:		struct usb_hcd		*ss_hcd;
2688:		int			retval;
2689:	
2690:		dev_info(&pdev->dev, "%s, driver " DRIVER_VERSION "\n", driver_desc);
2691:		dum = *((void **)dev_get_platdata(&pdev->dev));
2692:	
2693:		if (mod_data.is_super_speed)
2694:			dummy_hcd.flags = HCD_USB3 | HCD_SHARED;
2695:		else if (mod_data.is_high_speed)
2696:			dummy_hcd.flags = HCD_USB2;
2697:		else
2698:			dummy_hcd.flags = HCD_USB11;
2699:		hs_hcd = usb_create_hcd(&dummy_hcd, &pdev->dev, dev_name(&pdev->dev));
2700:		if (!hs_hcd)
2701:			return -ENOMEM;
2702:		hs_hcd->has_tt = 1;
2703:	
2704:		retval = usb_add_hcd(hs_hcd, 0, 0);
2705:		if (retval)
2706:			goto put_usb2_hcd;
2707:	
2708:		if (mod_data.is_super_speed) {
2709:			ss_hcd = usb_create_shared_hcd(&dummy_hcd, &pdev->dev,
2710:						dev_name(&pdev->dev), hs_hcd);
2711:			if (!ss_hcd) {
2712:				retval = -ENOMEM;
2713:				goto dealloc_usb2_hcd;
2714:			}
2715:	
2716:			retval = usb_add_hcd(ss_hcd, 0, 0);
2717:			if (retval)
2718:				goto put_usb3_hcd;
2719:		}
2720:		return 0;
2721:	
2722:	put_usb3_hcd:
2723:		usb_put_hcd(ss_hcd);
2724:	dealloc_usb2_hcd:
2725:		usb_remove_hcd(hs_hcd);
2726:	put_usb2_hcd:
2727:		usb_put_hcd(hs_hcd);
2728:		dum->hs_hcd = dum->ss_hcd = NULL;
2729:		return retval;
2730:	}
 SourceFile:drivers/usb/gadget/udc/dummy_hcd.c]

gemini-3.1-pro-preview

							input: 79684
							output: 48
							thoughts: 340
						

**Debugging a USB DMA Allocation Issue**

Okay, hold on a second. I just realized something critical: `dummy_hcd` *doesn't* actually set `hcd->self.uses_dma` to `1`. That means `hcd_uses_dma(hcd)` is evaluating to false, right? Which means, then, that `hcd_buffer_alloc` is using a standard `kmalloc(size, mem_flags)` allocation. If the size requested is, say, 64 bytes – as seems likely in this scenario – it's just a `kmalloc(64)`.

So, the next question is... why is KASAN reporting that the page belongs to `task_struct`? That makes no sense.

Okay, let's look at that reproducer more closely. I should've known better and focused on the reproducer earlier.

```c
//  syz_usb_ep_write arguments: [
//    fd: fd_usb (resource)
//    ep: int8 = 0x81 (1 bytes)
//    len: len = 0x1 (8 bytes)
//    data: ptr[in, buffer] {
//      buffer: {50 62 7b} (length 0x3)
//    }
//  ]
memcpy((void*)0x200000000040, "Pb{", 3);
syz_usb_ep_write(/*fd=*/r[0], /*ep=*/0x81, /*len=*/1, /*data=*/0x200000000040);
```

Aha! `syz_usb_ep_write` is writing to the endpoint! The whole time I was trying to figure out how this *dummy* hcd deals with data transfers from the gadget to the host. Now that I have it, I can use the reproducer to figure out the problem. And I now know `dummy_timer` is handling the transfer... Got it! I'm probably going down the wrong path, and now I need to figure out what's causing the mismatch. I need to focus on how the data is being handled within the `dummy_hcd` implementation, given it's not using DMA. This simplifies the issue a bit.

map[ContextFile:drivers/usb/gadget/udc/dummy_hcd.c IncludeLines:true Name:dummy_timer]

map[SourceCode:1793:	/*
1794:	 * Drive both sides of the transfers; looks like irq handlers to both
1795:	 * drivers except that the callbacks are invoked from soft interrupt
1796:	 * context.
1797:	 */
1798:	static enum hrtimer_restart dummy_timer(struct hrtimer *t)
1799:	{
1800:		struct dummy_hcd	*dum_hcd = timer_container_of(dum_hcd, t,
1801:								      timer);
1802:		struct dummy		*dum = dum_hcd->dum;
1803:		struct urbp		*urbp, *tmp;
1804:		unsigned long		flags;
1805:		int			limit, total;
1806:		int			i;
1807:	
1808:		/* simplistic model for one frame's bandwidth */
1809:		/* FIXME: account for transaction and packet overhead */
1810:		switch (dum->gadget.speed) {
1811:		case USB_SPEED_LOW:
1812:			total = 8/*bytes*/ * 12/*packets*/;
1813:			break;
1814:		case USB_SPEED_FULL:
1815:			total = 64/*bytes*/ * 19/*packets*/;
1816:			break;
1817:		case USB_SPEED_HIGH:
1818:			total = 512/*bytes*/ * 13/*packets*/ * 8/*uframes*/;
1819:			break;
1820:		case USB_SPEED_SUPER:
1821:			/* Bus speed is 500000 bytes/ms, so use a little less */
1822:			total = 490000;
1823:			break;
1824:		default:	/* Can't happen */
1825:			dev_err(dummy_dev(dum_hcd), "bogus device speed\n");
1826:			total = 0;
1827:			break;
1828:		}
1829:	
1830:		/* look at each urb queued by the host side driver */
1831:		spin_lock_irqsave(&dum->lock, flags);
1832:		dum_hcd->timer_pending = 0;
1833:	
1834:		if (!dum_hcd->udev) {
1835:			dev_err(dummy_dev(dum_hcd),
1836:					"timer fired with no URBs pending?\n");
1837:			spin_unlock_irqrestore(&dum->lock, flags);
1838:			return HRTIMER_NORESTART;
1839:		}
1840:		dum_hcd->next_frame_urbp = NULL;
1841:	
1842:		for (i = 0; i < DUMMY_ENDPOINTS; i++) {
1843:			if (!ep_info[i].name)
1844:				break;
1845:			dum->ep[i].already_seen = 0;
1846:		}
1847:	
1848:	restart:
1849:		list_for_each_entry_safe(urbp, tmp, &dum_hcd->urbp_list, urbp_list) {
1850:			struct urb		*urb;
1851:			struct dummy_request	*req;
1852:			u8			address;
1853:			struct dummy_ep		*ep = NULL;
1854:			int			status = -EINPROGRESS;
1855:	
1856:			/* stop when we reach URBs queued after the timer interrupt */
1857:			if (urbp == dum_hcd->next_frame_urbp)
1858:				break;
1859:	
1860:			urb = urbp->urb;
1861:			if (urb->unlinked)
1862:				goto return_urb;
1863:			else if (dum_hcd->rh_state != DUMMY_RH_RUNNING)
1864:				continue;
1865:	
1866:			/* Used up this frame's bandwidth? */
1867:			if (total <= 0)
1868:				continue;
1869:	
1870:			/* find the gadget's ep for this request (if configured) */
1871:			address = usb_pipeendpoint (urb->pipe);
1872:			if (usb_urb_dir_in(urb))
1873:				address |= USB_DIR_IN;
1874:			ep = find_endpoint(dum, address);
1875:			if (!ep) {
1876:				/* set_configuration() disagreement */
1877:				dev_dbg(dummy_dev(dum_hcd),
1878:					"no ep configured for urb %p\n",
1879:					urb);
1880:				status = -EPROTO;
1881:				goto return_urb;
1882:			}
1883:	
1884:			if (ep->already_seen)
1885:				continue;
1886:			ep->already_seen = 1;
1887:			if (ep == &dum->ep[0] && urb->error_count) {
1888:				ep->setup_stage = 1;	/* a new urb */
1889:				urb->error_count = 0;
1890:			}
1891:			if (ep->halted && !ep->setup_stage) {
1892:				/* NOTE: must not be iso! */
1893:				dev_dbg(dummy_dev(dum_hcd), "ep %s halted, urb %p\n",
1894:						ep->ep.name, urb);
1895:				status = -EPIPE;
1896:				goto return_urb;
1897:			}
1898:			/* FIXME make sure both ends agree on maxpacket */
1899:	
1900:			/* handle control requests */
1901:			if (ep == &dum->ep[0] && ep->setup_stage) {
1902:				struct usb_ctrlrequest		setup;
1903:				int				value;
1904:	
1905:				setup = *(struct usb_ctrlrequest *) urb->setup_packet;
1906:				/* paranoia, in case of stale queued data */
1907:				list_for_each_entry(req, &ep->queue, queue) {
1908:					list_del_init(&req->queue);
1909:					req->req.status = -EOVERFLOW;
1910:					dev_dbg(udc_dev(dum), "stale req = %p\n",
1911:							req);
1912:	
1913:					spin_unlock(&dum->lock);
1914:					usb_gadget_giveback_request(&ep->ep, &req->req);
1915:					spin_lock(&dum->lock);
1916:					ep->already_seen = 0;
1917:					goto restart;
1918:				}
1919:	
1920:				/* gadget driver never sees set_address or operations
1921:				 * on standard feature flags.  some hardware doesn't
1922:				 * even expose them.
1923:				 */
1924:				ep->last_io = jiffies;
1925:				ep->setup_stage = 0;
1926:				ep->halted = 0;
1927:	
1928:				value = handle_control_request(dum_hcd, urb, &setup,
1929:							       &status);
1930:	
1931:				/* gadget driver handles all other requests.  block
1932:				 * until setup() returns; no reentrancy issues etc.
1933:				 */
1934:				if (value > 0) {
1935:					++dum->callback_usage;
1936:					spin_unlock(&dum->lock);
1937:					value = dum->driver->setup(&dum->gadget,
1938:							&setup);
1939:					spin_lock(&dum->lock);
1940:					--dum->callback_usage;
1941:	
1942:					if (value >= 0) {
1943:						/* no delays (max 64KB data stage) */
1944:						limit = 64*1024;
1945:						goto treat_control_like_bulk;
1946:					}
1947:					/* error, see below */
1948:				}
1949:	
1950:				if (value < 0) {
1951:					if (value != -EOPNOTSUPP)
1952:						dev_dbg(udc_dev(dum),
1953:							"setup --> %d\n",
1954:							value);
1955:					status = -EPIPE;
1956:					urb->actual_length = 0;
1957:				}
1958:	
1959:				goto return_urb;
1960:			}
1961:	
1962:			/* non-control requests */
1963:			limit = total;
1964:			switch (usb_pipetype(urb->pipe)) {
1965:			case PIPE_ISOCHRONOUS:
1966:				/*
1967:				 * We don't support isochronous.  But if we did,
1968:				 * here are some of the issues we'd have to face:
1969:				 *
1970:				 * Is it urb->interval since the last xfer?
1971:				 * Use urb->iso_frame_desc[i].
1972:				 * Complete whether or not ep has requests queued.
1973:				 * Report random errors, to debug drivers.
1974:				 */
1975:				limit = max(limit, periodic_bytes(dum, ep));
1976:				status = -EINVAL;	/* fail all xfers */
1977:				break;
1978:	
1979:			case PIPE_INTERRUPT:
1980:				/* FIXME is it urb->interval since the last xfer?
1981:				 * this almost certainly polls too fast.
1982:				 */
1983:				limit = max(limit, periodic_bytes(dum, ep));
1984:				fallthrough;
1985:	
1986:			default:
1987:	treat_control_like_bulk:
1988:				ep->last_io = jiffies;
1989:				total -= transfer(dum_hcd, urb, ep, limit, &status);
1990:				break;
1991:			}
1992:	
1993:			/* incomplete transfer? */
1994:			if (status == -EINPROGRESS)
1995:				continue;
1996:	
1997:	return_urb:
1998:			list_del(&urbp->urbp_list);
1999:			kfree(urbp);
2000:			if (ep)
2001:				ep->already_seen = ep->setup_stage = 0;
2002:	
2003:			usb_hcd_unlink_urb_from_ep(dummy_hcd_to_hcd(dum_hcd), urb);
2004:			spin_unlock(&dum->lock);
2005:			usb_hcd_giveback_urb(dummy_hcd_to_hcd(dum_hcd), urb, status);
2006:			spin_lock(&dum->lock);
2007:	
2008:			goto restart;
2009:		}
2010:	
2011:		if (list_empty(&dum_hcd->urbp_list)) {
2012:			usb_put_dev(dum_hcd->udev);
2013:			dum_hcd->udev = NULL;
2014:		} else if (!dum_hcd->timer_pending &&
2015:				dum_hcd->rh_state == DUMMY_RH_RUNNING) {
2016:			/* want a 1 msec delay here */
2017:			dum_hcd->timer_pending = 1;
2018:			hrtimer_start(&dum_hcd->timer, ns_to_ktime(DUMMY_TIMER_INT_NSECS),
2019:					HRTIMER_MODE_REL_SOFT);
2020:		}
2021:	
2022:		spin_unlock_irqrestore(&dum->lock, flags);
2023:	
2024:		return HRTIMER_NORESTART;
2025:	}
 SourceFile:drivers/usb/gadget/udc/dummy_hcd.c]

gemini-3.1-pro-preview

							input: 84082
							output: 43
							thoughts: 1808
						

**Analyzing the HID Report Descriptor: A Deep Dive**

Okay, so I'm tracing through this USB HID driver and I'm really digging into how the data transfer works in this `dummy_hcd` scenario, trying to understand why this reproducer causes a crash, or doesn't. My focus is on the `transfer` function within the `dummy_hcd.c` file and how it interacts with the HID report descriptor.

The critical path: data is copied from `req->req.buf` to `urb->transfer_buffer`. I know the latter is allocated via `usb_alloc_coherent`. However, there's a potential wrinkle, if it *isn't*. I need to account for all possible allocations, and `usbhid_start` is the right place to look. Here, `usbhid->inbuf` is allocated. Let's see... `usbhid->inbuf` comes from `usb_alloc_coherent` and its size is determined by `usbhid->bufsize`. This is important, as the size is compared to `insize`, which in turn, comes from `hid_find_max_report`. If `insize` is zero, there's a problem, because it means the transfer length is zero. Zero length transfers from `dummy_hcd` would bypass the `mcp2221_raw_event` handler, which is not what's happening in this case.

But the reproducer *does* write a byte...

The problem must be that `urb->transfer_buffer_length` is > 0.

So, let's go back and examine `transfer` in `dummy_hcd.c`. I can see how `host_len` and `dev_len` are calculated using `urb->transfer_buffer_length`, but this calculation is what should determine how much data is actually transferred. If `host_len` is zero, so is `len`, and therefore, `memcpy` copies nothing, and we get a zero `urb->actual_length`. That bypasses `mcp2221_raw_event`

If `insize` is zero, the code goes down the branch where nothing gets transferred. The crash must occur when there is data.

So, since it crashes, `size` must be greater than 0, implying we're not dealing with a zero-length transfer. I need to understand how `insize` becomes greater than zero.

Right, `insize` is determined by `hid_find_max_report`. Time to look at the report descriptor again!

I examine the report descriptor: `00 00 08 00 00 00 08 04 82`. This looks strange.

The first two bytes, `00 00`, are the source of my confusion. I originally misread this, and that's critical to the understanding. `00 00` are both Size 0.
Tag 8 (Input), Type 0, Size 2.
Ah-ha! `0x82` at the end! It's an `Input` report with *two* bytes of data! The problem is that the buffer ends at `82`!

If the buffer ends at `82` there are no data bytes! The `hid_parse_report` will likely fail! I need to review `hid_parser_main` to be certain!

map[ContextFile:drivers/hid/hid-core.c IncludeLines:true Name:hid_parser_main]

map[SourceCode: 641:	static int hid_parser_main(struct hid_parser *parser, struct hid_item *item)
 642:	{
 643:		__u32 data;
 644:		int ret;
 645:	
 646:		hid_concatenate_last_usage_page(parser);
 647:	
 648:		data = item_udata(item);
 649:	
 650:		switch (item->tag) {
 651:		case HID_MAIN_ITEM_TAG_BEGIN_COLLECTION:
 652:			ret = open_collection(parser, data & 0xff);
 653:			break;
 654:		case HID_MAIN_ITEM_TAG_END_COLLECTION:
 655:			ret = close_collection(parser);
 656:			break;
 657:		case HID_MAIN_ITEM_TAG_INPUT:
 658:			ret = hid_add_field(parser, HID_INPUT_REPORT, data);
 659:			break;
 660:		case HID_MAIN_ITEM_TAG_OUTPUT:
 661:			ret = hid_add_field(parser, HID_OUTPUT_REPORT, data);
 662:			break;
 663:		case HID_MAIN_ITEM_TAG_FEATURE:
 664:			ret = hid_add_field(parser, HID_FEATURE_REPORT, data);
 665:			break;
 666:		default:
 667:			if (item->tag >= HID_MAIN_ITEM_TAG_RESERVED_MIN &&
 668:				item->tag <= HID_MAIN_ITEM_TAG_RESERVED_MAX)
 669:				hid_warn_ratelimited(parser->device, "reserved main item tag 0x%x\n", item->tag);
 670:			else
 671:				hid_warn_ratelimited(parser->device, "unknown main item tag 0x%x\n", item->tag);
 672:			ret = 0;
 673:		}
 674:	
 675:		memset(&parser->local, 0, sizeof(parser->local));	/* Reset the local parser environment */
 676:	
 677:		return ret;
 678:	}
 SourceFile:drivers/hid/hid-core.c]

gemini-3.1-pro-preview

							input: 87311
							output: 41
							thoughts: 19
						

Here's my understanding of the situation, presented from my perspective as an expert:

**Understanding the Item Parsing in `hid-core.c`**

Okay, so I'm thinking about the low-level HID implementation, and specifically, I'm trying to recall where the item parsing actually happens. Ah, right! It's in `hid-core.c`, isn't it? The function `fetch_item` is the key. That's where the raw report descriptor data gets dissected into individual items. That's a critical piece for building the structure of the HID report. I need to make sure I remember that `fetch_item` call because that's the starting point for figuring out what each field is, what its usage is, and how it should be interpreted. It's the lynchpin for understanding the entire report structure, which is vital for any analysis of the device's capabilities.

map[ContextFile:drivers/hid/hid-core.c IncludeLines:true Name:fetch_item]

map[SourceCode: 781:	static const u8 *fetch_item(const __u8 *start, const __u8 *end, struct hid_item *item)
 782:	{
 783:		u8 b;
 784:	
 785:		if ((end - start) <= 0)
 786:			return NULL;
 787:	
 788:		b = *start++;
 789:	
 790:		item->type = (b >> 2) & 3;
 791:		item->tag  = (b >> 4) & 15;
 792:	
 793:		if (item->tag == HID_ITEM_TAG_LONG) {
 794:	
 795:			item->format = HID_ITEM_FORMAT_LONG;
 796:	
 797:			if ((end - start) < 2)
 798:				return NULL;
 799:	
 800:			item->size = *start++;
 801:			item->tag  = *start++;
 802:	
 803:			if ((end - start) < item->size)
 804:				return NULL;
 805:	
 806:			item->data.longdata = start;
 807:			start += item->size;
 808:			return start;
 809:		}
 810:	
 811:		item->format = HID_ITEM_FORMAT_SHORT;
 812:		item->size = BIT(b & 3) >> 1; /* 0, 1, 2, 3 -> 0, 1, 2, 4 */
 813:	
 814:		if (end - start < item->size)
 815:			return NULL;
 816:	
 817:		switch (item->size) {
 818:		case 0:
 819:			break;
 820:	
 821:		case 1:
 822:			item->data.u8 = *start;
 823:			break;
 824:	
 825:		case 2:
 826:			item->data.u16 = get_unaligned_le16(start);
 827:			break;
 828:	
 829:		case 4:
 830:			item->data.u32 = get_unaligned_le32(start);
 831:			break;
 832:		}
 833:	
 834:		return start + item->size;
 835:	}
 SourceFile:drivers/hid/hid-core.c]

gemini-3.1-pro-preview

							input: 88306
							output: 43
							thoughts: 77
						

Okay, let's break this down.

**Analyzing a Potential Parsing Failure**

Hmm, so if the difference between `end` and `start` is less than `item->size`, the function returns `NULL`. That seems straightforward. Looking at the example, this means the last item, which I'm seeing is `82` with a size of 2, will trigger this condition and `fetch_item` will return `NULL`. The question is, what happens *then*? Does `hid_parse_report` just bail out? Does it handle the `NULL` return gracefully, or does it lead to a premature stop in the parse? I need to check either `hid_parse_report` or potentially the function it calls, `hid_parse_collections`, to understand the control flow and error handling. I need to know how it reacts when it doesn't get a valid item. I suspect that this small size will cause issues.

map[ContextFile:drivers/hid/hid-core.c IncludeLines:true Name:hid_parse_collections]

map[SourceCode:1248:	static int hid_parse_collections(struct hid_device *device)
1249:	{
1250:		struct hid_item item;
1251:		const u8 *start = device->rdesc;
1252:		const u8 *end = start + device->rsize;
1253:		const u8 *next;
1254:		int ret;
1255:		static typeof(hid_parser_main) (* const dispatch_type[]) = {
1256:			hid_parser_main,
1257:			hid_parser_global,
1258:			hid_parser_local,
1259:			hid_parser_reserved
1260:		};
1261:	
1262:		struct hid_parser *parser __free(kvfree) = vzalloc(sizeof(*parser));
1263:		if (!parser)
1264:			return -ENOMEM;
1265:	
1266:		parser->device = device;
1267:	
1268:		device->collection = kzalloc_objs(*device->collection,
1269:						  HID_DEFAULT_NUM_COLLECTIONS);
1270:		if (!device->collection)
1271:			return -ENOMEM;
1272:	
1273:		device->collection_size = HID_DEFAULT_NUM_COLLECTIONS;
1274:		for (unsigned int i = 0; i < HID_DEFAULT_NUM_COLLECTIONS; i++)
1275:			device->collection[i].parent_idx = -1;
1276:	
1277:		ret = -EINVAL;
1278:		if (start == end) {
1279:			hid_err(device, "rejecting 0-sized report descriptor\n");
1280:			goto out;
1281:		}
1282:	
1283:		while ((next = fetch_item(start, end, &item)) != NULL) {
1284:			start = next;
1285:	
1286:			if (item.format != HID_ITEM_FORMAT_SHORT) {
1287:				hid_err(device, "unexpected long global item\n");
1288:				goto out;
1289:			}
1290:	
1291:			if (dispatch_type[item.type](parser, &item)) {
1292:				hid_err(device, "item %u %u %u %u parsing failed\n",
1293:					item.format,
1294:					(unsigned int)item.size,
1295:					(unsigned int)item.type,
1296:					(unsigned int)item.tag);
1297:				goto out;
1298:			}
1299:		}
1300:	
1301:		if (start != end) {
1302:			hid_err(device, "item fetching failed at offset %u/%u\n",
1303:				device->rsize - (unsigned int)(end - start),
1304:				device->rsize);
1305:			goto out;
1306:		}
1307:	
1308:		if (parser->collection_stack_ptr) {
1309:			hid_err(device, "unbalanced collection at end of report description\n");
1310:			goto out;
1311:		}
1312:	
1313:		if (parser->local.delimiter_depth) {
1314:			hid_err(device, "unbalanced delimiter at end of report description\n");
1315:			goto out;
1316:		}
1317:	
1318:		/*
1319:		 * fetch initial values in case the device's
1320:		 * default multiplier isn't the recommended 1
1321:		 */
1322:		hid_setup_resolution_multiplier(device);
1323:	
1324:		device->status |= HID_STAT_PARSED;
1325:		ret = 0;
1326:	
1327:	out:
1328:		kfree(parser->collection_stack);
1329:		return ret;
1330:	}
 SourceFile:drivers/hid/hid-core.c]

gemini-3.1-pro-preview

							input: 89797
							output: 45
							thoughts: 1414
						

**Analyzing the Report Descriptor Vulnerability**

Okay, let's break this down. My initial concern was around `hid_parse_collections` failing, which would cascade up to `mcp2221_probe`. If the report descriptor is invalid, that's a problem, and the whole driver fails. The reproducer must ensure the report descriptor *is* valid because otherwise `mcp2221_raw_event` can't be called. Let's revisit the reproducer and see what's happening.

The `syz_usb_connect` calls are interesting. The first call sets up a device, then the second call… wait, it modifies the device descriptor! Specifically, it sets `wDescriptorLength` to 0. The second call to `syz_usb_connect` connects a device with a modified descriptor.

Now, we have a disconnection of the *first* device with `syz_usb_disconnect` using the file descriptor returned by the *first* connection. Then we have an `syz_usb_ep_write` call using the *same* file descriptor! That's a red flag. But wait, since we know `syz_usb_disconnect` closes the file descriptor, this `syz_usb_ep_write` should fail with EBADF, right?

But, ah ha! The reproducer's logic makes the first device disconnect; then the second connect must have the *same* file descriptor number as the first! So, `r[1]` will be the same as `r[0]`, because the `syz_usb_disconnect` closes the first device. This means the `syz_usb_ep_write` is writing to the *second* device!

The key here is that the second device has `wDescriptorLength = 0`. If `wDescriptorLength` is zero, `hid_parse` will request zero bytes from the device! That's a problem. `hid_parse` gets the report descriptor through a control transfer. If `wDescriptorLength` is zero, it'll ask for no data. We need to check `usbhid_parse` now to verify what happens on a read for zero bytes.

map[ContextFile:drivers/hid/usbhid/hid-core.c IncludeLines:true Name:usbhid_parse]

map[SourceCode: 982:	static int usbhid_parse(struct hid_device *hid)
 983:	{
 984:		struct usb_interface *intf = to_usb_interface(hid->dev.parent);
 985:		struct usb_host_interface *interface = intf->cur_altsetting;
 986:		struct usb_device *dev = interface_to_usbdev (intf);
 987:		struct hid_descriptor *hdesc;
 988:		struct hid_class_descriptor *hcdesc;
 989:		__u8 fixed_opt_descriptors_size;
 990:		u32 quirks = 0;
 991:		unsigned int rsize = 0;
 992:		char *rdesc;
 993:		int ret;
 994:	
 995:		quirks = hid_lookup_quirk(hid);
 996:	
 997:		if (quirks & HID_QUIRK_IGNORE)
 998:			return -ENODEV;
 999:	
1000:		/* Many keyboards and mice don't like to be polled for reports,
1001:		 * so we will always set the HID_QUIRK_NOGET flag for them. */
1002:		if (interface->desc.bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT) {
1003:			if (interface->desc.bInterfaceProtocol == USB_INTERFACE_PROTOCOL_KEYBOARD ||
1004:				interface->desc.bInterfaceProtocol == USB_INTERFACE_PROTOCOL_MOUSE)
1005:					quirks |= HID_QUIRK_NOGET;
1006:		}
1007:	
1008:		if (usb_get_extra_descriptor(interface, HID_DT_HID, &hdesc) &&
1009:		    (!interface->desc.bNumEndpoints ||
1010:		     usb_get_extra_descriptor(&interface->endpoint[0], HID_DT_HID, &hdesc))) {
1011:			dbg_hid("class descriptor not present\n");
1012:			return -ENODEV;
1013:		}
1014:	
1015:		if (!hdesc->bNumDescriptors ||
1016:		    hdesc->bLength != sizeof(*hdesc) +
1017:				      (hdesc->bNumDescriptors - 1) * sizeof(*hcdesc)) {
1018:			dbg_hid("hid descriptor invalid, bLen=%hhu bNum=%hhu\n",
1019:				hdesc->bLength, hdesc->bNumDescriptors);
1020:	
1021:			/*
1022:			 * Some devices may expose a wrong number of descriptors compared
1023:			 * to the provided length.
1024:			 * However, we ignore the optional hid class descriptors entirely
1025:			 * so we can safely recompute the proper field.
1026:			 */
1027:			if (hdesc->bLength >= sizeof(*hdesc)) {
1028:				fixed_opt_descriptors_size = hdesc->bLength - sizeof(*hdesc);
1029:	
1030:				hid_warn(intf, "fixing wrong optional hid class descriptors count\n");
1031:				hdesc->bNumDescriptors = fixed_opt_descriptors_size / sizeof(*hcdesc) + 1;
1032:			} else {
1033:				return -EINVAL;
1034:			}
1035:		}
1036:	
1037:		hid->version = le16_to_cpu(hdesc->bcdHID);
1038:		hid->country = hdesc->bCountryCode;
1039:	
1040:		if (hdesc->rpt_desc.bDescriptorType == HID_DT_REPORT)
1041:			rsize = le16_to_cpu(hdesc->rpt_desc.wDescriptorLength);
1042:	
1043:		if (!rsize || rsize > HID_MAX_DESCRIPTOR_SIZE) {
1044:			dbg_hid("weird size of report descriptor (%u)\n", rsize);
1045:			return -EINVAL;
1046:		}
1047:	
1048:		rdesc = kmalloc(rsize, GFP_KERNEL);
1049:		if (!rdesc)
1050:			return -ENOMEM;
1051:	
1052:		hid_set_idle(dev, interface->desc.bInterfaceNumber, 0, 0);
1053:	
1054:		ret = hid_get_class_descriptor(dev, interface->desc.bInterfaceNumber,
1055:				HID_DT_REPORT, rdesc, rsize);
1056:		if (ret < 0) {
1057:			dbg_hid("reading report descriptor failed\n");
1058:			kfree(rdesc);
1059:			goto err;
1060:		}
1061:	
1062:		ret = hid_parse_report(hid, rdesc, rsize);
1063:		kfree(rdesc);
1064:		if (ret) {
1065:			dbg_hid("parsing report descriptor failed\n");
1066:			goto err;
1067:		}
1068:	
1069:		if (hdesc->bNumDescriptors > 1)
1070:			hid_warn(intf,
1071:				"%u unsupported optional hid class descriptors\n",
1072:				(int)(hdesc->bNumDescriptors - 1));
1073:	
1074:		hid->quirks |= quirks;
1075:	
1076:		return 0;
1077:	err:
1078:		return ret;
1079:	}
 SourceFile:drivers/hid/usbhid/hid-core.c]

gemini-3.1-pro-preview

							input: 93308
							output: 48
							thoughts: 2890
						

**Analyzing the USB HID Crash: A Deep Dive**

Okay, so the `if (!rsize || rsize > HID_MAX_DESCRIPTOR_SIZE)` check looks like the key. If `wDescriptorLength` is zero, `usbhid_parse` returns `-EINVAL`. This failure propagates: `usbhid_parse` fails -> `hid_parse` fails -> `mcp2221_probe` fails. This means the second device, with its zero `wDescriptorLength`, shouldn't be probed successfully. Since we see `mcp2221_raw_event` being called, I initially assume the crash is *not* on the second device.

Let's dissect the first device's descriptor, as that looks truncated. Examining the byte array, it seems the endpoint descriptor is missing bytes: `09 05 81 03 08` is only 5 bytes, whereas it usually is 7 bytes. Now, looking at the HID descriptor itself: `wDescriptorLength` is set to 1. This means `usbhid_parse` allocates and reads only one byte for the report descriptor. However, the first device's `syz_usb_connect` uses `conn_descs=0`, which means it doesn't handle `USB_DT_REPORT` (type 0x22). The `lookup_connect_response_in` function doesn't include a case for report descriptors. Consequently, the endpoint stalls!

A stall in `lookup_connect_response_in` leads to `usb_raw_ep0_stall`. This should cause `hid_get_class_descriptor` to fail, which returns an error. This returns `-EPIPE`, which is then returned by `usbhid_parse`. Thus, `hid_parse` and `mcp2221_probe` will also return `-EPIPE`. The stall implies that `mcp2221_probe` MUST succeed for the crash to occur. But how? This scenario requires `mcp2221_probe` to succeed on the first device.

The second device has its `wDescriptorLength` set to 0. With this value, `usbhid_parse` should return `-EINVAL`. Yet, `syz_usb_control_io` is called on the second device, fetching an event. Examining the provided descriptor buffer, `syz_usb_control_io` provides the report descriptor, which should work, and the device SHOULDN'T stall. Here, the crash must occur on the first device.

However, `mcp2221_probe` does not return early. This means that `hid_parse` actually succeeds!

So the critical function to examine is `hid_parse`. Then, it turns out that `hid_parse` is just a macro for `hid_open_report`. Now, `usbhid_parse` is invoked by `usbhid_probe`. This means that if `usbhid_parse` were to fail, the entire probing process would fail, and we wouldn't reach the problematic code. If `usbhid_parse` succeeds, `hid_add_device` is then called.

In the case of the first device, `wDescriptorLength` is 1. This means the allocated size, `rsize`, is 1. `usbhid_parse` then allocates one byte and performs `GET_DESCRIPTOR`. However, since `lookup_connect_response_in` stalls, `hid_get_class_descriptor` fails with a stall and `usb_control_msg` will return `-EPIPE`.

Therefore, the first device is the one that causes the crash, and it must occur within `hid_get_class_descriptor` when `USB_DT_REPORT` stalls.

map[ContextFile:drivers/hid/usbhid/hid-core.c IncludeLines:true Name:hid_get_class_descriptor]

map[SourceCode: 665:	static int hid_get_class_descriptor(struct usb_device *dev, int ifnum,
 666:			unsigned char type, void *buf, int size)
 667:	{
 668:		int result, retries = 4;
 669:	
 670:		memset(buf, 0, size);
 671:	
 672:		do {
 673:			result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
 674:					USB_REQ_GET_DESCRIPTOR, USB_RECIP_INTERFACE | USB_DIR_IN,
 675:					(type << 8), ifnum, buf, size, USB_CTRL_GET_TIMEOUT);
 676:			retries--;
 677:		} while (result < size && retries);
 678:		return result;
 679:	}
 SourceFile:drivers/hid/usbhid/hid-core.c]

gemini-3.1-pro-preview

							input: 97330
							output: 45
							thoughts: 7294
						

**Initial Analysis of a USB Driver Issue**

Okay, here's the breakdown of my thinking as I dissect this USB driver bug.  It's clear something isn't aligning with how the driver expects devices to behave, especially with HID descriptors.  The primary suspect is likely a race or some error handling quirk around device setup and descriptor parsing.  

Initially, I'm noting the `-EPIPE` return and the retry logic. It's a key symptom, especially if coupled with a descriptor parsing failure.  The fact that `usbhid_parse` fails is what kicks off this whole investigation. The first device's failure is interesting: if `usbhid_parse` fails the device doesn't get added, and yet there are events happening.

Then I get into the heart of the problem:  the descriptor length.  I see a `wDescriptorLength` of zero for the second device. That *should* lead to `usbhid_parse` returning `-EINVAL` straight away, so it makes no sense. The code's clearly setting `wDescriptorLength` to zero.  

The repro uses `BPF` which is interesting, I check that it is just a USB device. The first device gets its descriptors modified after the connect call, which should mean that the first call is important, but the first call does not matter, as the first device is disconnect before it's probed.

The key is in `syz_usb_connect_impl`: it stalls on `USB_DT_REPORT`! No, `SET_CONFIGURATION` is received, and the function returns the fd, then the other control requests are handled in a separate function.  I am thinking that this is a race between the disconnection of the first device, and the probing of the second, and that it explains how the `SET_CONFIGURATION` is received, and that triggers device removal and the probe may be happening at the same time.

The first device's endpoint write isn't to the first device, the file descriptors are likely reused.
The key to getting to the `mcp2221` function is that the `usbhid_probe` runs in a separate thread.
I realize now that the `fd`s can be reused, so `r[0]` and `r[1]` might be the same!  This is *huge*.  If `syz_usb_connect` closes the first device fd, the subsequent call to connect returns the SAME fd! The `syz_usb_ep_write` call is then *actually* talking to the second device, but that device's descriptor is messed up with `bLength` = 0.  I am now sure that I understand how this works, or at least how the problem occurs. I now believe that there might be a race in the disconnection of the first device while the device is being probed in a separate thread.

requested entity does not exist

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

map[SourceCode: SourceFile:]

gemini-3.1-pro-preview

							input: 105300
							output: 21
							thoughts: 14
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Analyzing the `usb_get_extra_descriptor` Call**

Okay, so I'm thinking about `usb_get_extra_descriptor`. That function name rings a bell... it's likely a critical piece in handling those pesky extended USB descriptors, right? My initial guess is that it's designed to retrieve vendor-specific or class-specific descriptors that go beyond the standard ones defined in the USB specification. It's probably being used to dive deeper into the capabilities or features of a device beyond what's immediately apparent in the basic device, configuration, interface, and endpoint descriptors.

I'm imagining this is probably invoked during device enumeration or configuration, possibly when parsing the configuration descriptor. I would expect it to be used when a standard descriptor indicates the presence of an extended descriptor, probably indicated by a specific field. I'd be looking for fields like `bDescriptorType` or `wTotalLength` of descriptors near the end of the standard information, as hints of where the relevant data can be found.

I'm also thinking about potential use-cases. Maybe it's for handling complex audio devices, custom HID reports, or devices that implement unique power management features or perhaps custom protocols. I'd be interested in how the function is used, and which variables are provided to the function. This would lead me to where I should search.

map[Expression:usb_get_extra_descriptor]

map[Output:drivers/hid/usbhid/hid-core.c=982=static int usbhid_parse(struct hid_device *hid)
--
drivers/hid/usbhid/hid-core.c-1007-
drivers/hid/usbhid/hid-core.c:1008:	if (usb_get_extra_descriptor(interface, HID_DT_HID, &hdesc) &&
drivers/hid/usbhid/hid-core.c-1009-	    (!interface->desc.bNumEndpoints ||
drivers/hid/usbhid/hid-core.c:1010:	     usb_get_extra_descriptor(&interface->endpoint[0], HID_DT_HID, &hdesc))) {
drivers/hid/usbhid/hid-core.c-1011-		dbg_hid("class descriptor not present\n");
--
drivers/usb/core/hub.c=2435=static int usb_enumerate_device_otg(struct usb_device *udev)
--
drivers/usb/core/hub.c-2452-		/* descriptor may appear anywhere in config */
drivers/usb/core/hub.c:2453:		err = __usb_get_extra_descriptor(udev->rawdescriptors[0],
drivers/usb/core/hub.c-2454-				le16_to_cpu(udev->config[0].desc.wTotalLength),
--
drivers/usb/core/usb.c=946=EXPORT_SYMBOL_GPL(usb_get_current_frame_number);
--
drivers/usb/core/usb.c-949-/*
drivers/usb/core/usb.c:950: * __usb_get_extra_descriptor() finds a descriptor of specific type in the
drivers/usb/core/usb.c-951- * extra field of the interface and endpoint descriptor structs.
--
drivers/usb/core/usb.c-953-
drivers/usb/core/usb.c:954:int __usb_get_extra_descriptor(char *buffer, unsigned size,
drivers/usb/core/usb.c-955-			       unsigned char type, void **ptr, size_t minsize)
--
drivers/usb/core/usb.c-980-}
drivers/usb/core/usb.c:981:EXPORT_SYMBOL_GPL(__usb_get_extra_descriptor);
drivers/usb/core/usb.c-982-
--
drivers/video/fbdev/udlfb.c=1549=static int dlfb_parse_vendor_descriptor(struct dlfb_data *dlfb,
--
drivers/video/fbdev/udlfb.c-1567-	if (total_len < 0) {
drivers/video/fbdev/udlfb.c:1568:		if (0 == usb_get_extra_descriptor(intf->cur_altsetting,
drivers/video/fbdev/udlfb.c-1569-			0x5f, &desc))
--
include/linux/usb.h=428=struct usb_host_bos {
--
include/linux/usb.h-437-
include/linux/usb.h:438:int __usb_get_extra_descriptor(char *buffer, unsigned size,
include/linux/usb.h-439-	unsigned char type, void **ptr, size_t min);
include/linux/usb.h:440:#define usb_get_extra_descriptor(ifpoint, type, ptr) \
include/linux/usb.h:441:				__usb_get_extra_descriptor((ifpoint)->extra, \
include/linux/usb.h-442-				(ifpoint)->extralen, \
]

gemini-3.1-pro-preview

							input: 106555
							output: 43
							thoughts: 383
						

**Analyzing USB Descriptor Parsing**

Okay, so I'm looking at how `usb_get_extra_descriptor` handles things. My initial thought is it searches for the descriptor within `(ifpoint)->extra`, which seems standard. But then I'm seeing this C code that's modifying an address, `0x200000000024`. That's a red flag. Let me quickly re-examine the offsets to make sure I'm oriented. I see:

*   `0x1b`: `09` (bLength for the interface)
*   `0x1c`: `04` (bDescriptorType - the interface descriptor)
*   `0x1d`: `00` (bInterfaceNumber)
*   `0x1e`: `00` (bAlternateSetting)
*   `0x1f`: `00` (bNumEndpoints)
*   `0x20`: `03` (bInterfaceClass)
*   `0x21`: `01` (bInterfaceSubClass)
*   `0x22`: `00` (bInterfaceProtocol)
*   `0x23`: `00` (iInterface)
*   `0x24`: `00` (bLength for HID)

Now it hits me. If `bNumEndpoints` is actually zero, that means the interface descriptor *should* be only 9 bytes long. Logically, the HID descriptor would directly follow it as an extra.

But the real problem is that I'm seeing a code snippet:

```c
*(uint8_t*)0x20000000001f = 0; // bNumEndpoints = 0
```

That's a direct *write* to memory, setting `bNumEndpoints` to zero. This is where it gets interesting, because if `bNumEndpoints` is zero, the USB core *won't* parse any endpoint descriptors. So this modifies the core logic.

And, as I said, the HID descriptor is an EXTRA descriptor of the interface. Since the USB core is supposed to parse the entire configuration and its sub-descriptors, if `bLength` of the HID descriptor is 0, what happens then? My next step is to head over to the `usb_parse_configuration` function in `drivers/usb/core/config.c` to see how it handles this specific case.

map[ContextFile:drivers/usb/core/config.c IncludeLines:true Name:usb_parse_configuration]

map[SourceCode: 659:	static int usb_parse_configuration(struct usb_device *dev, int cfgidx,
 660:	    struct usb_host_config *config, unsigned char *buffer, int size)
 661:	{
 662:		struct device *ddev = &dev->dev;
 663:		unsigned char *buffer0 = buffer;
 664:		int cfgno;
 665:		int nintf, nintf_orig;
 666:		int i, j, n;
 667:		struct usb_interface_cache *intfc;
 668:		unsigned char *buffer2;
 669:		int size2;
 670:		struct usb_descriptor_header *header;
 671:		int retval;
 672:		u8 inums[USB_MAXINTERFACES], nalts[USB_MAXINTERFACES];
 673:		unsigned iad_num = 0;
 674:	
 675:		memcpy(&config->desc, buffer, USB_DT_CONFIG_SIZE);
 676:		nintf = nintf_orig = config->desc.bNumInterfaces;
 677:		config->desc.bNumInterfaces = 0;	// Adjusted later
 678:	
 679:		if (config->desc.bDescriptorType != USB_DT_CONFIG ||
 680:		    config->desc.bLength < USB_DT_CONFIG_SIZE ||
 681:		    config->desc.bLength > size) {
 682:			dev_notice(ddev, "invalid descriptor for config index %d: "
 683:			    "type = 0x%X, length = %d\n", cfgidx,
 684:			    config->desc.bDescriptorType, config->desc.bLength);
 685:			return -EINVAL;
 686:		}
 687:		cfgno = config->desc.bConfigurationValue;
 688:	
 689:		buffer += config->desc.bLength;
 690:		size -= config->desc.bLength;
 691:	
 692:		if (nintf > USB_MAXINTERFACES) {
 693:			dev_notice(ddev, "config %d has too many interfaces: %d, "
 694:			    "using maximum allowed: %d\n",
 695:			    cfgno, nintf, USB_MAXINTERFACES);
 696:			nintf = USB_MAXINTERFACES;
 697:		}
 698:	
 699:		/* Go through the descriptors, checking their length and counting the
 700:		 * number of altsettings for each interface */
 701:		n = 0;
 702:		for ((buffer2 = buffer, size2 = size);
 703:		      size2 > 0;
 704:		     (buffer2 += header->bLength, size2 -= header->bLength)) {
 705:	
 706:			if (size2 < sizeof(struct usb_descriptor_header)) {
 707:				dev_notice(ddev, "config %d descriptor has %d excess "
 708:				    "byte%s, ignoring\n",
 709:				    cfgno, size2, str_plural(size2));
 710:				break;
 711:			}
 712:	
 713:			header = (struct usb_descriptor_header *) buffer2;
 714:			if ((header->bLength > size2) || (header->bLength < 2)) {
 715:				dev_notice(ddev, "config %d has an invalid descriptor "
 716:				    "of length %d, skipping remainder of the config\n",
 717:				    cfgno, header->bLength);
 718:				break;
 719:			}
 720:	
 721:			if (header->bDescriptorType == USB_DT_INTERFACE) {
 722:				struct usb_interface_descriptor *d;
 723:				int inum;
 724:	
 725:				d = (struct usb_interface_descriptor *) header;
 726:				if (d->bLength < USB_DT_INTERFACE_SIZE) {
 727:					dev_notice(ddev, "config %d has an invalid "
 728:					    "interface descriptor of length %d, "
 729:					    "skipping\n", cfgno, d->bLength);
 730:					continue;
 731:				}
 732:	
 733:				inum = d->bInterfaceNumber;
 734:	
 735:				if ((dev->quirks & USB_QUIRK_HONOR_BNUMINTERFACES) &&
 736:				    n >= nintf_orig) {
 737:					dev_notice(ddev, "config %d has more interface "
 738:					    "descriptors, than it declares in "
 739:					    "bNumInterfaces, ignoring interface "
 740:					    "number: %d\n", cfgno, inum);
 741:					continue;
 742:				}
 743:	
 744:				if (inum >= nintf_orig)
 745:					dev_notice(ddev, "config %d has an invalid "
 746:					    "interface number: %d but max is %d\n",
 747:					    cfgno, inum, nintf_orig - 1);
 748:	
 749:				/* Have we already encountered this interface?
 750:				 * Count its altsettings */
 751:				for (i = 0; i < n; ++i) {
 752:					if (inums[i] == inum)
 753:						break;
 754:				}
 755:				if (i < n) {
 756:					if (nalts[i] < 255)
 757:						++nalts[i];
 758:				} else if (n < USB_MAXINTERFACES) {
 759:					inums[n] = inum;
 760:					nalts[n] = 1;
 761:					++n;
 762:				}
 763:	
 764:			} else if (header->bDescriptorType ==
 765:					USB_DT_INTERFACE_ASSOCIATION) {
 766:				struct usb_interface_assoc_descriptor *d;
 767:	
 768:				d = (struct usb_interface_assoc_descriptor *)header;
 769:				if (d->bLength < USB_DT_INTERFACE_ASSOCIATION_SIZE) {
 770:					dev_notice(ddev,
 771:						 "config %d has an invalid interface association descriptor of length %d, skipping\n",
 772:						 cfgno, d->bLength);
 773:					continue;
 774:				}
 775:	
 776:				if (iad_num == USB_MAXIADS) {
 777:					dev_notice(ddev, "found more Interface "
 778:						       "Association Descriptors "
 779:						       "than allocated for in "
 780:						       "configuration %d\n", cfgno);
 781:				} else {
 782:					config->intf_assoc[iad_num] = d;
 783:					iad_num++;
 784:				}
 785:	
 786:			} else if (header->bDescriptorType == USB_DT_DEVICE ||
 787:				    header->bDescriptorType == USB_DT_CONFIG)
 788:				dev_notice(ddev, "config %d contains an unexpected "
 789:				    "descriptor of type 0x%X, skipping\n",
 790:				    cfgno, header->bDescriptorType);
 791:	
 792:		}	/* for ((buffer2 = buffer, size2 = size); ...) */
 793:		size = buffer2 - buffer;
 794:		config->desc.wTotalLength = cpu_to_le16(buffer2 - buffer0);
 795:	
 796:		if (n != nintf)
 797:			dev_notice(ddev, "config %d has %d interface%s, different from "
 798:			    "the descriptor's value: %d\n",
 799:			    cfgno, n, str_plural(n), nintf_orig);
 800:		else if (n == 0)
 801:			dev_notice(ddev, "config %d has no interfaces?\n", cfgno);
 802:		config->desc.bNumInterfaces = nintf = n;
 803:	
 804:		/* Check for missing interface numbers */
 805:		for (i = 0; i < nintf; ++i) {
 806:			for (j = 0; j < nintf; ++j) {
 807:				if (inums[j] == i)
 808:					break;
 809:			}
 810:			if (j >= nintf)
 811:				dev_notice(ddev, "config %d has no interface number "
 812:				    "%d\n", cfgno, i);
 813:		}
 814:	
 815:		/* Allocate the usb_interface_caches and altsetting arrays */
 816:		for (i = 0; i < nintf; ++i) {
 817:			j = nalts[i];
 818:			if (j > USB_MAXALTSETTING) {
 819:				dev_notice(ddev, "too many alternate settings for "
 820:				    "config %d interface %d: %d, "
 821:				    "using maximum allowed: %d\n",
 822:				    cfgno, inums[i], j, USB_MAXALTSETTING);
 823:				nalts[i] = j = USB_MAXALTSETTING;
 824:			}
 825:	
 826:			intfc = kzalloc_flex(*intfc, altsetting, j);
 827:			config->intf_cache[i] = intfc;
 828:			if (!intfc)
 829:				return -ENOMEM;
 830:			kref_init(&intfc->ref);
 831:		}
 832:	
 833:		/* FIXME: parse the BOS descriptor */
 834:	
 835:		/* Skip over any Class Specific or Vendor Specific descriptors;
 836:		 * find the first interface descriptor */
 837:		config->extra = buffer;
 838:		i = find_next_descriptor(buffer, size, USB_DT_INTERFACE,
 839:		    USB_DT_INTERFACE, &n);
 840:		config->extralen = i;
 841:		if (n > 0)
 842:			dev_dbg(ddev, "skipped %d descriptor%s after %s\n",
 843:			    n, str_plural(n), "configuration");
 844:		buffer += i;
 845:		size -= i;
 846:	
 847:		/* Parse all the interface/altsetting descriptors */
 848:		while (size > 0) {
 849:			retval = usb_parse_interface(ddev, cfgno, config,
 850:			    buffer, size, inums, nalts);
 851:			if (retval < 0)
 852:				return retval;
 853:	
 854:			buffer += retval;
 855:			size -= retval;
 856:		}
 857:	
 858:		/* Check for missing altsettings */
 859:		for (i = 0; i < nintf; ++i) {
 860:			intfc = config->intf_cache[i];
 861:			for (j = 0; j < intfc->num_altsetting; ++j) {
 862:				for (n = 0; n < intfc->num_altsetting; ++n) {
 863:					if (intfc->altsetting[n].desc.
 864:					    bAlternateSetting == j)
 865:						break;
 866:				}
 867:				if (n >= intfc->num_altsetting)
 868:					dev_notice(ddev, "config %d interface %d has no "
 869:					    "altsetting %d\n", cfgno, inums[i], j);
 870:			}
 871:		}
 872:	
 873:		return 0;
 874:	}
 SourceFile:drivers/usb/core/config.c]

gemini-3.1-pro-preview

							input: 110996
							output: 43
							thoughts: 47
						

**Analyzing the USB Interface Parsing**

Okay, so `usb_parse_interface` is responsible for dissecting the interface descriptor and any accompanying extra descriptors. That makes sense; it's the core of how the system understands what the interface *does*. Now, I'm stuck on this edge case: What exactly happens when the `bLength` field within an HID descriptor is reported as zero? Does the parser gracefully handle this or could it lead to unforeseen behavior? Best to take a look at the code for `usb_parse_interface` to be certain. Gotta confirm what edge cases are accounted for.

map[ContextFile:drivers/usb/core/config.c IncludeLines:true Name:usb_parse_interface]

map[SourceCode: 552:	static int usb_parse_interface(struct device *ddev, int cfgno,
 553:	    struct usb_host_config *config, unsigned char *buffer, int size,
 554:	    u8 inums[], u8 nalts[])
 555:	{
 556:		unsigned char *buffer0 = buffer;
 557:		struct usb_interface_descriptor	*d;
 558:		int inum, asnum;
 559:		struct usb_interface_cache *intfc;
 560:		struct usb_host_interface *alt;
 561:		int i, n;
 562:		int len, retval;
 563:		int num_ep, num_ep_orig;
 564:	
 565:		d = (struct usb_interface_descriptor *) buffer;
 566:		buffer += d->bLength;
 567:		size -= d->bLength;
 568:	
 569:		if (d->bLength < USB_DT_INTERFACE_SIZE)
 570:			goto skip_to_next_interface_descriptor;
 571:	
 572:		/* Which interface entry is this? */
 573:		intfc = NULL;
 574:		inum = d->bInterfaceNumber;
 575:		for (i = 0; i < config->desc.bNumInterfaces; ++i) {
 576:			if (inums[i] == inum) {
 577:				intfc = config->intf_cache[i];
 578:				break;
 579:			}
 580:		}
 581:		if (!intfc || intfc->num_altsetting >= nalts[i])
 582:			goto skip_to_next_interface_descriptor;
 583:	
 584:		/* Check for duplicate altsetting entries */
 585:		asnum = d->bAlternateSetting;
 586:		for ((i = 0, alt = &intfc->altsetting[0]);
 587:		      i < intfc->num_altsetting;
 588:		     (++i, ++alt)) {
 589:			if (alt->desc.bAlternateSetting == asnum) {
 590:				dev_notice(ddev, "Duplicate descriptor for config %d "
 591:				    "interface %d altsetting %d, skipping\n",
 592:				    cfgno, inum, asnum);
 593:				goto skip_to_next_interface_descriptor;
 594:			}
 595:		}
 596:	
 597:		++intfc->num_altsetting;
 598:		memcpy(&alt->desc, d, USB_DT_INTERFACE_SIZE);
 599:	
 600:		/* Skip over any Class Specific or Vendor Specific descriptors;
 601:		 * find the first endpoint or interface descriptor */
 602:		alt->extra = buffer;
 603:		i = find_next_descriptor(buffer, size, USB_DT_ENDPOINT,
 604:		    USB_DT_INTERFACE, &n);
 605:		alt->extralen = i;
 606:		if (n > 0)
 607:			dev_dbg(ddev, "skipped %d descriptor%s after %s\n",
 608:			    n, str_plural(n), "interface");
 609:		buffer += i;
 610:		size -= i;
 611:	
 612:		/* Allocate space for the right(?) number of endpoints */
 613:		num_ep = num_ep_orig = alt->desc.bNumEndpoints;
 614:		alt->desc.bNumEndpoints = 0;		/* Use as a counter */
 615:		if (num_ep > USB_MAXENDPOINTS) {
 616:			dev_notice(ddev, "too many endpoints for config %d interface %d "
 617:			    "altsetting %d: %d, using maximum allowed: %d\n",
 618:			    cfgno, inum, asnum, num_ep, USB_MAXENDPOINTS);
 619:			num_ep = USB_MAXENDPOINTS;
 620:		}
 621:	
 622:		if (num_ep > 0) {
 623:			/* Can't allocate 0 bytes */
 624:			len = sizeof(struct usb_host_endpoint) * num_ep;
 625:			alt->endpoint = kzalloc(len, GFP_KERNEL);
 626:			if (!alt->endpoint)
 627:				return -ENOMEM;
 628:		}
 629:	
 630:		/* Parse all the endpoint descriptors */
 631:		n = 0;
 632:		while (size > 0) {
 633:			if (((struct usb_descriptor_header *) buffer)->bDescriptorType
 634:			     == USB_DT_INTERFACE)
 635:				break;
 636:			retval = usb_parse_endpoint(ddev, cfgno, config, inum, asnum,
 637:					alt, num_ep, buffer, size);
 638:			if (retval < 0)
 639:				return retval;
 640:			++n;
 641:	
 642:			buffer += retval;
 643:			size -= retval;
 644:		}
 645:	
 646:		if (n != num_ep_orig)
 647:			dev_notice(ddev, "config %d interface %d altsetting %d has %d "
 648:			    "endpoint descriptor%s, different from the interface "
 649:			    "descriptor's value: %d\n",
 650:			    cfgno, inum, asnum, n, str_plural(n), num_ep_orig);
 651:		return buffer - buffer0;
 652:	
 653:	skip_to_next_interface_descriptor:
 654:		i = find_next_descriptor(buffer, size, USB_DT_INTERFACE,
 655:		    USB_DT_INTERFACE, NULL);
 656:		return buffer - buffer0 + i;
 657:	}
 SourceFile:drivers/usb/core/config.c]

gemini-3.1-pro-preview

							input: 112925
							output: 43
							thoughts: 42
						

Okay, let's see...

**Analyzing Descriptor Navigation Logic**

Right, so `find_next_descriptor` seems to have a specific behavior. It's skipping over different types of descriptors until it hits either an `USB_DT_ENDPOINT` or an `USB_DT_INTERFACE`. I need to understand why that's happening. I need to take a closer look at that function. What's the rationale behind this selective skipping? Is it related to how the enumeration process is structured? Or perhaps it's optimized for a specific hardware architecture? I'll need to dig into the code and trace the control flow to be certain.

map[ContextFile:drivers/usb/core/config.c IncludeLines:true Name:find_next_descriptor]

map[SourceCode:  22:	static int find_next_descriptor(unsigned char *buffer, int size,
  23:	    int dt1, int dt2, int *num_skipped)
  24:	{
  25:		struct usb_descriptor_header *h;
  26:		int n = 0;
  27:		unsigned char *buffer0 = buffer;
  28:	
  29:		/* Find the next descriptor of type dt1 or dt2 */
  30:		while (size > 0) {
  31:			h = (struct usb_descriptor_header *) buffer;
  32:			if (h->bDescriptorType == dt1 || h->bDescriptorType == dt2)
  33:				break;
  34:			buffer += h->bLength;
  35:			size -= h->bLength;
  36:			++n;
  37:		}
  38:	
  39:		/* Store the number of descriptors skipped and return the
  40:		 * number of bytes skipped */
  41:		if (num_skipped)
  42:			*num_skipped = n;
  43:		return buffer - buffer0;
  44:	}
 SourceFile:drivers/usb/core/config.c]

gemini-3.1-pro-preview

							input: 113479
							output: 43
							thoughts: 5789
						

**The HID Descriptor Bug and the KASAN Crash**

Okay, here's what I've figured out, breaking it down step-by-step. The initial thought was that a zero `bLength` in the HID descriptor would lead to an infinite loop in `find_next_descriptor`. However, `usb_parse_configuration` has a check (`header->bLength < 2`) that would break out of the loop and cause the function to return.  But, that break causes a truncation of the buffer.

The first key observation is that the zero `bLength` causes `usb_parse_configuration` to truncate the buffer.  This loop initially scans all descriptors. The critical point is that after this truncation, the HID descriptor is *skipped* in the following loop within `usb_parse_interface`. Specifically, `alt->extra` will then be NULL, and the subsequent `usb_get_extra_descriptor` will fail to find the HID descriptor. Therefore, `usbhid_parse` returns `-ENODEV`, which should prevent the device from being properly added.

However, the crash isn't simply a hang; it's a KASAN slab-out-of-bounds error. The syzkaller reproducer modifies a specific byte in the descriptor buffer. The reproducer calls `syz_usb_connect` twice, with the modification only happening *after* the first call. This suggests that the second device is being connected with `bLength` = 0.

Looking closely at the code where the buffer is being modified:

```c
*(uint8_t*)0x200000000024 = 0;
```

This `0x200000000024` offset corresponds to the *start* of the HID descriptor. The buffer contains the following sequence:

*   Device descriptor (18 bytes)
*   Configuration descriptor (9 bytes)
*   Interface descriptor (9 bytes)
*   HID descriptor (9 bytes)
*   Endpoint descriptor (5 bytes)

So, yes, it *does* zero out the `bLength` field of the HID descriptor on the *second* device.

The first device, upon successful connect, then disconnects. However, it seems the disconnect doesn't instantly tear down the raw gadget. This is because the raw gadget uses a workqueue or some other mechanism to teardown the device. This means the first device may still exist in an inconsistent state when the second device attempts to connect. The first device attempts to send `GET_DESCRIPTOR`, but there is no user space process to respond to that request, leading to the device failing.

The important factor is that the second device, when it connects, sees the modified descriptor where `bLength` is 0, causing the `usb_parse_configuration` to truncate, skipping HID and causing `usbhid_parse` to return `-ENODEV`. This means the second device shouldn't probe correctly.

The reason the KASAN crash happens has to involve the fact the configuration is truncated, and later accesses are performed on invalid memory. So it's probably *not* a hang due to an infinite loop, but a race.

Furthermore, another detail that makes it tricky to troubleshoot, is that `bNumEndpoints` is being set to 0. Despite this fact, however, `usb_parse_interface` *will* still process the endpoint descriptor, though it will complain if there are *too many* endpoints.

The key to the whole bug is the zero-length HID descriptor. The modification of the buffer is happening *after* the first device's connection, meaning the crash happens on the *second* device. The `bLength` of 0 truncates the config and leads to `alt->extra` pointing to the wrong buffer, with `extralen` set to 0. Therefore, the HID descriptor is never found by `usbhid_parse`!  Then, there's another point! The endpoint `wMaxPacketSize` is 0. With `wMaxPacketSize` 0, the first device *might* not have been able to probe and crash in `usbhid_start`. This may have been the source of the KASAN slab-out-of-bounds error.

map[ContextFile:drivers/usb/core/urb.c IncludeLines:true Name:usb_submit_urb]

map[SourceCode: 230:	/**
 231:	 * usb_submit_urb - issue an asynchronous transfer request for an endpoint
 232:	 * @urb: pointer to the urb describing the request
 233:	 * @mem_flags: the type of memory to allocate, see kmalloc() for a list
 234:	 *	of valid options for this.
 235:	 *
 236:	 * This submits a transfer request, and transfers control of the URB
 237:	 * describing that request to the USB subsystem.  Request completion will
 238:	 * be indicated later, asynchronously, by calling the completion handler.
 239:	 * The three types of completion are success, error, and unlink
 240:	 * (a software-induced fault, also called "request cancellation").
 241:	 *
 242:	 * URBs may be submitted in interrupt context.
 243:	 *
 244:	 * The caller must have correctly initialized the URB before submitting
 245:	 * it.  Functions such as usb_fill_bulk_urb() and usb_fill_control_urb() are
 246:	 * available to ensure that most fields are correctly initialized, for
 247:	 * the particular kind of transfer, although they will not initialize
 248:	 * any transfer flags.
 249:	 *
 250:	 * If the submission is successful, the complete() callback from the URB
 251:	 * will be called exactly once, when the USB core and Host Controller Driver
 252:	 * (HCD) are finished with the URB.  When the completion function is called,
 253:	 * control of the URB is returned to the device driver which issued the
 254:	 * request.  The completion handler may then immediately free or reuse that
 255:	 * URB.
 256:	 *
 257:	 * With few exceptions, USB device drivers should never access URB fields
 258:	 * provided by usbcore or the HCD until its complete() is called.
 259:	 * The exceptions relate to periodic transfer scheduling.  For both
 260:	 * interrupt and isochronous urbs, as part of successful URB submission
 261:	 * urb->interval is modified to reflect the actual transfer period used
 262:	 * (normally some power of two units).  And for isochronous urbs,
 263:	 * urb->start_frame is modified to reflect when the URB's transfers were
 264:	 * scheduled to start.
 265:	 *
 266:	 * Not all isochronous transfer scheduling policies will work, but most
 267:	 * host controller drivers should easily handle ISO queues going from now
 268:	 * until 10-200 msec into the future.  Drivers should try to keep at
 269:	 * least one or two msec of data in the queue; many controllers require
 270:	 * that new transfers start at least 1 msec in the future when they are
 271:	 * added.  If the driver is unable to keep up and the queue empties out,
 272:	 * the behavior for new submissions is governed by the URB_ISO_ASAP flag.
 273:	 * If the flag is set, or if the queue is idle, then the URB is always
 274:	 * assigned to the first available (and not yet expired) slot in the
 275:	 * endpoint's schedule.  If the flag is not set and the queue is active
 276:	 * then the URB is always assigned to the next slot in the schedule
 277:	 * following the end of the endpoint's previous URB, even if that slot is
 278:	 * in the past.  When a packet is assigned in this way to a slot that has
 279:	 * already expired, the packet is not transmitted and the corresponding
 280:	 * usb_iso_packet_descriptor's status field will return -EXDEV.  If this
 281:	 * would happen to all the packets in the URB, submission fails with a
 282:	 * -EXDEV error code.
 283:	 *
 284:	 * For control endpoints, the synchronous usb_control_msg() call is
 285:	 * often used (in non-interrupt context) instead of this call.
 286:	 * That is often used through convenience wrappers, for the requests
 287:	 * that are standardized in the USB 2.0 specification.  For bulk
 288:	 * endpoints, a synchronous usb_bulk_msg() call is available.
 289:	 *
 290:	 * Return:
 291:	 * 0 on successful submissions. A negative error number otherwise.
 292:	 *
 293:	 * Request Queuing:
 294:	 *
 295:	 * URBs may be submitted to endpoints before previous ones complete, to
 296:	 * minimize the impact of interrupt latencies and system overhead on data
 297:	 * throughput.  With that queuing policy, an endpoint's queue would never
 298:	 * be empty.  This is required for continuous isochronous data streams,
 299:	 * and may also be required for some kinds of interrupt transfers. Such
 300:	 * queuing also maximizes bandwidth utilization by letting USB controllers
 301:	 * start work on later requests before driver software has finished the
 302:	 * completion processing for earlier (successful) requests.
 303:	 *
 304:	 * As of Linux 2.6, all USB endpoint transfer queues support depths greater
 305:	 * than one.  This was previously a HCD-specific behavior, except for ISO
 306:	 * transfers.  Non-isochronous endpoint queues are inactive during cleanup
 307:	 * after faults (transfer errors or cancellation).
 308:	 *
 309:	 * Reserved Bandwidth Transfers:
 310:	 *
 311:	 * Periodic transfers (interrupt or isochronous) are performed repeatedly,
 312:	 * using the interval specified in the urb.  Submitting the first urb to
 313:	 * the endpoint reserves the bandwidth necessary to make those transfers.
 314:	 * If the USB subsystem can't allocate sufficient bandwidth to perform
 315:	 * the periodic request, submitting such a periodic request should fail.
 316:	 *
 317:	 * For devices under xHCI, the bandwidth is reserved at configuration time, or
 318:	 * when the alt setting is selected.  If there is not enough bus bandwidth, the
 319:	 * configuration/alt setting request will fail.  Therefore, submissions to
 320:	 * periodic endpoints on devices under xHCI should never fail due to bandwidth
 321:	 * constraints.
 322:	 *
 323:	 * Device drivers must explicitly request that repetition, by ensuring that
 324:	 * some URB is always on the endpoint's queue (except possibly for short
 325:	 * periods during completion callbacks).  When there is no longer an urb
 326:	 * queued, the endpoint's bandwidth reservation is canceled.  This means
 327:	 * drivers can use their completion handlers to ensure they keep bandwidth
 328:	 * they need, by reinitializing and resubmitting the just-completed urb
 329:	 * until the driver longer needs that periodic bandwidth.
 330:	 *
 331:	 * Memory Flags:
 332:	 *
 333:	 * The general rules for how to decide which mem_flags to use
 334:	 * are the same as for kmalloc.  There are four
 335:	 * different possible values; GFP_KERNEL, GFP_NOFS, GFP_NOIO and
 336:	 * GFP_ATOMIC.
 337:	 *
 338:	 * GFP_NOFS is not ever used, as it has not been implemented yet.
 339:	 *
 340:	 * GFP_ATOMIC is used when
 341:	 *   (a) you are inside a completion handler, an interrupt, bottom half,
 342:	 *       tasklet or timer, or
 343:	 *   (b) you are holding a spinlock or rwlock (does not apply to
 344:	 *       semaphores), or
 345:	 *   (c) current->state != TASK_RUNNING, this is the case only after
 346:	 *       you've changed it.
 347:	 *
 348:	 * GFP_NOIO is used in the block io path and error handling of storage
 349:	 * devices.
 350:	 *
 351:	 * All other situations use GFP_KERNEL.
 352:	 *
 353:	 * Some more specific rules for mem_flags can be inferred, such as
 354:	 *  (1) start_xmit, timeout, and receive methods of network drivers must
 355:	 *      use GFP_ATOMIC (they are called with a spinlock held);
 356:	 *  (2) queuecommand methods of scsi drivers must use GFP_ATOMIC (also
 357:	 *      called with a spinlock held);
 358:	 *  (3) If you use a kernel thread with a network driver you must use
 359:	 *      GFP_NOIO, unless (b) or (c) apply;
 360:	 *  (4) after you have done a down() you can use GFP_KERNEL, unless (b) or (c)
 361:	 *      apply or your are in a storage driver's block io path;
 362:	 *  (5) USB probe and disconnect can use GFP_KERNEL unless (b) or (c) apply; and
 363:	 *  (6) changing firmware on a running storage or net device uses
 364:	 *      GFP_NOIO, unless b) or c) apply
 365:	 *
 366:	 */
 367:	int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
 368:	{
 369:		int				xfertype, max;
 370:		struct usb_device		*dev;
 371:		struct usb_host_endpoint	*ep;
 372:		int				is_out;
 373:		unsigned int			allowed;
 374:		bool				is_eusb2_isoch_double;
 375:	
 376:		if (!urb || !urb->complete)
 377:			return -EINVAL;
 378:		if (urb->hcpriv) {
 379:			WARN_ONCE(1, "URB %p submitted while active\n", urb);
 380:			return -EBUSY;
 381:		}
 382:	
 383:		dev = urb->dev;
 384:		if ((!dev) || (dev->state < USB_STATE_UNAUTHENTICATED))
 385:			return -ENODEV;
 386:	
 387:		/* For now, get the endpoint from the pipe.  Eventually drivers
 388:		 * will be required to set urb->ep directly and we will eliminate
 389:		 * urb->pipe.
 390:		 */
 391:		ep = usb_pipe_endpoint(dev, urb->pipe);
 392:		if (!ep)
 393:			return -ENOENT;
 394:	
 395:		urb->ep = ep;
 396:		urb->status = -EINPROGRESS;
 397:		urb->actual_length = 0;
 398:	
 399:		/* Lots of sanity checks, so HCDs can rely on clean data
 400:		 * and don't need to duplicate tests
 401:		 */
 402:		xfertype = usb_endpoint_type(&ep->desc);
 403:		if (xfertype == USB_ENDPOINT_XFER_CONTROL) {
 404:			struct usb_ctrlrequest *setup =
 405:					(struct usb_ctrlrequest *) urb->setup_packet;
 406:	
 407:			if (!setup)
 408:				return -ENOEXEC;
 409:			is_out = !(setup->bRequestType & USB_DIR_IN) ||
 410:					!setup->wLength;
 411:			dev_WARN_ONCE(&dev->dev, (usb_pipeout(urb->pipe) != is_out),
 412:					"BOGUS control dir, pipe %x doesn't match bRequestType %x\n",
 413:					urb->pipe, setup->bRequestType);
 414:			if (le16_to_cpu(setup->wLength) != urb->transfer_buffer_length) {
 415:				dev_dbg(&dev->dev, "BOGUS control len %d doesn't match transfer length %d\n",
 416:						le16_to_cpu(setup->wLength),
 417:						urb->transfer_buffer_length);
 418:				return -EBADR;
 419:			}
 420:		} else {
 421:			is_out = usb_endpoint_dir_out(&ep->desc);
 422:		}
 423:	
 424:		/* Clear the internal flags and cache the direction for later use */
 425:		urb->transfer_flags &= ~(URB_DIR_MASK | URB_DMA_MAP_SINGLE |
 426:				URB_DMA_MAP_PAGE | URB_DMA_MAP_SG | URB_MAP_LOCAL |
 427:				URB_SETUP_MAP_SINGLE | URB_SETUP_MAP_LOCAL |
 428:				URB_DMA_SG_COMBINED);
 429:		urb->transfer_flags |= (is_out ? URB_DIR_OUT : URB_DIR_IN);
 430:		kmsan_handle_urb(urb, is_out);
 431:	
 432:		if (xfertype != USB_ENDPOINT_XFER_CONTROL &&
 433:				dev->state < USB_STATE_CONFIGURED)
 434:			return -ENODEV;
 435:	
 436:		max = usb_endpoint_maxp(&ep->desc);
 437:		is_eusb2_isoch_double = usb_endpoint_is_hs_isoc_double(dev, ep);
 438:		if (!max && !is_eusb2_isoch_double) {
 439:			dev_dbg(&dev->dev,
 440:				"bogus endpoint ep%d%s in %s (bad maxpacket %d)\n",
 441:				usb_endpoint_num(&ep->desc), is_out ? "out" : "in",
 442:				__func__, max);
 443:			return -EMSGSIZE;
 444:		}
 445:	
 446:		/* periodic transfers limit size per frame/uframe,
 447:		 * but drivers only control those sizes for ISO.
 448:		 * while we're checking, initialize return status.
 449:		 */
 450:		if (xfertype == USB_ENDPOINT_XFER_ISOC) {
 451:			int	n, len;
 452:	
 453:			/* SuperSpeed isoc endpoints have up to 16 bursts of up to
 454:			 * 3 packets each
 455:			 */
 456:			if (dev->speed >= USB_SPEED_SUPER) {
 457:				int     burst = 1 + ep->ss_ep_comp.bMaxBurst;
 458:				int     mult = USB_SS_MULT(ep->ss_ep_comp.bmAttributes);
 459:				max *= burst;
 460:				max *= mult;
 461:			}
 462:	
 463:			if (dev->speed == USB_SPEED_SUPER_PLUS &&
 464:			    USB_SS_SSP_ISOC_COMP(ep->ss_ep_comp.bmAttributes)) {
 465:				struct usb_ssp_isoc_ep_comp_descriptor *isoc_ep_comp;
 466:	
 467:				isoc_ep_comp = &ep->ssp_isoc_ep_comp;
 468:				max = le32_to_cpu(isoc_ep_comp->dwBytesPerInterval);
 469:			}
 470:	
 471:			/* High speed, 1-3 packets/uframe, max 6 for eUSB2 double bw */
 472:			if (dev->speed == USB_SPEED_HIGH) {
 473:				if (is_eusb2_isoch_double)
 474:					max = le32_to_cpu(ep->eusb2_isoc_ep_comp.dwBytesPerInterval);
 475:				else
 476:					max *= usb_endpoint_maxp_mult(&ep->desc);
 477:			}
 478:	
 479:			if (urb->number_of_packets <= 0)
 480:				return -EINVAL;
 481:			for (n = 0; n < urb->number_of_packets; n++) {
 482:				len = urb->iso_frame_desc[n].length;
 483:				if (len < 0 || len > max)
 484:					return -EMSGSIZE;
 485:				urb->iso_frame_desc[n].status = -EXDEV;
 486:				urb->iso_frame_desc[n].actual_length = 0;
 487:			}
 488:		} else if (urb->num_sgs && !urb->dev->bus->no_sg_constraint) {
 489:			struct scatterlist *sg;
 490:			int i;
 491:	
 492:			for_each_sg(urb->sg, sg, urb->num_sgs - 1, i)
 493:				if (sg->length % max)
 494:					return -EINVAL;
 495:		}
 496:	
 497:		/* the I/O buffer must be mapped/unmapped, except when length=0 */
 498:		if (urb->transfer_buffer_length > INT_MAX)
 499:			return -EMSGSIZE;
 500:	
 501:		/*
 502:		 * stuff that drivers shouldn't do, but which shouldn't
 503:		 * cause problems in HCDs if they get it wrong.
 504:		 */
 505:	
 506:		/* Check that the pipe's type matches the endpoint's type */
 507:		if (usb_pipe_type_check(urb->dev, urb->pipe))
 508:			dev_warn_once(&dev->dev, "BOGUS urb xfer, pipe %x != type %x\n",
 509:				usb_pipetype(urb->pipe), pipetypes[xfertype]);
 510:	
 511:		/* Check against a simple/standard policy */
 512:		allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK |
 513:				URB_FREE_BUFFER);
 514:		switch (xfertype) {
 515:		case USB_ENDPOINT_XFER_BULK:
 516:		case USB_ENDPOINT_XFER_INT:
 517:			if (is_out)
 518:				allowed |= URB_ZERO_PACKET;
 519:			fallthrough;
 520:		default:			/* all non-iso endpoints */
 521:			if (!is_out)
 522:				allowed |= URB_SHORT_NOT_OK;
 523:			break;
 524:		case USB_ENDPOINT_XFER_ISOC:
 525:			allowed |= URB_ISO_ASAP;
 526:			break;
 527:		}
 528:		allowed &= urb->transfer_flags;
 529:	
 530:		/* warn if submitter gave bogus flags */
 531:		if (allowed != urb->transfer_flags)
 532:			dev_WARN(&dev->dev, "BOGUS urb flags, %x --> %x\n",
 533:				urb->transfer_flags, allowed);
 534:	
 535:		/*
 536:		 * Force periodic transfer intervals to be legal values that are
 537:		 * a power of two (so HCDs don't need to).
 538:		 *
 539:		 * FIXME want bus->{intr,iso}_sched_horizon values here.  Each HC
 540:		 * supports different values... this uses EHCI/UHCI defaults (and
 541:		 * EHCI can use smaller non-default values).
 542:		 */
 543:		switch (xfertype) {
 544:		case USB_ENDPOINT_XFER_ISOC:
 545:		case USB_ENDPOINT_XFER_INT:
 546:			/* too small? */
 547:			if (urb->interval <= 0)
 548:				return -EINVAL;
 549:	
 550:			/* too big? */
 551:			switch (dev->speed) {
 552:			case USB_SPEED_SUPER_PLUS:
 553:			case USB_SPEED_SUPER:	/* units are 125us */
 554:				/* Handle up to 2^(16-1) microframes */
 555:				if (urb->interval > (1 << 15))
 556:					return -EINVAL;
 557:				max = 1 << 15;
 558:				break;
 559:			case USB_SPEED_HIGH:	/* units are microframes */
 560:				/* NOTE usb handles 2^15 */
 561:				if (urb->interval > (1024 * 8))
 562:					urb->interval = 1024 * 8;
 563:				max = 1024 * 8;
 564:				break;
 565:			case USB_SPEED_FULL:	/* units are frames/msec */
 566:			case USB_SPEED_LOW:
 567:				if (xfertype == USB_ENDPOINT_XFER_INT) {
 568:					if (urb->interval > 255)
 569:						return -EINVAL;
 570:					/* NOTE ohci only handles up to 32 */
 571:					max = 128;
 572:				} else {
 573:					if (urb->interval > 1024)
 574:						urb->interval = 1024;
 575:					/* NOTE usb and ohci handle up to 2^15 */
 576:					max = 1024;
 577:				}
 578:				break;
 579:			default:
 580:				return -EINVAL;
 581:			}
 582:			/* Round down to a power of 2, no more than max */
 583:			urb->interval = min(max, 1 << ilog2(urb->interval));
 584:		}
 585:	
 586:		return usb_hcd_submit_urb(urb, mem_flags);
 587:	}
 SourceFile:drivers/usb/core/urb.c]

gemini-3.1-pro-preview

							input: 126458
							output: 45
							thoughts: 520
						

**Analyzing the USB HID Initialization Flow**

Okay, let's break this down. My initial concern was about error handling during USB communication, specifically regarding the `usb_submit_urb` function. It seems this function has a check: `max = usb_endpoint_maxp(&ep->desc);` and if `max` is zero, it returns `-EMSGSIZE`. That means if `wMaxPacketSize` in the endpoint descriptor is zero, we'll get an error, right?

The question then becomes, where does this `-EMSGSIZE` error propagate? My initial thought was it would cascade into a failure within `usbhid_start`. But no, wait, `usbhid_start` doesn't call `usb_submit_urb` directly.

Instead, `usbhid_start` calls `hid_start_in(hid)` when the `HID_QUIRK_ALWAYS_POLL` quirk is set. *That's* the function which calls `usb_submit_urb` on the input urb: `usb_submit_urb(usbhid->urbin, GFP_KERNEL)`. Okay, so the `mcp2221` driver doesn't set `HID_QUIRK_ALWAYS_POLL`. Which means, `hid_start_in` is not called in `usbhid_start`.

So when does `hid_start_in` *actually* get called? Aha! It's when the device is opened. `mcp2221_probe` calls `hid_hw_open(hdev)`.  `hid_hw_open` then calls `usbhid_open`. `usbhid_open` calls `hid_start_in`!

Therefore, if `hid_start_in` fails, which means `usb_submit_urb` returns -EMSGSIZE, the error will be caught by `usbhid_open`. I'll need to check the `usbhid_open` function next to understand how it handles any errors returned by `hid_start_in`.

map[ContextFile:drivers/hid/usbhid/hid-core.c IncludeLines:true Name:usbhid_open]

map[SourceCode: 681:	static int usbhid_open(struct hid_device *hid)
 682:	{
 683:		struct usbhid_device *usbhid = hid->driver_data;
 684:		int res;
 685:	
 686:		mutex_lock(&usbhid->mutex);
 687:	
 688:		set_bit(HID_OPENED, &usbhid->iofl);
 689:	
 690:		if (hid->quirks & HID_QUIRK_ALWAYS_POLL) {
 691:			res = 0;
 692:			goto Done;
 693:		}
 694:	
 695:		res = usb_autopm_get_interface(usbhid->intf);
 696:		/* the device must be awake to reliably request remote wakeup */
 697:		if (res < 0) {
 698:			clear_bit(HID_OPENED, &usbhid->iofl);
 699:			res = -EIO;
 700:			goto Done;
 701:		}
 702:	
 703:		usbhid->intf->needs_remote_wakeup = 1;
 704:	
 705:		set_bit(HID_RESUME_RUNNING, &usbhid->iofl);
 706:		set_bit(HID_IN_POLLING, &usbhid->iofl);
 707:	
 708:		res = hid_start_in(hid);
 709:		if (res) {
 710:			if (res != -ENOSPC) {
 711:				hid_io_error(hid);
 712:				res = 0;
 713:			} else {
 714:				/* no use opening if resources are insufficient */
 715:				res = -EBUSY;
 716:				clear_bit(HID_OPENED, &usbhid->iofl);
 717:				clear_bit(HID_IN_POLLING, &usbhid->iofl);
 718:				usbhid->intf->needs_remote_wakeup = 0;
 719:			}
 720:		}
 721:	
 722:		usb_autopm_put_interface(usbhid->intf);
 723:	
 724:		/*
 725:		 * In case events are generated while nobody was listening,
 726:		 * some are released when the device is re-opened.
 727:		 * Wait 50 msec for the queue to empty before allowing events
 728:		 * to go through hid.
 729:		 */
 730:		if (res == 0)
 731:			msleep(50);
 732:	
 733:		clear_bit(HID_RESUME_RUNNING, &usbhid->iofl);
 734:	
 735:	 Done:
 736:		mutex_unlock(&usbhid->mutex);
 737:		return res;
 738:	}
 SourceFile:drivers/hid/usbhid/hid-core.c]

gemini-3.1-pro-preview

							input: 128320
							output: 1120
							thoughts: 16309
						

**Crash Analysis and Explanation**

Okay, here's what I've figured out. This crash is a nasty slab-out-of-bounds read, originating in the `mcp2221_raw_event` function within the MCP2221 HID driver. It all boils down to an integer underflow that leads to an out-of-bounds access.

First, the key line is the one where the code checks for `MCP2221_GPIO_SET` command. Inside that case we find this line: `(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)`. Now, the `mcp->gp_idx` member is critical here. It's a `u8` and, crucially, it's initialized to 0 when the mcp2221 struct is first allocated (using `devm_kzalloc`). This value of zero is only properly initialized with a value when `mcp_gpio_set` is called.

Here's the problem: if the device sends a specific input report (an `MCP2221_GPIO_SET` report), *before* any GPIO operations have occurred, `mcp->gp_idx` remains at its initial 0 value. The bug happens at that line: because `mcp->gp_idx` is `u8` type, the expression `mcp->gp_idx - 1` gets promoted to `int` and becomes -1.

Now, because `data` is a pointer to a `u8` buffer, this turns into accessing `data[-1]`. This is the crux of the problem!

Here's where the memory layout comes into play, and where KASAN picks up on it. The `data` pointer is just an alias for the `urb->transfer_buffer`, which is allocated using `kmalloc(64, GFP_KERNEL)`. This `kmalloc` call gets a new location in `kmalloc-64` cache.  Now, and this is the magic, `kmalloc` returns addresses at page boundary. This 64-byte object happened to be allocated at the beginning of a page, such as `ffff888111fe8000`.

The key is that the previous physical page (e.g., `ffff888111fe7000`) was, in this case, a part of the `task_struct` cache!

Now, when the code tries to access `data[-1]`, it reads the byte at `ffff888111fe7fff`—the very *last* byte of the *previous* page.

Here's how KASAN makes that connection: the address `ffff888111fe7fff` is recognized as being within a page belonging to the `task_struct` cache. KASAN calculates the difference, and because the last object in that page belongs to the `task_struct` cache, KASAN reports that this out-of-bounds read happens in context of that memory cache!

So in summary, the out of bounds access is caused by two fundamental problems:
1.  An integer underflow because of an uninitialized value in `mcp->gp_idx`.
2. No bounds checks in `mcp2221_raw_event` to ensure that size is appropriate for this data, and that `mcp->gp_idx` is actually a valid index.

map[KernelScratchSrc:/app/workdir/cache/tmp/tmp326899429]

gemini-3.1-pro-preview

You are an experienced Linux kernel developer tasked with creating a fix for a kernel bug.
You will be given a crash report, and an initial explanation of the root cause done by another
kernel expert.

Use the codeeditor tool to do code edits.
Note: you will not see your changes when looking at the code using codesearch tools.
Use the patch-diff tool to review the modifications you applied.

Your final reply should contain explanation of what you did in the patch and why
(details not present in the initial explanation of the bug).

Your fix must not just prevent the given crash, but also be the best fix for the underlying
root cause from the software engineering point of view. There can be several ways to fix the
same bug. Consider alternatives, and pick the best one. For example, additional checks may be
added at different locations/functions, it's usually better to place them earlier in the
execution to avoid multiple checks at various locations later.

Frequently the same coding mistake is done in several locations in the source code.
Check if your fix should be extended/applied to similar cases around to fix other similar bugs.
But don't go too wide, don't try to fix problems kernel-wide, fix similar issues
in the same file only.

If you are changing post-conditions of a function, consider all callers of the functions,
and if they need to be updated to handle new post-conditions. For example, if you make
a function that previously never returned a NULL, return NULL, consider if callers
need to be updated to handle NULL return value.



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

The crash that corresponds to the bug is:

==================================================================
BUG: KASAN: slab-out-of-bounds in mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
Read of size 1 at addr ffff888111fe7fff by task ktimers/0/16

CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted syzkaller #1 PREEMPT_{RT,(full)} 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description+0x55/0x1e0 mm/kasan/report.c:378
 print_report+0x58/0x70 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
 __hid_input_report+0x42b/0x590 drivers/hid/hid-core.c:2161
 hid_irq_in+0x495/0x710 drivers/hid/usbhid/hid-core.c:286
 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657
 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005
 __run_hrtimer kernel/time/hrtimer.c:1930 [inline]
 __hrtimer_run_queues+0x405/0xb10 kernel/time/hrtimer.c:1994
 hrtimer_run_softirq+0x18f/0x260 kernel/time/hrtimer.c:2011
 handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 run_ktimerd+0x69/0x100 kernel/softirq.c:1151
 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

Allocated by task 2:
 kasan_save_stack mm/kasan/common.c:57 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
 unpoison_slab_object mm/kasan/common.c:340 [inline]
 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
 kasan_slab_alloc include/linux/kasan.h:253 [inline]
 slab_post_alloc_hook mm/slub.c:4569 [inline]
 slab_alloc_node mm/slub.c:4898 [inline]
 kmem_cache_alloc_node_noprof+0x22a/0x6e0 mm/slub.c:4950
 alloc_task_struct_node kernel/fork.c:187 [inline]
 dup_task_struct+0x52/0x840 kernel/fork.c:918
 copy_process+0x89b/0x4450 kernel/fork.c:2090
 kernel_clone+0x283/0x870 kernel/fork.c:2721
 kernel_thread+0x13f/0x1b0 kernel/fork.c:2782
 create_kthread kernel/kthread.c:459 [inline]
 kthreadd+0x4ec/0x6e0 kernel/kthread.c:817
 ret_from_fork+0x514/0xb70 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 ffff888111fe5880
 which belongs to the cache task_struct of size 7296
The buggy address is located 2815 bytes to the right of
 allocated 7296-byte region [ffff888111fe5880, ffff888111fe7500)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x111fe0
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff888116e25541
flags: 0x100000000000040(head|node=0|zone=2)
page_type: f5(slab)
raw: 0100000000000040 ffff8881012e0500 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800040004 00000000f5000000 ffff888116e25541
head: 0100000000000040 ffff8881012e0500 dead000000000100 dead000000000122
head: 0000000000000000 0000000800040004 00000000f5000000 ffff888116e25541
head: 0100000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
head: 0000000000000000 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 2388, tgid 2388 (kworker/u9:11), ts 15402053339, free_ts 0
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1858
 prep_new_page mm/page_alloc.c:1866 [inline]
 get_page_from_freelist+0x27c8/0x2840 mm/page_alloc.c:3946
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5226
 alloc_slab_page mm/slub.c:3278 [inline]
 allocate_slab+0x77/0x660 mm/slub.c:3467
 new_slab mm/slub.c:3525 [inline]
 refill_objects+0x33c/0x3d0 mm/slub.c:7271
 refill_sheaf mm/slub.c:2816 [inline]
 __pcs_replace_empty_main+0x373/0x720 mm/slub.c:4651
 alloc_from_pcs mm/slub.c:4749 [inline]
 slab_alloc_node mm/slub.c:4883 [inline]
 kmem_cache_alloc_node_noprof+0x4f4/0x6e0 mm/slub.c:4950
 alloc_task_struct_node kernel/fork.c:187 [inline]
 dup_task_struct+0x52/0x840 kernel/fork.c:918
 copy_process+0x89b/0x4450 kernel/fork.c:2090
 kernel_clone+0x283/0x870 kernel/fork.c:2721
 user_mode_thread+0x110/0x180 kernel/fork.c:2797
 call_usermodehelper_exec_work+0x5c/0x230 kernel/umh.c:171
 process_one_work kernel/workqueue.c:3314 [inline]
 process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397
 worker_thread+0x8a2/0xda0 kernel/workqueue.c:3478
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
page_owner free stack trace missing

Memory state around the buggy address:
 ffff888111fe7e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff888111fe7f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888111fe7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                ^
 ffff888111fe8000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff888111fe8080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================


The explanation of the root cause of the bug is:

An analysis of the crash report and the source code reveals that the root cause is an **out-of-bounds read due to a negative array index** in `mcp2221_raw_event()`, combined with a lack of bounds checking on the incoming HID report size.

### Detailed Explanation

1. **Uninitialized State**: 
   When the `mcp2221` device is probed, its state structure is allocated using `devm_kzalloc()`, which zero-initializes all fields. The `mcp->gp_idx` field (a `u8`) is initialized to `0`. It is only updated to a valid positive offset (e.g., 3, 7, 11, or 15) when the GPIO subsystem invokes the driver's GPIO operations like `mcp_gpio_set()`.

2. **The Vulnerability**:
   If the device sends an `MCP2221_GPIO_SET` (0x50) input report *before* any GPIO operations are performed (or if a malicious device/reproducer injects one), `mcp2221_raw_event()` processes the report while `mcp->gp_idx` is still `0`.
   
   Looking at `drivers/hid/hid-mcp2221.c` around line 964:
   ```c
   960:		case MCP2221_GPIO_SET:
   961:			switch (data[1]) {
   962:			case MCP2221_SUCCESS:
   963:				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
   964:					(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
   ```
   Because `mcp->gp_idx` is `0`, the expression `mcp->gp_idx - 1` promotes the `u8` to an `int`, resulting in `-1`. This causes the code to access `data[-1]`.

3. **Memory Layout and the KASAN Report**:
   The `data` pointer passed to `mcp2221_raw_event()` points to the URB transfer buffer, which is allocated by the USB core via `kmalloc()` (e.g., from the `kmalloc-64` cache). 
   
   In the crashing scenario, the SLUB allocator placed this 64-byte buffer at the very beginning of a new page, exactly at address `ffff888111fe8000`. 
   
   When the code evaluates `data[-1]`, it reads the address `ffff888111fe7fff`. This address is the last byte of the *previous* physical page. As shown in the KASAN report, the previous page (`pfn:0x111fe0`) was an order-3 slab page belonging to the `task_struct` cache. The last `task_struct` object in that page ended at `ffff888111fe7500`, and the remainder of the page was SLUB padding/redzone (filled with `fc`).
   
   KASAN intercepted the read at `ffff888111fe7fff` and correctly reported it as a slab-out-of-bounds read located 2815 bytes to the right of the `task_struct` object.

   ```text
    ffff888111fe7f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
   >ffff888111fe7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                   ^ (data[-1] at ffff888111fe7fff)
    ffff888111fe8000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  <-- data (urb->transfer_buffer)
   ```

### How to Fix

To fix this bug, `mcp2221_raw_event()` needs two corrections:
1. **Validate `mcp->gp_idx`**: Ensure that `mcp->gp_idx` is valid (e.g., `mcp->gp_idx > 0`) before using it as an array index.
2. **Bounds Checking**: The function completely lacks bounds checking on the `size` parameter. It blindly accesses `data[0]`, `data[1]`, and various other offsets (like `data[50]` in the `MCP2221_I2C_PARAM_OR_STATUS` case). It should verify that `size` is large enough for the specific report being processed before accessing the `data` array.

An analysis of the crash report and the driver's source code reveals that the root cause is an out-of-bounds read due to a negative array index in `mcp2221_raw_event()`, combined with a lack of bounds checking on the incoming HID report size.

### Detailed Explanation

1. **Uninitialized State & Stray Reports**: 
   When the `mcp2221` device is probed, its state structure is allocated using `devm_kzalloc()`, which zero-initializes all fields. The `mcp->gp_idx` field is initialized to `0`. It is only updated to a valid positive offset when the GPIO subsystem invokes the driver's GPIO operations (like `mcp_gpio_set()`).
   The `mcp2221_raw_event()` function is called for any incoming HID input report. It blindly processes the report based on the command byte `data[0]`, without verifying if the report is actually a response to the command the driver just sent.

2. **The Vulnerability**:
   If the device sends an `MCP2221_GPIO_SET` (0x50) input report *before* any GPIO operations are performed (or if a malicious device/reproducer injects one), `mcp2221_raw_event()` processes the report while `mcp->gp_idx` is still `0`.
   Because `mcp->gp_idx` is `0`, the expression `mcp->gp_idx - 1` results in `-1`, causing the code to access `data[-1]`. This reads out of the bounds of the URB transfer buffer, triggering the KASAN slab-out-of-bounds report.

3. **Lack of Bounds Checking**:
   The function completely lacks bounds checking on the `size` parameter. It blindly accesses various offsets (like `data[50]` in the `MCP2221_I2C_PARAM_OR_STATUS` case). The expected report size for MCP2221 is 64 bytes.

### The Fix

To fix this bug comprehensively, we need to ensure that `mcp2221_raw_event()` only processes valid responses to the currently pending command, and that the report size is correct.

1. **Size Validation**: We add a check to ensure `size >= 64` at the beginning of the function. If the size is smaller, we ignore the report.
2. **Command Validation**: The driver always stores the command byte it sends in `mcp->txbuf[0]`. The MCP2221 device always echoes this command byte in the first byte of its response (`data[0]`). By checking `if (data[0] != mcp->txbuf[0])`, we can safely ignore any stray, delayed, or malicious reports that do not match the currently pending command.
   Since `mcp->txbuf[0]` and `mcp->gp_idx` are always set together when sending GPIO commands, this check inherently guarantees that `mcp->gp_idx` is valid and correctly initialized for the specific command being processed, preventing the `-1` index access.

I have applied the following patch to `drivers/hid/hid-mcp2221.c`:

```c
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -858,6 +858,12 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 	u8 *buf;
 	struct mcp2221 *mcp = hid_get_drvdata(hdev);
 
+	if (unlikely(size < 64))
+		return 1;
+
+	if (data[0] != mcp->txbuf[0])
+		return 1;
+
 	switch (data[0]) {
 
 	case MCP2221_I2C_WR_DATA:
```

gemini-3.1-pro-preview

							input: 8031
							output: 33
							thoughts: 123
						

**Analyzing a KASAN Slab-Out-of-Bounds Read in the MCP2221 Driver**

Okay, so I'm seeing a KASAN slab-out-of-bounds read error, specifically in the `mcp2221_raw_event` function within the `hid-mcp2221.c` driver at line 964. The root of the problem seems to be an issue with how the driver is handling a General Purpose (GP) pin index. It looks like `mcp->gp_idx` is being set to 0. Consequently, when the code tries to access `data[mcp->gp_idx - 1]`, it's effectively doing `data[-1]`, which is, of course, a memory access outside of the allocated bounds. This is a classic off-by-one or underflow error.

Furthermore, it looks like there's also a lack of adequate bounds checking on the `size` variable. This suggests a potential weakness or another entry point for issues if `size` is not validated correctly.

My next step is to dive right into the `drivers/hid/hid-mcp2221.c` source code and see exactly how `mcp->gp_idx` is being determined and how the `size` parameter is handled. I need to understand the control flow leading to this access to fully understand the vulnerability. I'll be looking for where `mcp->gp_idx` is initialized, potentially within other functions within the driver, and where `size` is coming from. Time to dig in and pinpoint the problematic logic.

map[SourceFile:drivers/hid/hid-mcp2221.c]

map[Entities:[map[Kind:function Name:__check_gpio_mode_enforce] map[Kind:function Name:mcp2221_check_gpio_pinfunc] map[Kind:function Name:mcp2221_driver_exit] map[Kind:function Name:mcp2221_driver_init] map[Kind:function Name:mcp2221_hid_unregister] map[Kind:function Name:mcp2221_probe] map[Kind:function Name:mcp2221_raw_event] map[Kind:function Name:mcp2221_read_raw] map[Kind:function Name:mcp2221_remove] map[Kind:function Name:mcp2221_write_raw] map[Kind:function Name:mcp_cancel_last_cmd] map[Kind:function Name:mcp_chk_last_cmd_status] map[Kind:function Name:mcp_chk_last_cmd_status_free_bus] map[Kind:function Name:mcp_get_i2c_eng_state] map[Kind:function Name:mcp_gpio_dir_set] map[Kind:function Name:mcp_gpio_direction_input] map[Kind:function Name:mcp_gpio_direction_output] map[Kind:function Name:mcp_gpio_get] map[Kind:function Name:mcp_gpio_get_direction] map[Kind:function Name:mcp_gpio_read_sram] map[Kind:function Name:mcp_gpio_set] map[Kind:function Name:mcp_i2c_func] map[Kind:function Name:mcp_i2c_smbus_read] map[Kind:function Name:mcp_i2c_write] map[Kind:function Name:mcp_i2c_xfer] map[Kind:function Name:mcp_iio_channels] map[Kind:function Name:mcp_init_work] map[Kind:function Name:mcp_send_data_req_status] map[Kind:function Name:mcp_send_report] map[Kind:function Name:mcp_set_i2c_speed] map[Kind:function Name:mcp_smbus_write] map[Kind:function Name:mcp_smbus_xfer] map[Kind:struct Name:mcp2221] map[Kind:struct Name:mcp2221_iio] map[Kind:struct Name:mcp_get_gpio] map[Kind:struct Name:mcp_set_gpio] map[Kind:global_variable Name:__UNIQUE_ID_addressable_mcp2221_driver_init_1028] map[Kind:global_variable Name:__UNIQUE_ID_modinfo_1004] map[Kind:global_variable Name:__UNIQUE_ID_modinfo_1005] map[Kind:global_variable Name:__UNIQUE_ID_modinfo_1029] map[Kind:global_variable Name:__UNIQUE_ID_modinfo_1030] map[Kind:global_variable Name:__UNIQUE_ID_modinfo_1031] map[Kind:global_variable Name:__UNIQUE_ID_modinfo_1032] map[Kind:global_variable Name:__exitcall_mcp2221_driver_exit] map[Kind:global_variable Name:__mod_device_table__kmod_hid_mcp2221__hid__mcp2221_devices] map[Kind:global_variable Name:__param_gpio_mode_enforce] map[Kind:global_variable Name:__param_str_gpio_mode_enforce] map[Kind:global_variable Name:i2c_clk_freq] map[Kind:global_variable Name:mcp2221_devices] map[Kind:global_variable Name:mcp2221_driver] map[Kind:global_variable Name:mcp2221_info] map[Kind:global_variable Name:mcp_i2c_algo]]]

gemini-3.1-pro-preview

							input: 9661
							output: 53
							thoughts: 34
						

Here's my analysis of the provided text, structured as a first-person expert summary:

**Diving into the HID Driver for the MCP2221**

Okay, so we're talking about the `mcp2221_raw_event` function within the `hid-mcp2221.c` file, specifically in the `drivers/hid` directory. This tells me we're looking at the core event handling for a Human Interface Device (HID) that utilizes the MCP2221 USB-to-I2C/UART converter chip. My assumption is that the raw event processing here is where the driver interacts directly with the incoming data from the MCP2221. It's likely involved in interpreting the raw USB reports, translating them into meaningful HID events that the system understands. I'll be interested to see how the driver handles data buffering, interrupt handling (if applicable), and any specific hardware quirks or timing considerations of the MCP2221 itself within this function. I'll need to carefully examine what sort of filtering, scaling, or translation happens here to ensure that valid, interpretable HID data gets passed upstream to the input subsystem.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp2221_raw_event]

map[SourceCode: 849:	/*
 850:	 * MCP2221 uses interrupt endpoint for input reports. This function
 851:	 * is called by HID layer when it receives i/p report from mcp2221,
 852:	 * which is actually a response to the previously sent command.
 853:	 *
 854:	 * MCP2221A firmware specific return codes are parsed and 0 or
 855:	 * appropriate negative error code is returned. Delayed response
 856:	 * results in timeout error and stray reponses results in -EIO.
 857:	 */
 858:	static int mcp2221_raw_event(struct hid_device *hdev,
 859:					struct hid_report *report, u8 *data, int size)
 860:	{
 861:		u8 *buf;
 862:		struct mcp2221 *mcp = hid_get_drvdata(hdev);
 863:	
 864:		switch (data[0]) {
 865:	
 866:		case MCP2221_I2C_WR_DATA:
 867:		case MCP2221_I2C_WR_NO_STOP:
 868:		case MCP2221_I2C_RD_DATA:
 869:		case MCP2221_I2C_RD_RPT_START:
 870:			switch (data[1]) {
 871:			case MCP2221_SUCCESS:
 872:				mcp->status = 0;
 873:				break;
 874:			default:
 875:				mcp->status = mcp_get_i2c_eng_state(mcp, data, 2);
 876:			}
 877:			complete(&mcp->wait_in_report);
 878:			break;
 879:	
 880:		case MCP2221_I2C_PARAM_OR_STATUS:
 881:			switch (data[1]) {
 882:			case MCP2221_SUCCESS:
 883:				if ((mcp->txbuf[3] == MCP2221_I2C_SET_SPEED) &&
 884:					(data[3] != MCP2221_I2C_SET_SPEED)) {
 885:					mcp->status = -EAGAIN;
 886:					break;
 887:				}
 888:				if (data[20] & MCP2221_I2C_MASK_ADDR_NACK) {
 889:					mcp->status = -ENXIO;
 890:					break;
 891:				}
 892:				mcp->status = mcp_get_i2c_eng_state(mcp, data, 8);
 893:	#if IS_REACHABLE(CONFIG_IIO)
 894:				memcpy(&mcp->adc_values, &data[50], sizeof(mcp->adc_values));
 895:	#endif
 896:				break;
 897:			default:
 898:				mcp->status = -EIO;
 899:			}
 900:			complete(&mcp->wait_in_report);
 901:			break;
 902:	
 903:		case MCP2221_I2C_GET_DATA:
 904:			switch (data[1]) {
 905:			case MCP2221_SUCCESS:
 906:				if (data[2] == MCP2221_I2C_ADDR_NACK) {
 907:					mcp->status = -ENXIO;
 908:					break;
 909:				}
 910:				if (!mcp_get_i2c_eng_state(mcp, data, 2)
 911:					&& (data[3] == 0)) {
 912:					mcp->status = 0;
 913:					break;
 914:				}
 915:				if (data[3] == 127) {
 916:					mcp->status = -EIO;
 917:					break;
 918:				}
 919:				if (data[2] == MCP2221_I2C_READ_COMPL ||
 920:				    data[2] == MCP2221_I2C_READ_PARTIAL) {
 921:					if (!mcp->rxbuf || mcp->rxbuf_idx < 0 || data[3] > 60) {
 922:						mcp->status = -EINVAL;
 923:						break;
 924:					}
 925:					if (mcp->rxbuf_idx + data[3] > mcp->rxbuf_size) {
 926:						mcp->status = -EINVAL;
 927:						break;
 928:					}
 929:					buf = mcp->rxbuf;
 930:					memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
 931:					mcp->rxbuf_idx = mcp->rxbuf_idx + data[3];
 932:					mcp->status = 0;
 933:					break;
 934:				}
 935:				mcp->status = -EIO;
 936:				break;
 937:			default:
 938:				mcp->status = -EIO;
 939:			}
 940:			complete(&mcp->wait_in_report);
 941:			break;
 942:	
 943:		case MCP2221_GPIO_GET:
 944:			switch (data[1]) {
 945:			case MCP2221_SUCCESS:
 946:				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
 947:					(data[mcp->gp_idx + 1] == MCP2221_ALT_F_NOT_GPIOD)) {
 948:					mcp->status = -ENOENT;
 949:				} else {
 950:					mcp->status = !!data[mcp->gp_idx];
 951:					mcp->gpio_dir = data[mcp->gp_idx + 1];
 952:				}
 953:				break;
 954:			default:
 955:				mcp->status = -EAGAIN;
 956:			}
 957:			complete(&mcp->wait_in_report);
 958:			break;
 959:	
 960:		case MCP2221_GPIO_SET:
 961:			switch (data[1]) {
 962:			case MCP2221_SUCCESS:
 963:				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
 964:					(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
 965:					mcp->status = -ENOENT;
 966:				} else {
 967:					mcp->status = 0;
 968:				}
 969:				break;
 970:			default:
 971:				mcp->status = -EAGAIN;
 972:			}
 973:			complete(&mcp->wait_in_report);
 974:			break;
 975:	
 976:		case MCP2221_SET_SRAM_SETTINGS:
 977:			switch (data[1]) {
 978:			case MCP2221_SUCCESS:
 979:				mcp->status = 0;
 980:				break;
 981:			default:
 982:				mcp->status = -EAGAIN;
 983:			}
 984:			complete(&mcp->wait_in_report);
 985:			break;
 986:	
 987:		case MCP2221_GET_SRAM_SETTINGS:
 988:			switch (data[1]) {
 989:			case MCP2221_SUCCESS:
 990:				memcpy(&mcp->mode, &data[22], 4);
 991:	#if IS_REACHABLE(CONFIG_IIO)
 992:				mcp->dac_value = data[6] & GENMASK(4, 0);
 993:	#endif
 994:				mcp->status = 0;
 995:				break;
 996:			default:
 997:				mcp->status = -EAGAIN;
 998:			}
 999:			complete(&mcp->wait_in_report);
1000:			break;
1001:	
1002:		case MCP2221_READ_FLASH_DATA:
1003:			switch (data[1]) {
1004:			case MCP2221_SUCCESS:
1005:				mcp->status = 0;
1006:	
1007:				/* Only handles CHIP SETTINGS subpage currently */
1008:				if (mcp->txbuf[1] != 0) {
1009:					mcp->status = -EIO;
1010:					break;
1011:				}
1012:	
1013:	#if IS_REACHABLE(CONFIG_IIO)
1014:				{
1015:					u8 tmp;
1016:					/* DAC scale value */
1017:					tmp = FIELD_GET(GENMASK(7, 6), data[6]);
1018:					if ((data[6] & BIT(5)) && tmp)
1019:						mcp->dac_scale = tmp + 4;
1020:					else
1021:						mcp->dac_scale = 5;
1022:	
1023:					/* ADC scale value */
1024:					tmp = FIELD_GET(GENMASK(4, 3), data[7]);
1025:					if ((data[7] & BIT(2)) && tmp)
1026:						mcp->adc_scale = tmp - 1;
1027:					else
1028:						mcp->adc_scale = 0;
1029:				}
1030:	#endif
1031:	
1032:				break;
1033:			default:
1034:				mcp->status = -EAGAIN;
1035:			}
1036:			complete(&mcp->wait_in_report);
1037:			break;
1038:	
1039:		default:
1040:			mcp->status = -EIO;
1041:			complete(&mcp->wait_in_report);
1042:		}
1043:	
1044:		return 1;
1045:	}
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 13037
							output: 21
							thoughts: 173
						

**Analyzing the MCP2221 Raw Event Handler**

Okay, so I'm looking at this `mcp2221_raw_event` function, and the first thing that jumps out at me is that it doesn't seem to validate the `size` parameter at all. It just blindly accepts whatever data is thrown at it. Now, I know the report size for the MCP2221 is typically 64 bytes. That's the expected size.

Since this is an HID raw event callback, I need to understand what happens with smaller reports. If `size` is less than 64, what should we do? Should we return a value that signifies whether it handled it, or not? My initial instinct is that if the size is too small, a return of 0 or 1 is likely appropriate - but I need to make sure I understand what those return values mean. A return of 0 generally signifies that the event wasn't handled, and returning a 1 would mean it was handled, right? In this case, if the size is wrong, we probably want to *not* handle it.

To be sure, I should check how other HID drivers handle this scenario. Seeing how they deal with this should provide some clarity on the best approach here.

requested entity does not exist

map[Name:raw_event]

map[References:<nil> TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 13523
							output: 25
							thoughts: 17
						

Here's my take on the thought process, as if I were the one thinking it:

**Digging into the `hid_driver` Structure**

Okay, let me just double-check that... wait a minute! Is that right? I think I've got it, yes! `raw_event`... it's actually a *field* within the `struct hid_driver`. That's a crucial piece of information. This changes the way I need to approach this analysis. It means... right, it means I need to look at how this struct is actually used within the broader HID driver framework. Knowing it's embedded within `hid_driver` will influence how I trace its origin, how it's initialized, and how it is ultimately handled. This is significant because...

map[Name:hid_driver::raw_event]

map[References:[map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:__hid_input_report SourceFile:drivers/hid/hid-core.c SourceLine:2160] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:__hid_input_report SourceFile:drivers/hid/hid-core.c SourceLine:2161] map[ReferenceKind:reads ReferencingEntityKind:function ReferencingEntityName:hid_connect SourceFile:drivers/hid/hid-core.c SourceLine:2324]] TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 13907
							output: 44
							thoughts: 24
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Diving into `hid-core.c`**

Okay, time to investigate how HID input reports are handled at the core level. I need to refresh my memory on the data flow. My immediate focus is `__hid_input_report` within `drivers/hid/hid-core.c`. This function is fundamental to the entire HID subsystem's operation, acting as the nexus for interpreting the incoming data from a HID device and making it available to the rest of the kernel. I'm especially interested in how it deals with different report types, how it validates the data (or doesn't!), and how it ultimately translates these raw reports into usable input events. I want to see how it interacts with the report descriptors and whether there are potential weaknesses in the decoding/parsing stages that could lead to vulnerabilities. I'm also curious about its performance characteristics under heavy load from multiple HID devices. Time to dig in!

map[ContextFile:drivers/hid/hid-core.c IncludeLines:true Name:__hid_input_report]

map[SourceCode:2109:	static int __hid_input_report(struct hid_device *hid, enum hid_report_type type,
2110:				      u8 *data, size_t bufsize, u32 size, int interrupt, u64 source,
2111:				      bool from_bpf, bool lock_already_taken)
2112:	{
2113:		struct hid_report_enum *report_enum;
2114:		struct hid_driver *hdrv;
2115:		struct hid_report *report;
2116:		int ret = 0;
2117:	
2118:		if (!hid)
2119:			return -ENODEV;
2120:	
2121:		ret = down_trylock(&hid->driver_input_lock);
2122:		if (lock_already_taken && !ret) {
2123:			up(&hid->driver_input_lock);
2124:			return -EINVAL;
2125:		} else if (!lock_already_taken && ret) {
2126:			return -EBUSY;
2127:		}
2128:	
2129:		if (!hid->driver) {
2130:			ret = -ENODEV;
2131:			goto unlock;
2132:		}
2133:		report_enum = hid->report_enum + type;
2134:		hdrv = hid->driver;
2135:	
2136:		data = dispatch_hid_bpf_device_event(hid, type, data, &bufsize, &size, interrupt,
2137:						     source, from_bpf);
2138:		if (IS_ERR(data)) {
2139:			ret = PTR_ERR(data);
2140:			goto unlock;
2141:		}
2142:	
2143:		if (!size) {
2144:			dbg_hid("empty report\n");
2145:			ret = -1;
2146:			goto unlock;
2147:		}
2148:	
2149:		/* Avoid unnecessary overhead if debugfs is disabled */
2150:		if (!list_empty(&hid->debug_list))
2151:			hid_dump_report(hid, type, data, size);
2152:	
2153:		report = hid_get_report(report_enum, data);
2154:	
2155:		if (!report) {
2156:			ret = -1;
2157:			goto unlock;
2158:		}
2159:	
2160:		if (hdrv && hdrv->raw_event && hid_match_report(hid, report)) {
2161:			ret = hdrv->raw_event(hid, report, data, size);
2162:			if (ret < 0)
2163:				goto unlock;
2164:		}
2165:	
2166:		ret = hid_report_raw_event(hid, type, data, bufsize, size, interrupt);
2167:	
2168:	unlock:
2169:		if (!lock_already_taken)
2170:			up(&hid->driver_input_lock);
2171:		return ret;
2172:	}
 SourceFile:drivers/hid/hid-core.c]

gemini-3.1-pro-preview

							input: 15111
							output: 51
							thoughts: 418
						

**Analyzing the HID Event Processing Flow**

Okay, so I'm diving into this HID event processing logic. My immediate concern is how the return values from `hdrv->raw_event` are handled. It seems that if it returns a negative value, it's supposed to halt the processing and proceed to unlock something. A return of 0 means continue. A return of anything greater than 0 also continues, right? But then the code moves to `hid_report_raw_event`. Let's clarify. If `ret < 0` goes to unlock, but if `mcp2221_raw_event` returns 1, does that also continue?

Now, the `mcp2221_raw_event` function itself is a bit confusing. The comment in the code says it handles input reports from the MCP2221, which are responses to previously sent commands. Okay, so far so good. It parses firmware-specific return codes and either returns 0 or a negative error code. But then, at the very end of the function, it returns 1. That's where I get lost.

The comment implies that the function returns an error code, yet it returns 1. If it returns 1, the event is handled, and shouldn't be passed on to generic HID input processing, right? Okay, so if `mcp2221_raw_event` returns 1, then `ret` becomes 1, and the program flow does continue to `hid_report_raw_event`. So, if the return is positive, it means it continues, not that the events handled and we skip this.

Also, what happens if the report size is too small? What's the expected behavior there? Should it return 0? We need to look at what size the function is expecting. The MCP2221 report size is supposed to be 64 bytes. I should check `mcp2221_probe` or a similar function to see how the report size is actually configured.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp2221_probe]

map[SourceCode:1237:	static int mcp2221_probe(struct hid_device *hdev,
1238:						const struct hid_device_id *id)
1239:	{
1240:		int ret;
1241:		struct mcp2221 *mcp;
1242:	
1243:		mcp = devm_kzalloc(&hdev->dev, sizeof(*mcp), GFP_KERNEL);
1244:		if (!mcp)
1245:			return -ENOMEM;
1246:	
1247:		ret = hid_parse(hdev);
1248:		if (ret) {
1249:			hid_err(hdev, "can't parse reports\n");
1250:			return ret;
1251:		}
1252:	
1253:		/*
1254:		 * This driver uses the .raw_event callback and therefore does not need any
1255:		 * HID_CONNECT_xxx flags.
1256:		 */
1257:		ret = hid_hw_start(hdev, 0);
1258:		if (ret) {
1259:			hid_err(hdev, "can't start hardware\n");
1260:			return ret;
1261:		}
1262:	
1263:		hid_info(hdev, "USB HID v%x.%02x Device [%s] on %s\n", hdev->version >> 8,
1264:				hdev->version & 0xff, hdev->name, hdev->phys);
1265:	
1266:		ret = hid_hw_open(hdev);
1267:		if (ret) {
1268:			hid_err(hdev, "can't open device\n");
1269:			hid_hw_stop(hdev);
1270:			return ret;
1271:		}
1272:	
1273:		mutex_init(&mcp->lock);
1274:		init_completion(&mcp->wait_in_report);
1275:		hid_set_drvdata(hdev, mcp);
1276:		mcp->hdev = hdev;
1277:	
1278:		ret = devm_add_action_or_reset(&hdev->dev, mcp2221_hid_unregister, hdev);
1279:		if (ret)
1280:			return ret;
1281:	
1282:		hid_device_io_start(hdev);
1283:	
1284:		/* Set I2C bus clock diviser */
1285:		if (i2c_clk_freq > 400)
1286:			i2c_clk_freq = 400;
1287:		if (i2c_clk_freq < 50)
1288:			i2c_clk_freq = 50;
1289:		mcp->cur_i2c_clk_div = (12000000 / (i2c_clk_freq * 1000)) - 3;
1290:		ret = mcp_set_i2c_speed(mcp);
1291:		if (ret) {
1292:			hid_err(hdev, "can't set i2c speed: %d\n", ret);
1293:			return ret;
1294:		}
1295:	
1296:		mcp->adapter.owner = THIS_MODULE;
1297:		mcp->adapter.class = I2C_CLASS_HWMON;
1298:		mcp->adapter.algo = &mcp_i2c_algo;
1299:		mcp->adapter.retries = 1;
1300:		mcp->adapter.dev.parent = &hdev->dev;
1301:		ACPI_COMPANION_SET(&mcp->adapter.dev, ACPI_COMPANION(hdev->dev.parent));
1302:		snprintf(mcp->adapter.name, sizeof(mcp->adapter.name),
1303:				"MCP2221 usb-i2c bridge");
1304:	
1305:		i2c_set_adapdata(&mcp->adapter, mcp);
1306:		ret = devm_i2c_add_adapter(&hdev->dev, &mcp->adapter);
1307:		if (ret) {
1308:			hid_err(hdev, "can't add usb-i2c adapter: %d\n", ret);
1309:			return ret;
1310:		}
1311:	
1312:	#if IS_REACHABLE(CONFIG_GPIOLIB)
1313:		/* Setup GPIO chip */
1314:		mcp->gc = devm_kzalloc(&hdev->dev, sizeof(*mcp->gc), GFP_KERNEL);
1315:		if (!mcp->gc)
1316:			return -ENOMEM;
1317:	
1318:		mcp->gc->label = "mcp2221_gpio";
1319:		mcp->gc->direction_input = mcp_gpio_direction_input;
1320:		mcp->gc->direction_output = mcp_gpio_direction_output;
1321:		mcp->gc->get_direction = mcp_gpio_get_direction;
1322:		mcp->gc->set = mcp_gpio_set;
1323:		mcp->gc->get = mcp_gpio_get;
1324:		mcp->gc->ngpio = MCP_NGPIO;
1325:		mcp->gc->base = -1;
1326:		mcp->gc->can_sleep = 1;
1327:		mcp->gc->parent = &hdev->dev;
1328:	
1329:		ret = devm_gpiochip_add_data(&hdev->dev, mcp->gc, mcp);
1330:		if (ret)
1331:			return ret;
1332:	
1333:		mcp2221_check_gpio_pinfunc(mcp);
1334:	#endif
1335:	
1336:	#if IS_REACHABLE(CONFIG_IIO)
1337:		if (!gpio_mode_enforce) {
1338:			INIT_DELAYED_WORK(&mcp->init_work, mcp_init_work);
1339:			schedule_delayed_work(&mcp->init_work, msecs_to_jiffies(100));
1340:		}
1341:	#endif
1342:	
1343:		return 0;
1344:	}
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 17877
							output: 53
							thoughts: 36
						

Okay, here's my interpretation of those thoughts, tailored for an expert audience:

**Analyzing MCP2221 Data Transfer Constraints**

Alright, the critical constraint I need to keep in mind is the 64-byte fixed report size for the MCP2221. That limitation immediately dictates how I approach the data structures and transfer protocols. I can't afford to overshoot that size; padding, fragmentation, or complex framing techniques become necessary if I need to send more. 

Given this context, I need to revisit my understanding and assumptions about the `mcp2221_raw_event` structure. Are there any hidden inefficiencies or potential for exceeding that 64-byte boundary that I might have overlooked during the initial design? It’s time for a thorough review; I need to ensure that the current implementation is optimally sized and doesn't introduce any unforeseen issues down the line. I must re-examine it with this hard limit firmly in my mind.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp2221_raw_event]

map[SourceCode: 849:	/*
 850:	 * MCP2221 uses interrupt endpoint for input reports. This function
 851:	 * is called by HID layer when it receives i/p report from mcp2221,
 852:	 * which is actually a response to the previously sent command.
 853:	 *
 854:	 * MCP2221A firmware specific return codes are parsed and 0 or
 855:	 * appropriate negative error code is returned. Delayed response
 856:	 * results in timeout error and stray reponses results in -EIO.
 857:	 */
 858:	static int mcp2221_raw_event(struct hid_device *hdev,
 859:					struct hid_report *report, u8 *data, int size)
 860:	{
 861:		u8 *buf;
 862:		struct mcp2221 *mcp = hid_get_drvdata(hdev);
 863:	
 864:		switch (data[0]) {
 865:	
 866:		case MCP2221_I2C_WR_DATA:
 867:		case MCP2221_I2C_WR_NO_STOP:
 868:		case MCP2221_I2C_RD_DATA:
 869:		case MCP2221_I2C_RD_RPT_START:
 870:			switch (data[1]) {
 871:			case MCP2221_SUCCESS:
 872:				mcp->status = 0;
 873:				break;
 874:			default:
 875:				mcp->status = mcp_get_i2c_eng_state(mcp, data, 2);
 876:			}
 877:			complete(&mcp->wait_in_report);
 878:			break;
 879:	
 880:		case MCP2221_I2C_PARAM_OR_STATUS:
 881:			switch (data[1]) {
 882:			case MCP2221_SUCCESS:
 883:				if ((mcp->txbuf[3] == MCP2221_I2C_SET_SPEED) &&
 884:					(data[3] != MCP2221_I2C_SET_SPEED)) {
 885:					mcp->status = -EAGAIN;
 886:					break;
 887:				}
 888:				if (data[20] & MCP2221_I2C_MASK_ADDR_NACK) {
 889:					mcp->status = -ENXIO;
 890:					break;
 891:				}
 892:				mcp->status = mcp_get_i2c_eng_state(mcp, data, 8);
 893:	#if IS_REACHABLE(CONFIG_IIO)
 894:				memcpy(&mcp->adc_values, &data[50], sizeof(mcp->adc_values));
 895:	#endif
 896:				break;
 897:			default:
 898:				mcp->status = -EIO;
 899:			}
 900:			complete(&mcp->wait_in_report);
 901:			break;
 902:	
 903:		case MCP2221_I2C_GET_DATA:
 904:			switch (data[1]) {
 905:			case MCP2221_SUCCESS:
 906:				if (data[2] == MCP2221_I2C_ADDR_NACK) {
 907:					mcp->status = -ENXIO;
 908:					break;
 909:				}
 910:				if (!mcp_get_i2c_eng_state(mcp, data, 2)
 911:					&& (data[3] == 0)) {
 912:					mcp->status = 0;
 913:					break;
 914:				}
 915:				if (data[3] == 127) {
 916:					mcp->status = -EIO;
 917:					break;
 918:				}
 919:				if (data[2] == MCP2221_I2C_READ_COMPL ||
 920:				    data[2] == MCP2221_I2C_READ_PARTIAL) {
 921:					if (!mcp->rxbuf || mcp->rxbuf_idx < 0 || data[3] > 60) {
 922:						mcp->status = -EINVAL;
 923:						break;
 924:					}
 925:					if (mcp->rxbuf_idx + data[3] > mcp->rxbuf_size) {
 926:						mcp->status = -EINVAL;
 927:						break;
 928:					}
 929:					buf = mcp->rxbuf;
 930:					memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
 931:					mcp->rxbuf_idx = mcp->rxbuf_idx + data[3];
 932:					mcp->status = 0;
 933:					break;
 934:				}
 935:				mcp->status = -EIO;
 936:				break;
 937:			default:
 938:				mcp->status = -EIO;
 939:			}
 940:			complete(&mcp->wait_in_report);
 941:			break;
 942:	
 943:		case MCP2221_GPIO_GET:
 944:			switch (data[1]) {
 945:			case MCP2221_SUCCESS:
 946:				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
 947:					(data[mcp->gp_idx + 1] == MCP2221_ALT_F_NOT_GPIOD)) {
 948:					mcp->status = -ENOENT;
 949:				} else {
 950:					mcp->status = !!data[mcp->gp_idx];
 951:					mcp->gpio_dir = data[mcp->gp_idx + 1];
 952:				}
 953:				break;
 954:			default:
 955:				mcp->status = -EAGAIN;
 956:			}
 957:			complete(&mcp->wait_in_report);
 958:			break;
 959:	
 960:		case MCP2221_GPIO_SET:
 961:			switch (data[1]) {
 962:			case MCP2221_SUCCESS:
 963:				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
 964:					(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
 965:					mcp->status = -ENOENT;
 966:				} else {
 967:					mcp->status = 0;
 968:				}
 969:				break;
 970:			default:
 971:				mcp->status = -EAGAIN;
 972:			}
 973:			complete(&mcp->wait_in_report);
 974:			break;
 975:	
 976:		case MCP2221_SET_SRAM_SETTINGS:
 977:			switch (data[1]) {
 978:			case MCP2221_SUCCESS:
 979:				mcp->status = 0;
 980:				break;
 981:			default:
 982:				mcp->status = -EAGAIN;
 983:			}
 984:			complete(&mcp->wait_in_report);
 985:			break;
 986:	
 987:		case MCP2221_GET_SRAM_SETTINGS:
 988:			switch (data[1]) {
 989:			case MCP2221_SUCCESS:
 990:				memcpy(&mcp->mode, &data[22], 4);
 991:	#if IS_REACHABLE(CONFIG_IIO)
 992:				mcp->dac_value = data[6] & GENMASK(4, 0);
 993:	#endif
 994:				mcp->status = 0;
 995:				break;
 996:			default:
 997:				mcp->status = -EAGAIN;
 998:			}
 999:			complete(&mcp->wait_in_report);
1000:			break;
1001:	
1002:		case MCP2221_READ_FLASH_DATA:
1003:			switch (data[1]) {
1004:			case MCP2221_SUCCESS:
1005:				mcp->status = 0;
1006:	
1007:				/* Only handles CHIP SETTINGS subpage currently */
1008:				if (mcp->txbuf[1] != 0) {
1009:					mcp->status = -EIO;
1010:					break;
1011:				}
1012:	
1013:	#if IS_REACHABLE(CONFIG_IIO)
1014:				{
1015:					u8 tmp;
1016:					/* DAC scale value */
1017:					tmp = FIELD_GET(GENMASK(7, 6), data[6]);
1018:					if ((data[6] & BIT(5)) && tmp)
1019:						mcp->dac_scale = tmp + 4;
1020:					else
1021:						mcp->dac_scale = 5;
1022:	
1023:					/* ADC scale value */
1024:					tmp = FIELD_GET(GENMASK(4, 3), data[7]);
1025:					if ((data[7] & BIT(2)) && tmp)
1026:						mcp->adc_scale = tmp - 1;
1027:					else
1028:						mcp->adc_scale = 0;
1029:				}
1030:	#endif
1031:	
1032:				break;
1033:			default:
1034:				mcp->status = -EAGAIN;
1035:			}
1036:			complete(&mcp->wait_in_report);
1037:			break;
1038:	
1039:		default:
1040:			mcp->status = -EIO;
1041:			complete(&mcp->wait_in_report);
1042:		}
1043:	
1044:		return 1;
1045:	}
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 21209
							output: 49
							thoughts: 353
						

**Analyzing the MCP2221 Raw Event Handling**

Okay, so I'm thinking about how the `mcp2221_raw_event` function should work, and specifically the size check at the beginning. The initial idea was to put the size check at the very top of the function. If the size is less than 64 bytes, it should return either 1 (handled) or 0 (not handled). If it returns 1, that means the raw event is completely dealt with by this function and doesn't need to be passed on to `hid_report_raw_event`. Returning 0 would mean it *does* need further processing.

However, if the size is invalid, I think we want to ignore it completely. Returning 1 would make sense, because the goal is to indicate that the function *handled* the error.

Wait a second… `mcp2221_raw_event` *always* returns 1. Right, that means that if `size < 64`, we should definitely return 1.

Now, what's the largest index that gets accessed within this function? I have to consider the data buffer. Looking at the `MCP2221_I2C_PARAM_OR_STATUS` case, I see a `memcpy` to `mcp->adc_values` from `data[50]`. I believe the size of `mcp->adc_values` is 6 bytes (likely three unsigned 16-bit values). So, that means the maximum index accessed is up to `data[55]`. So a size of 64 or more will be safe.

So, if we put the `if (size < 64)` check at the beginning, we can ensure that we are not going to read out of bounds.

```c
	if (size < 64)
		return 1;
```

Actually, is the report size *always* exactly 64 bytes? I should double-check `mcp_send_report` to be absolutely certain.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp_send_report]

map[SourceCode: 157:	/* Synchronously send output report to the device */
 158:	static int mcp_send_report(struct mcp2221 *mcp,
 159:						u8 *out_report, size_t len)
 160:	{
 161:		u8 *buf;
 162:		int ret;
 163:	
 164:		buf = kmemdup(out_report, len, GFP_KERNEL);
 165:		if (!buf)
 166:			return -ENOMEM;
 167:	
 168:		/* mcp2221 uses interrupt endpoint for out reports */
 169:		ret = hid_hw_output_report(mcp->hdev, buf, len);
 170:		kfree(buf);
 171:	
 172:		if (ret < 0)
 173:			return ret;
 174:		return 0;
 175:	}
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 22357
							output: 53
							thoughts: 38
						

Okay, here's my interpretation of those thoughts, tailored for an expert audience:

**Analyzing the Data Flow**

Alright, hang on a second. I need to recalibrate here. The `mcp2221_raw_event` seems to be related to *input* report handling. That's not what I was initially focused on. I need to make sure I'm following the correct data flow, so I'm going to shift my focus for a moment. Instead of assuming, I need to look closely at the `mcp_send_data_req_status`. I'll cross-reference the function usage and the values of the status to ensure I'm using the proper variables and making the right logical calls. I'm sure it is this function that drives the process.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp_send_data_req_status]

map[SourceCode: 177:	/*
 178:	 * Send o/p report to the device and wait for i/p report to be
 179:	 * received from the device. If the device does not respond,
 180:	 * we timeout.
 181:	 */
 182:	static int mcp_send_data_req_status(struct mcp2221 *mcp,
 183:				u8 *out_report, int len)
 184:	{
 185:		int ret;
 186:		unsigned long t;
 187:	
 188:		reinit_completion(&mcp->wait_in_report);
 189:	
 190:		ret = mcp_send_report(mcp, out_report, len);
 191:		if (ret)
 192:			return ret;
 193:	
 194:		t = wait_for_completion_timeout(&mcp->wait_in_report,
 195:								msecs_to_jiffies(4000));
 196:		if (!t)
 197:			return -ETIMEDOUT;
 198:	
 199:		return mcp->status;
 200:	}
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 22991
							output: 21
							thoughts: 1331
						

**Analyzing the MCP2221 HID Report Handling**

Okay, so I'm looking at this MCP2221 driver, and the report size is 64 bytes. Let's dig into `mcp2221_raw_event` and `mcp2221_probe` to see how the driver handles it.  Ah, `mcp2221_raw_event` seems the key here. It has a section that checks for I2C read completions.  Specifically, it does a check `data[3] > 60`. That means the data length is at most 60, and starts at `data[4]`, so this confirms a report size of 64 bytes (4 + 60 = 64).

Now, the core issue is what to do with short reports, reports smaller than 64 bytes. If `size < 64`, what do we do? Returning `1` doesn't signal completion, which could leave a command waiting indefinitely. Returning `1` would also leave `mcp->status` uninitialized. A short report could be a stray message or, potentially, a malicious one. If we complete the wait, we can complete the wrong command! But ignoring it will timeout the sender.

Initially, I thought about setting `mcp->status = -EIO` and `complete(&mcp->wait_in_report)`. If it's a response to a command, this seems correct: we signal an error. Now, the `mcp2221_raw_event` is:

```c
	static int mcp2221_raw_event(struct hid_device *hdev,
					struct hid_report *report, u8 *data, int size)
	{
		u8 *buf;
		struct mcp2221 *mcp = hid_get_drvdata(hdev);

		if (unlikely(size < 64))
			return 1;

		switch (data[0]) {
```

If we return `1`, no completion is signaled. If we do the following, the short reports will be handled:

```c
		if (size < 64) {
			mcp->status = -EIO;
			complete(&mcp->wait_in_report);
			return 1;
		}
```

Okay, now hold on... what if `size` is zero? `data[0]` is an out-of-bounds access. However, `__hid_input_report` has a check: `if (!size) return -1;`. Thus, `size` is at least 1. But completing a wait could complete the wrong command! However, the `mcp2221_raw_event` handles unknown `data[0]` values with:

```c
	default:
		mcp->status = -EIO;
		complete(&mcp->wait_in_report);
	}
```

So, it already *completes* the wait regardless. It's consistent to handle short reports the same way. Now, let's address the bug report.  It mentions validating `mcp->gp_idx`. That index is used in `MCP2221_GPIO_GET` and `MCP2221_GPIO_SET`.

```c
	case MCP2221_GPIO_GET:
		switch (data[1]) {
		case MCP2221_SUCCESS:
			if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
				(data[mcp->gp_idx + 1] == MCP2221_ALT_F_NOT_GPIOD)) {
				mcp->status = -ENOENT;
			} else {
				mcp->status = !!data[mcp->gp_idx];
				mcp->gpio_dir = data[mcp->gp_idx + 1];
			}
			break;
		default:
			mcp->status = -EAGAIN;
		}
		complete(&mcp->wait_in_report);
		break;

	case MCP2221_GPIO_SET:
		switch (data[1]) {
		case MCP2221_SUCCESS:
			if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
				(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
				m

requested entity does not exist

map[Name:gp_idx]

map[References:<nil> TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 25389
							output: 17
							thoughts: 27
						

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

**Diving into the MCP2221 HID Driver**

Alright, time to get my hands dirty. I need to track down the usage of `gp_idx` within the MCP2221 HID driver. The logical first step is to zero in on the source file, which I know is `drivers/hid/hid-mcp2221.c`. Now, I'm expecting `gp_idx` to likely be a crucial element in how the driver interacts with the GPIO functionality of the chip. This is probably a central variable for tracking or manipulating the general-purpose input/output pins. I anticipate it could be used for configuring the pin direction, reading or writing values, or possibly handling interrupts associated with those pins. Searching for it now.

map[Expression:gp_idx]

map[Output:drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c=10089=static u32 gfx_v10_0_get_cu_active_bitmap_per_sh(struct amdgpu_device *adev)
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c-10090-{
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:10091:	u32 wgp_idx, wgp_active_bitmap;
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c-10092-	u32 cu_bitmap_per_wgp, cu_active_bitmap;
--
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c-10096-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:10097:	for (wgp_idx = 0; wgp_idx < 16; wgp_idx++) {
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c-10098-		/* if there is one WGP enabled, it means 2 CUs will be enabled */
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:10099:		cu_bitmap_per_wgp = 3 << (2 * wgp_idx);
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:10100:		if (wgp_active_bitmap & (1 << wgp_idx))
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c-10101-			cu_active_bitmap |= cu_bitmap_per_wgp;
--
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c=7520=static u32 gfx_v11_0_get_cu_active_bitmap_per_sh(struct amdgpu_device *adev)
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c-7521-{
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:7522:	u32 wgp_idx, wgp_active_bitmap;
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c-7523-	u32 cu_bitmap_per_wgp, cu_active_bitmap;
--
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c-7527-
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:7528:	for (wgp_idx = 0; wgp_idx < 16; wgp_idx++) {
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c-7529-		/* if there is one WGP enabled, it means 2 CUs will be enabled */
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:7530:		cu_bitmap_per_wgp = 3 << (2 * wgp_idx);
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:7531:		if (wgp_active_bitmap & (1 << wgp_idx))
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c-7532-			cu_active_bitmap |= cu_bitmap_per_wgp;
--
drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c=5726=static u32 gfx_v12_0_get_cu_active_bitmap_per_sh(struct amdgpu_device *adev)
drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c-5727-{
drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c:5728:	u32 wgp_idx, wgp_active_bitmap;
drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c-5729-	u32 cu_bitmap_per_wgp, cu_active_bitmap;
--
drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c-5733-
drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c:5734:	for (wgp_idx = 0; wgp_idx < 16; wgp_idx++) {
drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c-5735-		/* if there is one WGP enabled, it means 2 CUs will be enabled */
drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c:5736:		cu_bitmap_per_wgp = 3 << (2 * wgp_idx);
drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c:5737:		if (wgp_active_bitmap & (1 << wgp_idx))
drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c-5738-			cu_active_bitmap |= cu_bitmap_per_wgp;
--
drivers/hid/hid-mcp2221.c=122=struct mcp2221 {
--
drivers/hid/hid-mcp2221.c-134-	struct gpio_chip *gc;
drivers/hid/hid-mcp2221.c:135:	u8 gp_idx;
drivers/hid/hid-mcp2221.c-136-	u8 gpio_dir;
--
drivers/hid/hid-mcp2221.c=712=static int mcp_gpio_get(struct gpio_chip *gc,
--
drivers/hid/hid-mcp2221.c-719-
drivers/hid/hid-mcp2221.c:720:	mcp->gp_idx = offsetof(struct mcp_get_gpio, gpio[offset]);
drivers/hid/hid-mcp2221.c-721-
--
drivers/hid/hid-mcp2221.c=729=static int mcp_gpio_set(struct gpio_chip *gc, unsigned int offset, int value)
--
drivers/hid/hid-mcp2221.c-736-
drivers/hid/hid-mcp2221.c:737:	mcp->gp_idx = offsetof(struct mcp_set_gpio, gpio[offset].value);
drivers/hid/hid-mcp2221.c-738-
drivers/hid/hid-mcp2221.c:739:	mcp->txbuf[mcp->gp_idx - 1] = 1;
drivers/hid/hid-mcp2221.c:740:	mcp->txbuf[mcp->gp_idx] = !!value;
drivers/hid/hid-mcp2221.c-741-
--
drivers/hid/hid-mcp2221.c=749=static int mcp_gpio_dir_set(struct mcp2221 *mcp,
--
drivers/hid/hid-mcp2221.c-754-
drivers/hid/hid-mcp2221.c:755:	mcp->gp_idx = offsetof(struct mcp_set_gpio, gpio[offset].direction);
drivers/hid/hid-mcp2221.c-756-
drivers/hid/hid-mcp2221.c:757:	mcp->txbuf[mcp->gp_idx - 1] = 1;
drivers/hid/hid-mcp2221.c:758:	mcp->txbuf[mcp->gp_idx] = val;
drivers/hid/hid-mcp2221.c-759-
--
drivers/hid/hid-mcp2221.c=795=static int mcp_gpio_get_direction(struct gpio_chip *gc,
--
drivers/hid/hid-mcp2221.c-802-
drivers/hid/hid-mcp2221.c:803:	mcp->gp_idx = offsetof(struct mcp_get_gpio, gpio[offset]);
drivers/hid/hid-mcp2221.c-804-
--
drivers/hid/hid-mcp2221.c=858=static int mcp2221_raw_event(struct hid_device *hdev,
--
drivers/hid/hid-mcp2221.c-945-		case MCP2221_SUCCESS:
drivers/hid/hid-mcp2221.c:946:			if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
drivers/hid/hid-mcp2221.c:947:				(data[mcp->gp_idx + 1] == MCP2221_ALT_F_NOT_GPIOD)) {
drivers/hid/hid-mcp2221.c-948-				mcp->status = -ENOENT;
drivers/hid/hid-mcp2221.c-949-			} else {
drivers/hid/hid-mcp2221.c:950:				mcp->status = !!data[mcp->gp_idx];
drivers/hid/hid-mcp2221.c:951:				mcp->gpio_dir = data[mcp->gp_idx + 1];
drivers/hid/hid-mcp2221.c-952-			}
--
drivers/hid/hid-mcp2221.c-962-		case MCP2221_SUCCESS:
drivers/hid/hid-mcp2221.c:963:			if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
drivers/hid/hid-mcp2221.c:964:				(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
drivers/hid/hid-mcp2221.c-965-				mcp->status = -ENOENT;
]

gemini-3.1-pro-preview

							input: 28298
							output: 49
							thoughts: 71
						

Here's my summary, as I delve into this code:

**Analyzing `mcp->gp_idx` Initialization**

Alright, let's break this down. It looks like the `mcp->gp_idx` field is being populated, and I see it's using `offsetof` with either `struct mcp_get_gpio` or `struct mcp_set_gpio`. My immediate thought is, "Okay, that's pretty standard, but let's make sure we understand *exactly* what's going on." I need to understand what's happening with that `gpio[offset]` within those structs, particularly how the `offsetof` is applied to either the base of the `gpio` array or specifically to the `value` member within an element of that array. Knowing those struct definitions is going to be key to confirming the intent of the index calculation. I'm going to quickly pull up the definitions of `struct mcp_get_gpio` and `struct mcp_set_gpio` to see how those offsets are being calculated in relation to the start of the structure. Knowing the structure layout will make this completely clear.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp_get_gpio]

map[SourceCode: 107:	/* MCP GPIO get command layout */
 108:	struct mcp_get_gpio {
 109:		u8 cmd;
 110:		u8 dummy;
 111:		struct {
 112:			u8 value;
 113:			u8 direction;
 114:		} gpio[MCP_NGPIO];
 115:	} __packed;
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 28806
							output: 49
							thoughts: 10
						

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

**Analyzing the `struct mcp_set_gpio` Structure**

Alright, so we're looking at this `struct mcp_set_gpio`. My initial thought is to immediately dissect its purpose within the broader context. Is this a local structure, or does it interact with the kernel? Judging by the name, it's likely involved in setting General Purpose Input/Output pins, or GPIOs, related to an MCP device. That suggests a hardware interaction level, potentially within an embedded systems or driver context.

My immediate questions are: What members are within this structure? What specific fields are used for configuring the MCP device? Are we talking about direction, value, pull-up/pull-down configuration, or something more advanced? The details of each member are critical to understanding how the driver communicates the desired GPIO settings to the MCP hardware. I need to see if it utilizes bitfields, or if a more generic integer type is used. Are there any restrictions, such as allowable ranges, or specific bitmask values?

I'm also wondering if there are any associated functions that work with this struct. How is it passed to other code, and what operations can be performed on it? Are there any data validation routines to check for valid pin numbers, values, and configurations? I'm anticipating error handling. What is the scope of this structure? Does it have to be maintained with the driver as a global/static variable? Is it part of a larger chain of structures?

Ultimately, the goal is to determine the efficiency and robustness of the system architecture related to this structure. Is it properly designed for the specific needs of the MCP? Is it safe from concurrent access issues? Are there any potential performance bottlenecks? And, of course, is it properly documented? This will inform how effective it is in operation, or if it can be modified.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp_set_gpio]

map[SourceCode:  95:	/* MCP GPIO set command layout */
  96:	struct mcp_set_gpio {
  97:		u8 cmd;
  98:		u8 dummy;
  99:		struct {
 100:			u8 change_value;
 101:			u8 value;
 102:			u8 change_direction;
 103:			u8 direction;
 104:		} gpio[MCP_NGPIO];
 105:	} __packed;
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 29437
							output: 20
							thoughts: 804
						

**Analyzing Potential Vulnerabilities in the MCP2221 Driver**

Okay, let's break this down. First, I'm noting the offsets within the structures: `offsetof(struct mcp_get_gpio, gpio[0])` is 2, `offsetof(struct mcp_set_gpio, gpio[0].value)` is 3, and `offsetof(struct mcp_set_gpio, gpio[0].direction)` is 5. This means `mcp->gp_idx` should *always* be at least 2, and a value of 0 means either the device hasn't been initialized, or it's been reset.

I need to look into how `mcp->gp_idx` is validated in `mcp2221_raw_event`. The first thought is to check if `mcp->gp_idx` is valid within that function.

But here's a potential exploit scenario. What happens if the device sends a `MCP2221_GPIO_SET` response when we were expecting a `MCP2221_GPIO_GET` response? If the command sent was `MCP2221_GPIO_GET`, then `mcp->gp_idx` could be 2, 4, 6, or 8. If the device sends a `MCP2221_GPIO_SET` response, it's going to access `data[mcp->gp_idx - 1]`.

If `mcp->gp_idx` is 2, then `data[1]` is accessed. This is the status byte – a potential bug, as the response parser is assuming `mcp->gp_idx` was set for the correct command. The `mcp2221_raw_event` function just uses the value of `mcp->gp_idx` based on the response type. It's assuming that if `data[0]` is `MCP2221_GPIO_SET`, that `mcp->gp_idx` corresponds with a `MCP2221_GPIO_SET` command (so 3, 7, 11, or 15 for value, or 5, 9, 13, 17 for direction). And, if `data[0]` is `MCP2221_GPIO_GET`, it expects `mcp->gp_idx` to be from a `MCP2221_GPIO_GET` command (2, 4, 6, 8). This is a clear disconnect.

A malicious device *could* send a response to any command. If a malicious device sent a `MCP2221_GPIO_SET` when `mcp->gp_idx` is 2, it would then access `data[1]`. Although this isn't an out-of-bounds access (because the `data` buffer is 64 bytes), it's semantically incorrect because `data[1]` contains different information.

The immediate vulnerability lies in `mcp->gp_idx` being 0, which would lead to an access to `data[-1]`, and is clearly an off-by-one error. To fix this, I can start with a size check: `if (size < 64) return 1;` at the beginning of the `mcp2221_raw_event` function to make sure it will not access out-of-bounds memory. To resolve the `mcp->gp_idx` issue, I can validate if `mcp->gp_idx` is valid for the response, based on the *corresponding* command. But how do I know which command was sent? Wait a minute, the command is stored in `mcp->txbuf[0]`! So I could check if `data[0] == mcp->txbuf[0]`. I should check that `mcp->txbuf` is valid and contains the command.

requested entity does not exist

map[Name:txbuf]

map[References:<nil> TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 31136
							output: 16
							thoughts: 26
						

Okay, here's my take on those thoughts, framed as a first-person expert summary:

**Digging into the hid-mcp2221 Driver**

Alright, time to get to work. My initial thought is to zero in on the `drivers/hid/hid-mcp2221.c` file. I'm going to jump straight in and search for `txbuf`. That's a classic starting point, isn't it? When debugging or trying to understand a driver's communication flow, the transmit buffer (`txbuf`) is often where the action starts. It's the staging area for data being sent to the MCP2221 device, so naturally, I want to see how that's handled. This search should quickly reveal the crucial parts of the driver responsible for preparing, buffering, and ultimately transmitting data to the USB device. It will give me a foothold to examine the data flow through the driver. Let's see what we find!

map[Expression:txbuf]

map[Output:
Full output is too long, showing 500 out of 5260 lines.
Use more precise expression if possible.

[Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml=75=examples:
 --
 Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml-101-        memory-region = <&npu_firmware>, <&npu_pkt>, <&npu_txpkt>,
 Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml:102:                        <&npu_txbufid>, <&npu_ba>;
 Documentation/devicetree/bindings/net/airoha,en7581-npu.yaml-103-        memory-region-names = "firmware", "pkt", "tx-pkt", "tx-bufid", "ba";
 --
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h=166=union cvmx_sriox_bist_status {
 --
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h-185-		uint64_t ospf:1;
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h:186:		uint64_t txbuf:2;
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h-187-		uint64_t rxbuf:2;
 --
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h-193-		uint64_t rxbuf:2;
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h:194:		uint64_t txbuf:2;
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h-195-		uint64_t ospf:1;
 --
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h-229-		uint64_t ospf:1;
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h:230:		uint64_t txbuf:2;
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h-231-		uint64_t rxbuf:2;
 --
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h-237-		uint64_t rxbuf:2;
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h:238:		uint64_t txbuf:2;
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h-239-		uint64_t ospf:1;
 --
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h-271-		uint64_t ospf:1;
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h:272:		uint64_t txbuf:2;
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h-273-		uint64_t rxbuf:2;
 --
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h-279-		uint64_t rxbuf:2;
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h:280:		uint64_t txbuf:2;
 arch/mips/include/asm/octeon/cvmx-sriox-defs.h-281-		uint64_t ospf:1;
 --
 arch/powerpc/include/asm/vas.h=158=struct vas_tx_win_attr {
 --
 arch/powerpc/include/asm/vas.h-163-	int pswid;
 arch/powerpc/include/asm/vas.h:164:	int rsvd_txbuf_count;
 arch/powerpc/include/asm/vas.h-165-	int tc_mode;
 --
 arch/powerpc/include/asm/vas.h-169-	bool rej_no_credit;
 arch/powerpc/include/asm/vas.h:170:	bool rsvd_txbuf_enable;
 arch/powerpc/include/asm/vas.h-171-	bool tx_wcred_mode;
 --
 arch/powerpc/platforms/powernv/vas-window.c=686=static void init_winctx_for_rxwin(struct pnv_vas_window *rxwin,
 --
 arch/powerpc/platforms/powernv/vas-window.c-698-	 *	->notify_early		NA for NX windows
 arch/powerpc/platforms/powernv/vas-window.c:699:	 *	->rsvd_txbuf_count	NA for Rx windows
 arch/powerpc/platforms/powernv/vas-window.c-700-	 *	->lpid, ->pid, ->tid	NA for Rx windows
 --
 arch/powerpc/platforms/powernv/vas-window.c=910=static void init_winctx_for_txwin(struct pnv_vas_window *txwin,
 --
 arch/powerpc/platforms/powernv/vas-window.c-918-	 *	->notify_os_intr_reg	In powernv, send intrs to HV
 arch/powerpc/platforms/powernv/vas-window.c:919:	 *	->rsvd_txbuf_count	Not supported yet.
 arch/powerpc/platforms/powernv/vas-window.c-920-	 *	->notify_disable	False for NX windows
 --
 arch/powerpc/platforms/powernv/vas-window.c-936-	winctx->rej_no_credit = txattr->rej_no_credit;
 arch/powerpc/platforms/powernv/vas-window.c:937:	winctx->rsvd_txbuf_enable = txattr->rsvd_txbuf_enable;
 arch/powerpc/platforms/powernv/vas-window.c-938-
 --
 arch/powerpc/platforms/powernv/vas-window.c-942-	winctx->tx_word_mode = txattr->tx_win_ord_mode;
 arch/powerpc/platforms/powernv/vas-window.c:943:	winctx->rsvd_txbuf_count = txattr->rsvd_txbuf_count;
 arch/powerpc/platforms/powernv/vas-window.c-944-
 --
 arch/powerpc/platforms/powernv/vas-window.c=971=static bool tx_win_args_valid(enum vas_cop_type cop,
 --
 arch/powerpc/platforms/powernv/vas-window.c-983-	if (attr->user_win) {
 arch/powerpc/platforms/powernv/vas-window.c:984:		if (attr->rsvd_txbuf_count)
 arch/powerpc/platforms/powernv/vas-window.c-985-			return false;
 --
 arch/powerpc/platforms/powernv/vas-window.c=1412=static struct vas_window *vas_user_win_open(int vas_id, u64 flags,
 --
 arch/powerpc/platforms/powernv/vas-window.c-1421-	txattr.user_win = true;
 arch/powerpc/platforms/powernv/vas-window.c:1422:	txattr.rsvd_txbuf_count = false;
 arch/powerpc/platforms/powernv/vas-window.c-1423-	txattr.pswid = false;
 --
 arch/powerpc/platforms/powernv/vas.h=378=struct vas_winctx {
 --
 arch/powerpc/platforms/powernv/vas.h-381-	int wcreds_max;
 arch/powerpc/platforms/powernv/vas.h:382:	int rsvd_txbuf_count;
 arch/powerpc/platforms/powernv/vas.h-383-
 --
 arch/powerpc/platforms/powernv/vas.h-386-	bool fault_win;
 arch/powerpc/platforms/powernv/vas.h:387:	bool rsvd_txbuf_enable;
 arch/powerpc/platforms/powernv/vas.h-388-	bool pin_win;
 --
 arch/powerpc/sysdev/cpm_common.c=47=static u32 __iomem *cpm_udbg_txdesc;
 arch/powerpc/sysdev/cpm_common.c:48:static u8 __iomem *cpm_udbg_txbuf;
 arch/powerpc/sysdev/cpm_common.c-49-
 arch/powerpc/sysdev/cpm_common.c=50=static void udbg_putc_cpm(char c)
 --
 arch/powerpc/sysdev/cpm_common.c-57-
 arch/powerpc/sysdev/cpm_common.c:58:	out_8(cpm_udbg_txbuf, c);
 arch/powerpc/sysdev/cpm_common.c-59-	out_be32(&cpm_udbg_txdesc[0], 0xa0000001);
 --
 arch/powerpc/sysdev/cpm_common.c=62=void __init udbg_init_cpm(void)
 --
 arch/powerpc/sysdev/cpm_common.c-69-			   VIRT_IMMR_BASE);
 arch/powerpc/sysdev/cpm_common.c:70:	cpm_udbg_txbuf = (u8 __iomem __force *)
 arch/powerpc/sysdev/cpm_common.c-71-			 (in_be32(&cpm_udbg_txdesc[1]) - PHYS_IMMR_BASE +
 --
 arch/powerpc/sysdev/cpm_common.c-75-			  CONFIG_PPC_EARLY_DEBUG_CPM_ADDR;
 arch/powerpc/sysdev/cpm_common.c:76:	cpm_udbg_txbuf = (u8 __iomem __force *)in_be32(&cpm_udbg_txdesc[1]);
 arch/powerpc/sysdev/cpm_common.c-77-#endif
 --
 arch/um/drivers/vector_kern.c=901=static int writev_tx(struct vector_private *vp, struct sk_buff *skb)
 --
 arch/um/drivers/vector_kern.c-905-
 arch/um/drivers/vector_kern.c:906:	iov[0].iov_base = vp->header_txbuffer;
 arch/um/drivers/vector_kern.c-907-	iov_count = prep_msg(vp, skb, (struct iovec *) &iov);
 --
 arch/um/drivers/vector_kern.c=1106=static int vector_net_close(struct net_device *dev)
 --
 arch/um/drivers/vector_kern.c-1145-	kfree(vp->header_rxbuffer);
 arch/um/drivers/vector_kern.c:1146:	kfree(vp->header_txbuffer);
 arch/um/drivers/vector_kern.c-1147-	if (vp->rx_queue != NULL)
 --
 arch/um/drivers/vector_kern.c=1194=static int vector_net_open(struct net_device *dev)
 --
 arch/um/drivers/vector_kern.c-1237-	} else {
 arch/um/drivers/vector_kern.c:1238:		vp->header_txbuffer = kmalloc(vp->header_size, GFP_KERNEL);
 arch/um/drivers/vector_kern.c:1239:		if (vp->header_txbuffer == NULL)
 arch/um/drivers/vector_kern.c-1240-			goto out_close;
 --
 arch/um/drivers/vector_kern.h=74=struct vector_private {
 --
 arch/um/drivers/vector_kern.h-111-	void *header_rxbuffer;
 arch/um/drivers/vector_kern.h:112:	void *header_txbuffer;
 arch/um/drivers/vector_kern.h-113-
 --
 drivers/firmware/arm_ffa/driver.c=677=ffa_setup_and_transmit(u32 func_id, void *buffer, u32 max_fragsize,
 --
 drivers/firmware/arm_ffa/driver.c-722-
 drivers/firmware/arm_ffa/driver.c:723:	if (!args->use_txbuf) {
 drivers/firmware/arm_ffa/driver.c-724-		addr = virt_to_phys(buffer);
 --
 drivers/firmware/arm_ffa/driver.c=760=static int ffa_memory_ops(u32 func_id, struct ffa_mem_ops_args *args)
 --
 drivers/firmware/arm_ffa/driver.c-765-
 drivers/firmware/arm_ffa/driver.c:766:	if (!args->use_txbuf) {
 drivers/firmware/arm_ffa/driver.c-767-		buffer = alloc_pages_exact(rxtx_bufsz, GFP_KERNEL);
 --
 drivers/firmware/arm_ffa/driver.c-776-
 drivers/firmware/arm_ffa/driver.c:777:	if (args->use_txbuf)
 drivers/firmware/arm_ffa/driver.c-778-		mutex_unlock(&drv_info->tx_lock);
 --
 drivers/fpga/microchip-spi.c=229=static int mpf_spi_write_then_read(struct mpf_priv *priv,
 drivers/fpga/microchip-spi.c:230:				   const void *txbuf, size_t txbuf_size,
 drivers/fpga/microchip-spi.c-231-				   void *rxbuf, size_t rxbuf_size)
 --
 drivers/fpga/microchip-spi.c-235-
 drivers/fpga/microchip-spi.c:236:	ret = mpf_spi_write(priv, txbuf, txbuf_size);
 drivers/fpga/microchip-spi.c-237-	if (ret)
 --
 drivers/gpu/drm/i915/display/intel_dp_aux.c=460=static void
 drivers/gpu/drm/i915/display/intel_dp_aux.c:461:intel_dp_aux_header(u8 txbuf[HEADER_SIZE],
 drivers/gpu/drm/i915/display/intel_dp_aux.c-462-		    const struct drm_dp_aux_msg *msg)
 drivers/gpu/drm/i915/display/intel_dp_aux.c-463-{
 drivers/gpu/drm/i915/display/intel_dp_aux.c:464:	txbuf[0] = (msg->request << 4) | ((msg->address >> 16) & 0xf);
 drivers/gpu/drm/i915/display/intel_dp_aux.c:465:	txbuf[1] = (msg->address >> 8) & 0xff;
 drivers/gpu/drm/i915/display/intel_dp_aux.c:466:	txbuf[2] = msg->address & 0xff;
 drivers/gpu/drm/i915/display/intel_dp_aux.c:467:	txbuf[3] = msg->size - 1;
 drivers/gpu/drm/i915/display/intel_dp_aux.c-468-}
 --
 drivers/gpu/drm/i915/display/intel_dp_aux.c=485=intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
 --
 drivers/gpu/drm/i915/display/intel_dp_aux.c-488-	struct intel_display *display = to_intel_display(intel_dp);
 drivers/gpu/drm/i915/display/intel_dp_aux.c:489:	u8 txbuf[20], rxbuf[20];
 drivers/gpu/drm/i915/display/intel_dp_aux.c-490-	size_t txsize, rxsize;
 --
 drivers/gpu/drm/i915/display/intel_dp_aux.c-493-
 drivers/gpu/drm/i915/display/intel_dp_aux.c:494:	intel_dp_aux_header(txbuf, msg);
 drivers/gpu/drm/i915/display/intel_dp_aux.c-495-
 --
 drivers/gpu/drm/i915/display/intel_dp_aux.c-508-		if (msg->buffer)
 drivers/gpu/drm/i915/display/intel_dp_aux.c:509:			memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
 drivers/gpu/drm/i915/display/intel_dp_aux.c-510-
 drivers/gpu/drm/i915/display/intel_dp_aux.c:511:		ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
 drivers/gpu/drm/i915/display/intel_dp_aux.c-512-					rxbuf, rxsize, flags);
 --
 drivers/gpu/drm/i915/display/intel_dp_aux.c-533-
 drivers/gpu/drm/i915/display/intel_dp_aux.c:534:		ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
 drivers/gpu/drm/i915/display/intel_dp_aux.c-535-					rxbuf, rxsize, flags);
 --
 drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.c=811=static void
 drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.c:812:nv10_gr_load_dma_vtxbuf(struct nv10_gr_chan *chan, int chid, u32 inst)
 drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.c-813-{
 --
 drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.c=883=nv10_gr_load_context(struct nv10_gr_chan *chan, int chid)
 --
 drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.c-900-	inst = nvkm_rd32(device, NV10_PGRAPH_GLOBALSTATE1) & 0xffff;
 drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.c:901:	nv10_gr_load_dma_vtxbuf(chan, chid, inst);
 drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.c-902-
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h=22=struct r535_gr {
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h-32-		bool ro;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h:33:	} ctxbuf[R515_GR_MAX_CTXBUFS];
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h:34:	int ctxbuf_nr;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h-35-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h:36:	struct nvkm_memory *ctxbuf_mem[R515_GR_MAX_CTXBUFS];
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h-37-
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h-46-			struct nvkm_vma    *vma[R515_GR_MAX_CTXBUFS];
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h:47:		} ctxbuf;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h-48-		bool enabled;
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h=52=struct NV2080_CTRL_INTERNAL_ENGINE_CONTEXT_BUFFER_INFO;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h:53:void r535_gr_get_ctxbuf_info(struct r535_gr *, int i,
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/gr.h-54-			     struct NV2080_CTRL_INTERNAL_ENGINE_CONTEXT_BUFFER_INFO *);
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c=40=r535_gr_chan_dtor(struct nvkm_object *object)
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-44-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:45:	for (int i = 0; i < gr->ctxbuf_nr; i++) {
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-46-		nvkm_vmm_put(grc->vmm, &grc->vma[i]);
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c=60=r535_gr_promote_ctx(struct r535_gr *gr, bool golden, struct nvkm_vmm *vmm,
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-76-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:77:	for (int i = 0; i < gr->ctxbuf_nr; i++) {
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-78-		NV2080_CTRL_GPU_PROMOTE_CTX_BUFFER_ENTRY *entry =
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-79-			&ctrl->promoteEntry[ctrl->entryCount];
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:80:		const bool alloc = golden || !gr->ctxbuf[i].global;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-81-		int ret;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-82-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:83:		entry->bufferId = gr->ctxbuf[i].bufferId;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:84:		entry->bInitialize = gr->ctxbuf[i].init && alloc;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-85-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-86-		if (alloc) {
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:87:			ret = nvkm_memory_new(device, gr->ctxbuf[i].init ?
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-88-					      NVKM_MEM_TARGET_INST : NVKM_MEM_TARGET_INST_SR_LOST,
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:89:					      gr->ctxbuf[i].size, 1 << gr->ctxbuf[i].page,
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:90:					      gr->ctxbuf[i].init, &pmem[i]);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-91-			if (WARN_ON(ret))
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-93-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:94:			if (gr->ctxbuf[i].bufferId ==
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-95-					NV2080_CTRL_GPU_PROMOTE_CTX_BUFFER_ID_PRIV_ACCESS_MAP)
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-97-		} else {
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:98:			if (gr->ctxbuf[i].bufferId ==
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-99-				NV2080_CTRL_GPU_PROMOTE_CTX_BUFFER_ID_UNRESTRICTED_PRIV_ACCESS_MAP)
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-101-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:102:			pmem[i] = nvkm_memory_ref(gr->ctxbuf_mem[i]);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-103-		}
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-107-				.priv = 1,
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:108:				.ro   = gr->ctxbuf[i].ro,
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-109-			};
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-111-			mutex_lock(&vmm->mutex.vmm);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:112:			ret = nvkm_vmm_get_locked(vmm, false, true, false, 0, gr->ctxbuf[i].align,
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-113-						  nvkm_memory_size(pmem[i]), &pvma[i]);
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-126-			entry->gpuPhysAddr = nvkm_memory_addr(pmem[i]);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:127:			entry->size = gr->ctxbuf[i].size;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-128-			entry->physAttr = 4;
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c=174=void
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:175:r535_gr_get_ctxbuf_info(struct r535_gr *gr, int i,
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-176-			struct NV2080_CTRL_INTERNAL_ENGINE_CONTEXT_BUFFER_INFO *info)
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-227-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:228:	if (WARN_ON(gr->ctxbuf_nr == ARRAY_SIZE(gr->ctxbuf)))
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-229-		return;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-230-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:231:	gr->ctxbuf[gr->ctxbuf_nr].bufferId = map[id].id1;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:232:	gr->ctxbuf[gr->ctxbuf_nr].size     = size;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:233:	gr->ctxbuf[gr->ctxbuf_nr].page     = page;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:234:	gr->ctxbuf[gr->ctxbuf_nr].align    = align;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:235:	gr->ctxbuf[gr->ctxbuf_nr].global   = map[id].global;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:236:	gr->ctxbuf[gr->ctxbuf_nr].init     = map[id].init;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:237:	gr->ctxbuf[gr->ctxbuf_nr].ro       = map[id].ro;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:238:	gr->ctxbuf_nr++;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-239-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-240-	if (map[id].id1 == NV2080_CTRL_GPU_PROMOTE_CTX_BUFFER_ID_PRIV_ACCESS_MAP) {
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:241:		if (WARN_ON(gr->ctxbuf_nr == ARRAY_SIZE(gr->ctxbuf)))
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-242-			return;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-243-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:244:		gr->ctxbuf[gr->ctxbuf_nr] = gr->ctxbuf[gr->ctxbuf_nr - 1];
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:245:		gr->ctxbuf[gr->ctxbuf_nr].bufferId =
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-246-			NV2080_CTRL_GPU_PROMOTE_CTX_BUFFER_ID_UNRESTRICTED_PRIV_ACCESS_MAP;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:247:		gr->ctxbuf_nr++;
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-248-	}
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c=251=static int
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:252:r535_gr_get_ctxbufs_and_zcull_info(struct r535_gr *gr)
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-253-{
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-264-	for (int i = 0; i < ARRAY_SIZE(info->engineContextBuffersInfo[0].engine); i++)
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:265:		r535_gr_get_ctxbuf_info(gr, i, &info->engineContextBuffersInfo[0].engine[i]);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-266-
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c=275=r535_gr_oneinit(struct nvkm_gr *base)
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-317-	 */
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:318:	ret = rm->api->gr->get_ctxbufs_and_zcull_info(gr);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-319-	if (ret)
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-322-	/* Promote golden context to RM. */
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:323:	ret = r535_gr_promote_ctx(gr, true, golden.vmm, gr->ctxbuf_mem, golden.vma, &golden.chan);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-324-	if (ret)
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-335-	nvkm_gsp_rm_free(&golden.chan);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:336:	for (int i = gr->ctxbuf_nr - 1; i >= 0; i--)
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-337-		nvkm_vmm_put(golden.vmm, &golden.vma[i]);
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c=345=r535_gr_dtor(struct nvkm_gr *base)
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-348-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:349:	while (gr->ctxbuf_nr)
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:350:		nvkm_memory_unref(&gr->ctxbuf_mem[--gr->ctxbuf_nr]);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-351-
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c=357=r535_gr = {
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c:358:	.get_ctxbufs_and_zcull_info = r535_gr_get_ctxbufs_and_zcull_info,
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gr.c-359-};
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c=71=r570_gr_scrubber_fini(struct r535_gr *gr)
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c-82-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c:83:	for (int i = 0; i < gr->ctxbuf_nr; i++) {
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c:84:		nvkm_vmm_put(gr->scrubber.vmm, &gr->scrubber.ctxbuf.vma[i]);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c:85:		nvkm_memory_unref(&gr->scrubber.ctxbuf.mem[i]);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c-86-	}
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c=93=r570_gr_scrubber_init(struct r535_gr *gr)
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c-141-
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c:142:	ret = r535_gr_promote_ctx(gr, false, gr->scrubber.vmm, gr->scrubber.ctxbuf.mem,
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c:143:				  gr->scrubber.ctxbuf.vma, &gr->scrubber.chan);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c-144-	if (ret)
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c=166=static int
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c:167:r570_gr_get_ctxbufs_and_zcull_info(struct r535_gr *gr)
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c-168-{
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c-180-	for (int i = 0; i < ARRAY_SIZE(info->engineContextBuffersInfo[0].engine); i++)
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c:181:		r535_gr_get_ctxbuf_info(gr, i, &info->engineContextBuffersInfo[0].engine[i]);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c-182-
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c=217=r570_gr = {
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c:218:	.get_ctxbufs_and_zcull_info = r570_gr_get_ctxbufs_and_zcull_info,
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gr.c-219-	.scrubber.init = r570_gr_scrubber_init,
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/rm.h=33=struct nvkm_rm_api {
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/rm.h-126-	const struct nvkm_rm_api_gr {
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/rm.h:127:		int (*get_ctxbufs_and_zcull_info)(struct r535_gr *);
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/rm.h-128-		struct {
 --
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/rm.h=169=int r535_gr_promote_ctx(struct r535_gr *, bool golden, struct nvkm_vmm *,
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/rm.h:170:			struct nvkm_memory **pctxbuf_mem, struct nvkm_vma **pctxbuf_vma,
 drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/rm.h-171-			struct nvkm_gsp_object *chan);
 --
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c=145=static int st7789v_spi_write(struct st7789v *ctx, enum st7789v_prefix prefix,
 --
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c-148-	struct spi_transfer xfer = { };
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c:149:	u16 txbuf = ((prefix & 1) << 8) | data;
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c-150-
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c:151:	xfer.tx_buf = &txbuf;
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c:152:	xfer.len = sizeof(txbuf);
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c-153-
 --
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c=167=static int st7789v_read_data(struct st7789v *ctx, u8 cmd, u8 *buf,
 --
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c-171-	struct spi_message msg;
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c:172:	u16 txbuf = ((ST7789V_COMMAND & 1) << 8) | cmd;
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c-173-	u16 rxbuf[4] = {};
 --
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c-187-
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c:188:	xfer[0].tx_buf = &txbuf;
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c:189:	xfer[0].len = sizeof(txbuf);
 drivers/gpu/drm/panel/panel-sitronix-st7789v.c-190-	spi_message_add_tail(&xfer[0], &msg);
 --
 drivers/gpu/drm/tiny/repaper.c=103=static int repaper_spi_transfer(struct spi_device *spi, u8 header,
 --
 drivers/gpu/drm/tiny/repaper.c-105-{
 drivers/gpu/drm/tiny/repaper.c:106:	void *txbuf = NULL, *rxbuf = NULL;
 drivers/gpu/drm/tiny/repaper.c-107-	struct spi_transfer tr[2] = {};
 --
 drivers/gpu/drm/tiny/repaper.c-120-	if (tx && len <= 32) {
 drivers/gpu/drm/tiny/repaper.c:121:		txbuf = kmemdup(tx, len, GFP_KERNEL);
 drivers/gpu/drm/tiny/repaper.c:122:		if (!txbuf) {
 drivers/gpu/drm/tiny/repaper.c-123-			ret = -ENOMEM;
 --
 drivers/gpu/drm/tiny/repaper.c-135-
 drivers/gpu/drm/tiny/repaper.c:136:	tr[1].tx_buf = txbuf ? txbuf : tx;
 drivers/gpu/drm/tiny/repaper.c-137-	tr[1].rx_buf = rxbuf;
 --
 drivers/gpu/drm/tiny/repaper.c-146-	kfree(headerbuf);
 drivers/gpu/drm/tiny/repaper.c:147:	kfree(txbuf);
 drivers/gpu/drm/tiny/repaper.c-148-	kfree(rxbuf);
 --
 drivers/hid/hid-mcp2221.c=122=struct mcp2221 {
 --
 drivers/hid/hid-mcp2221.c-128-	u8 *rxbuf;
 drivers/hid/hid-mcp2221.c:129:	u8 txbuf[64];
 drivers/hid/hid-mcp2221.c-130-	int rxbuf_idx;
 --
 drivers/hid/hid-mcp2221.c=203=static int mcp_chk_last_cmd_status(struct mcp2221 *mcp)
 drivers/hid/hid-mcp2221.c-204-{
 drivers/hid/hid-mcp2221.c:205:	memset(mcp->txbuf, 0, 8);
 drivers/hid/hid-mcp2221.c:206:	mcp->txbuf[0] = MCP2221_I2C_PARAM_OR_STATUS;
 drivers/hid/hid-mcp2221.c-207-
 drivers/hid/hid-mcp2221.c:208:	return mcp_send_data_req_status(mcp, mcp->txbuf, 8);
 drivers/hid/hid-mcp2221.c-209-}
 --
 drivers/hid/hid-mcp2221.c=212=static int mcp_cancel_last_cmd(struct mcp2221 *mcp)
 drivers/hid/hid-mcp2221.c-213-{
 drivers/hid/hid-mcp2221.c:214:	memset(mcp->txbuf, 0, 8);
 drivers/hid/hid-mcp2221.c:215:	mcp->txbuf[0] = MCP2221_I2C_PARAM_OR_STATUS;
 drivers/hid/hid-mcp2221.c:216:	mcp->txbuf[2] = MCP2221_I2C_CANCEL;
 drivers/hid/hid-mcp2221.c-217-
 drivers/hid/hid-mcp2221.c:218:	return mcp_send_data_req_status(mcp, mcp->txbuf, 8);
 drivers/hid/hid-mcp2221.c-219-}
 --
 drivers/hid/hid-mcp2221.c=240=static int mcp_set_i2c_speed(struct mcp2221 *mcp)
 --
 drivers/hid/hid-mcp2221.c-243-
 drivers/hid/hid-mcp2221.c:244:	memset(mcp->txbuf, 0, 8);
 drivers/hid/hid-mcp2221.c:245:	mcp->txbuf[0] = MCP2221_I2C_PARAM_OR_STATUS;
 drivers/hid/hid-mcp2221.c:246:	mcp->txbuf[3] = MCP2221_I2C_SET_SPEED;
 drivers/hid/hid-mcp2221.c:247:	mcp->txbuf[4] = mcp->cur_i2c_clk_div;
 drivers/hid/hid-mcp2221.c-248-
 drivers/hid/hid-mcp2221.c:249:	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 8);
 drivers/hid/hid-mcp2221.c-250-	if (ret) {
 --
 drivers/hid/hid-mcp2221.c=267=static int mcp_i2c_write(struct mcp2221 *mcp,
 --
 drivers/hid/hid-mcp2221.c-276-	do {
 drivers/hid/hid-mcp2221.c:277:		mcp->txbuf[0] = type;
 drivers/hid/hid-mcp2221.c:278:		mcp->txbuf[1] = msg->len & 0xff;
 drivers/hid/hid-mcp2221.c:279:		mcp->txbuf[2] = msg->len >> 8;
 drivers/hid/hid-mcp2221.c:280:		mcp->txbuf[3] = (u8)(msg->addr << 1);
 drivers/hid/hid-mcp2221.c-281-
 drivers/hid/hid-mcp2221.c:282:		memcpy(&mcp->txbuf[4], &msg->buf[idx], len);
 drivers/hid/hid-mcp2221.c-283-
 drivers/hid/hid-mcp2221.c:284:		ret = mcp_send_data_req_status(mcp, mcp->txbuf, len + 4);
 drivers/hid/hid-mcp2221.c-285-		if (ret)
 --
 drivers/hid/hid-mcp2221.c=319=static int mcp_i2c_smbus_read(struct mcp2221 *mcp,
 --
 drivers/hid/hid-mcp2221.c-326-
 drivers/hid/hid-mcp2221.c:327:	mcp->txbuf[0] = type;
 drivers/hid/hid-mcp2221.c-328-	if (msg) {
 drivers/hid/hid-mcp2221.c:329:		mcp->txbuf[1] = msg->len & 0xff;
 drivers/hid/hid-mcp2221.c:330:		mcp->txbuf[2] = msg->len >> 8;
 drivers/hid/hid-mcp2221.c:331:		mcp->txbuf[3] = (u8)(msg->addr << 1);
 drivers/hid/hid-mcp2221.c-332-		total_len = msg->len;
 --
 drivers/hid/hid-mcp2221.c-335-	} else {
 drivers/hid/hid-mcp2221.c:336:		mcp->txbuf[1] = smbus_len;
 drivers/hid/hid-mcp2221.c:337:		mcp->txbuf[2] = 0;
 drivers/hid/hid-mcp2221.c:338:		mcp->txbuf[3] = (u8)(smbus_addr << 1);
 drivers/hid/hid-mcp2221.c-339-		total_len = smbus_len;
 --
 drivers/hid/hid-mcp2221.c-343-
 drivers/hid/hid-mcp2221.c:344:	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 4);
 drivers/hid/hid-mcp2221.c-345-	if (ret)
 --
 drivers/hid/hid-mcp2221.c-353-
 drivers/hid/hid-mcp2221.c:354:		memset(mcp->txbuf, 0, 4);
 drivers/hid/hid-mcp2221.c:355:		mcp->txbuf[0] = MCP2221_I2C_GET_DATA;
 drivers/hid/hid-mcp2221.c-356-
 drivers/hid/hid-mcp2221.c:357:		ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
 drivers/hid/hid-mcp2221.c-358-		if (ret) {
 --
 drivers/hid/hid-mcp2221.c=435=static int mcp_smbus_write(struct mcp2221 *mcp, u16 addr,
 --
 drivers/hid/hid-mcp2221.c-440-
 drivers/hid/hid-mcp2221.c:441:	mcp->txbuf[0] = type;
 drivers/hid/hid-mcp2221.c:442:	mcp->txbuf[1] = len + 1; /* 1 is due to command byte itself */
 drivers/hid/hid-mcp2221.c:443:	mcp->txbuf[2] = 0;
 drivers/hid/hid-mcp2221.c:444:	mcp->txbuf[3] = (u8)(addr << 1);
 drivers/hid/hid-mcp2221.c:445:	mcp->txbuf[4] = command;
 drivers/hid/hid-mcp2221.c-446-
 --
 drivers/hid/hid-mcp2221.c-451-	case 1:
 drivers/hid/hid-mcp2221.c:452:		mcp->txbuf[5] = buf[0];
 drivers/hid/hid-mcp2221.c-453-		data_len = 6;
 --
 drivers/hid/hid-mcp2221.c-455-	case 2:
 drivers/hid/hid-mcp2221.c:456:		mcp->txbuf[5] = buf[0];
 drivers/hid/hid-mcp2221.c:457:		mcp->txbuf[6] = buf[1];
 drivers/hid/hid-mcp2221.c-458-		data_len = 7;
 --
 drivers/hid/hid-mcp2221.c-463-
 drivers/hid/hid-mcp2221.c:464:		memcpy(&mcp->txbuf[5], buf, len);
 drivers/hid/hid-mcp2221.c-465-		data_len = len + 5;
 --
 drivers/hid/hid-mcp2221.c-467-
 drivers/hid/hid-mcp2221.c:468:	ret = mcp_send_data_req_status(mcp, mcp->txbuf, data_len);
 drivers/hid/hid-mcp2221.c-469-	if (ret)
 --
 drivers/hid/hid-mcp2221.c=638=static int mcp_gpio_read_sram(struct mcp2221 *mcp)
 --
 drivers/hid/hid-mcp2221.c-641-
 drivers/hid/hid-mcp2221.c:642:	memset(mcp->txbuf, 0, 64);
 drivers/hid/hid-mcp2221.c:643:	mcp->txbuf[0] = MCP2221_GET_SRAM_SETTINGS;
]
]

gemini-3.1-pro-preview

							input: 46398
							output: 19
							thoughts: 2203
						

**Analyzing MCP2221 Communication and Stray Reports**

Okay, so I'm thinking about how the MCP2221 driver handles communication and, specifically, how it deals with potential "stray" reports from the device. I'm focusing on the `mcp2221_raw_event` function, which processes responses from the device. I can see that `mcp->txbuf` stores the command that's sent, and it's 64 bytes in size.

In both `mcp_gpio_get` and `mcp_gpio_set`, `mcp->txbuf[0]` clearly holds the sent command. My initial instinct is to simply check if `data[0]` (the response's first byte) matches `mcp->txbuf[0]` early in `mcp2221_raw_event`. If it doesn't match, it's a stray response, right? This could avoid unnecessary processing or premature completions.

I am questioning if checking `data[0] != mcp->txbuf[0]` at the start of `mcp2221_raw_event` to filter out stray reports could break anything. I need to make sure this check is safe. I've examined the code for `mcp_i2c_smbus_read`, specifically how `MCP2221_I2C_RD_DATA` and `MCP2221_I2C_GET_DATA` are handled, and other similar functions for I2C and GPIO operations. The pattern seems consistent: The response generally mirrors the command byte, which is reassuring.

However, I'm thinking about edge cases. What if the device sends an unsolicited report? My initial thought is the check would correctly identify and reject it. But, this leads to the next question: how does the driver handle these "stray" responses? I know the driver is using `mcp_send_data_req_status` to send a command and wait for a response, so if there's a delay, I might get a response for an old command when there's a new one.

Then it hits me: If `mcp2221_raw_event` receives the wrong response and calls `complete(&mcp->wait_in_report)`, the function waiting for the current command will likely wake up prematurely, maybe with an error status or garbage data. If the driver incorrectly completes the waiting thread, the pending command's execution will be affected.

The comment mentions that stray responses result in `-EIO`. But it should not trigger `complete(&mcp->wait_in_report)`. I need to ensure the stray report doesn't accidentally complete the wrong completion! It seems as though my idea, of simply checking `data[0] != mcp->txbuf[0]` to immediately return, might be correct, and that it may need to be coupled with a more robust handling of the wait completion mechanism.

I'm thinking, in all cases, the response's first byte (`data[0]`) should indeed always match the command byte stored in `mcp->txbuf[0]`. Thus, testing the validity of `data[0]`, at the start of the function, seems to be a valid guard, preventing any stray reports from progressing further. If `data[0] != mcp->txbuf[0]`, I can return early without completing, and there might be no need to modify `mcp->status`.

My next step is to see if the driver's mutexes guard `mcp->txbuf` appropriately to prevent any race conditions, which may cause `mcp->txbuf` to be modified concurrently with the response arrival.

map[Name:lock]

map[References:<nil> TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 49432
							output: 24
							thoughts: 17
						

Okay, here's my interpretation of that thought process, tailored for an expert audience, and presented as if it were my own internal monologue:

**Investigating a Concurrency Issue**

Alright, I need to dig into this. I'm hitting a concurrency issue, clearly. Let's not get lost in the weeds. Given what I'm seeing, a good first step, a likely culprit, is going to be related to the locking mechanism. Before I go down a rabbit hole of debugging, let me start there. I'm going to search the codebase *directly* for usages of `mutex_lock(&mcp->lock)`. That function call, or something very similar, is almost certainly the root of the problem, so let's start there with a surgical strike. Let me get my bearings by finding *where* it's happening, before broadening the search.

map[Expression:mutex_lock\(&mcp->lock\)]

map[Output:drivers/hid/hid-mcp2200.c=102=static int mcp_cmd_read_all(struct mcp2200 *mcp)
--
drivers/hid/hid-mcp2200.c-108-
drivers/hid/hid-mcp2200.c:109:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2200.c-110-
--
drivers/hid/hid-mcp2200.c=130=static int mcp_set_multiple(struct gpio_chip *gc, unsigned long *mask,
--
drivers/hid/hid-mcp2200.c-137-
drivers/hid/hid-mcp2200.c:138:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2200.c-139-	cmd = (struct mcp_set_clear_outputs *) mcp->hid_report;
--
drivers/hid/hid-mcp2200.c=202=static int mcp_set_direction(struct gpio_chip *gc, unsigned int gpio_nr,
--
drivers/hid/hid-mcp2200.c-219-
drivers/hid/hid-mcp2200.c:220:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2200.c-221-	conf = (struct mcp_configure  *) mcp->hid_report;
--
drivers/hid/hid-mcp2221.c=381=static int mcp_i2c_xfer(struct i2c_adapter *adapter,
--
drivers/hid/hid-mcp2221.c-388-
drivers/hid/hid-mcp2221.c:389:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2221.c-390-
--
drivers/hid/hid-mcp2221.c=481=static int mcp_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
--
drivers/hid/hid-mcp2221.c-490-
drivers/hid/hid-mcp2221.c:491:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2221.c-492-
--
drivers/hid/hid-mcp2221.c=638=static int mcp_gpio_read_sram(struct mcp2221 *mcp)
--
drivers/hid/hid-mcp2221.c-644-
drivers/hid/hid-mcp2221.c:645:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2221.c-646-	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 64);
--
drivers/hid/hid-mcp2221.c=657=static int mcp2221_check_gpio_pinfunc(struct mcp2221 *mcp)
--
drivers/hid/hid-mcp2221.c-704-
drivers/hid/hid-mcp2221.c:705:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2221.c-706-	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 64);
--
drivers/hid/hid-mcp2221.c=712=static int mcp_gpio_get(struct gpio_chip *gc,
--
drivers/hid/hid-mcp2221.c-721-
drivers/hid/hid-mcp2221.c:722:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2221.c-723-	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
--
drivers/hid/hid-mcp2221.c=729=static int mcp_gpio_set(struct gpio_chip *gc, unsigned int offset, int value)
--
drivers/hid/hid-mcp2221.c-741-
drivers/hid/hid-mcp2221.c:742:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2221.c-743-	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 18);
--
drivers/hid/hid-mcp2221.c=763=static int mcp_gpio_direction_input(struct gpio_chip *gc,
--
drivers/hid/hid-mcp2221.c-768-
drivers/hid/hid-mcp2221.c:769:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2221.c-770-	ret = mcp_gpio_dir_set(mcp, offset, MCP2221_DIR_IN);
--
drivers/hid/hid-mcp2221.c=776=static int mcp_gpio_direction_output(struct gpio_chip *gc,
--
drivers/hid/hid-mcp2221.c-781-
drivers/hid/hid-mcp2221.c:782:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2221.c-783-	ret = mcp_gpio_dir_set(mcp, offset, MCP2221_DIR_OUT);
--
drivers/hid/hid-mcp2221.c=795=static int mcp_gpio_get_direction(struct gpio_chip *gc,
--
drivers/hid/hid-mcp2221.c-804-
drivers/hid/hid-mcp2221.c:805:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2221.c-806-	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
--
drivers/hid/hid-mcp2221.c=1068=static int mcp2221_read_raw(struct iio_dev *indio_dev,
--
drivers/hid/hid-mcp2221.c-1084-
drivers/hid/hid-mcp2221.c:1085:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2221.c-1086-
--
drivers/hid/hid-mcp2221.c=1108=static int mcp2221_write_raw(struct iio_dev *indio_dev,
--
drivers/hid/hid-mcp2221.c-1118-
drivers/hid/hid-mcp2221.c:1119:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2221.c-1120-
--
drivers/hid/hid-mcp2221.c=1176=static void mcp_init_work(struct work_struct *work)
--
drivers/hid/hid-mcp2221.c-1184-	hid_hw_power(mcp->hdev, PM_HINT_FULLON);
drivers/hid/hid-mcp2221.c:1185:	mutex_lock(&mcp->lock);
drivers/hid/hid-mcp2221.c-1186-
--
drivers/pinctrl/pinctrl-mcp23s08.c=199=static int mcp_pinconf_get(struct pinctrl_dev *pctldev, unsigned int pin,
--
drivers/pinctrl/pinctrl-mcp23s08.c-208-	case PIN_CONFIG_BIAS_PULL_UP:
drivers/pinctrl/pinctrl-mcp23s08.c:209:		mutex_lock(&mcp->lock);
drivers/pinctrl/pinctrl-mcp23s08.c-210-		ret = mcp_read(mcp, MCP_GPPU, &data);
--
drivers/pinctrl/pinctrl-mcp23s08.c=225=static int mcp_pinconf_set(struct pinctrl_dev *pctldev, unsigned int pin,
--
drivers/pinctrl/pinctrl-mcp23s08.c-239-		case PIN_CONFIG_BIAS_PULL_UP:
drivers/pinctrl/pinctrl-mcp23s08.c:240:			mutex_lock(&mcp->lock);
drivers/pinctrl/pinctrl-mcp23s08.c-241-			ret = mcp_set_bit(mcp, MCP_GPPU, pin, arg);
--
drivers/pinctrl/pinctrl-mcp23s08.c=261=static int mcp23s08_direction_input(struct gpio_chip *chip, unsigned offset)
--
drivers/pinctrl/pinctrl-mcp23s08.c-265-
drivers/pinctrl/pinctrl-mcp23s08.c:266:	mutex_lock(&mcp->lock);
drivers/pinctrl/pinctrl-mcp23s08.c-267-	status = mcp_set_bit(mcp, MCP_IODIR, offset, true);
--
drivers/pinctrl/pinctrl-mcp23s08.c=273=static int mcp23s08_get(struct gpio_chip *chip, unsigned offset)
--
drivers/pinctrl/pinctrl-mcp23s08.c-277-
drivers/pinctrl/pinctrl-mcp23s08.c:278:	mutex_lock(&mcp->lock);
drivers/pinctrl/pinctrl-mcp23s08.c-279-
--
drivers/pinctrl/pinctrl-mcp23s08.c=293=static int mcp23s08_get_multiple(struct gpio_chip *chip,
--
drivers/pinctrl/pinctrl-mcp23s08.c-299-
drivers/pinctrl/pinctrl-mcp23s08.c:300:	mutex_lock(&mcp->lock);
drivers/pinctrl/pinctrl-mcp23s08.c-301-
--
drivers/pinctrl/pinctrl-mcp23s08.c=320=static int mcp23s08_set(struct gpio_chip *chip, unsigned int offset, int value)
--
drivers/pinctrl/pinctrl-mcp23s08.c-325-
drivers/pinctrl/pinctrl-mcp23s08.c:326:	mutex_lock(&mcp->lock);
drivers/pinctrl/pinctrl-mcp23s08.c-327-	ret = __mcp23s08_set(mcp, mask, !!value);
--
drivers/pinctrl/pinctrl-mcp23s08.c=333=static int mcp23s08_set_multiple(struct gpio_chip *chip,
--
drivers/pinctrl/pinctrl-mcp23s08.c-338-
drivers/pinctrl/pinctrl-mcp23s08.c:339:	mutex_lock(&mcp->lock);
drivers/pinctrl/pinctrl-mcp23s08.c-340-	ret = mcp_update_bits(mcp, MCP_OLAT, *mask, *bits);
--
drivers/pinctrl/pinctrl-mcp23s08.c=347=mcp23s08_direction_output(struct gpio_chip *chip, unsigned offset, int value)
--
drivers/pinctrl/pinctrl-mcp23s08.c-352-
drivers/pinctrl/pinctrl-mcp23s08.c:353:	mutex_lock(&mcp->lock);
drivers/pinctrl/pinctrl-mcp23s08.c-354-	status = __mcp23s08_set(mcp, mask, value);
--
drivers/pinctrl/pinctrl-mcp23s08.c=363=static irqreturn_t mcp23s08_irq(int irq, void *data)
--
drivers/pinctrl/pinctrl-mcp23s08.c-372-
drivers/pinctrl/pinctrl-mcp23s08.c:373:	mutex_lock(&mcp->lock);
drivers/pinctrl/pinctrl-mcp23s08.c-374-	if (mcp_read(mcp, MCP_INTF, &intf))
--
drivers/pinctrl/pinctrl-mcp23s08.c-463-	if (need_unmask) {
drivers/pinctrl/pinctrl-mcp23s08.c:464:		mutex_lock(&mcp->lock);
drivers/pinctrl/pinctrl-mcp23s08.c-465-		goto unlock;
--
drivers/pinctrl/pinctrl-mcp23s08.c=529=static void mcp23s08_irq_bus_lock(struct irq_data *data)
--
drivers/pinctrl/pinctrl-mcp23s08.c-533-
drivers/pinctrl/pinctrl-mcp23s08.c:534:	mutex_lock(&mcp->lock);
drivers/pinctrl/pinctrl-mcp23s08.c-535-	regcache_cache_only(mcp->regmap, true);
]

gemini-3.1-pro-preview

							input: 53327
							output: 28
							thoughts: 1354
						

**Analyzing and Refining the MCP2221 Driver's Interrupt Handling**

Okay, so I'm diving into this MCP2221 driver, specifically the interrupt handling part. First, I'm confirming my understanding: `mcp->lock` is held whenever a command is sent and a response is expected. This is crucial for data integrity. For example, in `mcp_gpio_get`, the mutex protects `mcp->txbuf` while the command is sent and the driver waits for the reply. This means `mcp->txbuf` *should* be stable when `mcp2221_raw_event` is called from the HID interrupt context.

Now, `mcp2221_raw_event` reads `mcp->txbuf[0]` to match it against `data[0]` from the incoming report. The question is, is this a reliable comparison? Yes, because `mcp_send_data_req_status` ensures that `mcp->txbuf[0]` contains the correct command byte while the driver is waiting for the response, thanks to the mutex and `mcp->wait_in_report`. So, `mcp2221_raw_event` can safely compare `mcp->txbuf[0]` with `data[0]`. If they don't match, it's a stray report – that's the logic.

But what about the initial state where `mcp->txbuf[0]` is 0? If an unsolicited report comes in (like `MCP2221_GPIO_SET`, which is 0x50), `data[0]` won't equal `mcp->txbuf[0]`, and the report will be correctly ignored. This is a very elegant solution to the problem of handling unsolicited reports. No problem, solved!

Let's verify that `mcp2221_raw_event` is *only* supposed to process reports when a command is pending. The comment confirms this: it's for responses to previously sent commands. Stray responses should result in `-EIO` or be ignored. If we ignore them, the timeout will eventually trigger for a pending command, or nothing will happen if no command is active.

Now, should we complete a command with `-EIO` if a stray response arrives while it is pending? If we did, the current pending command would fail immediately. But what if the stray response is a delayed response from a *previous* command that timed out? Completing the current command with `-EIO` would cause it to fail, *and* then the real response to the current command would be treated as a stray report! Ignoring the stray response is definitely the best approach so that the driver will properly wait for and handle the current command's response.

Okay, the current code completes with `-EIO` if `data[0]` is unknown. But it also *processes* responses for known commands (e.g., `MCP2221_GPIO_SET`) even if *we* didn't send that particular command. That's wrong. I think I have a solution:

```c
	if (unlikely(size < 64))
		return 1;

	if (data[0] != mcp->txbuf[0])
		return 1; /* Ignore stray response */
```

Is this safe? Well, I need to consider all the cases. What about I2C commands, like `MCP2221_I2C_WR_DATA` (0x90), `MCP2221_I2C_WR_NO_STOP` (0x94), `MCP2221_I2C_RD_DATA` (0x91), and `MCP2221_I2C_RD_RPT_START` (0x93)?

In `mcp_i2c_write`, `mcp->txbuf[0]` will be set to one of those command types. And the response from the MCP2221 will echo the *same* command byte back in `data[0]`. The MCP2221 does echo the command!

Okay, let's verify. In `mcp2221_raw_event`, we handle these I2C commands and make sure that, for example, if we sent `MCP2221_I2C_WR_DATA`, `mcp->txbuf[0]` will be `MCP2221_I2C_WR_DATA`, and the response will also have `data[0]` equal to it. The code holds up!

Is there a chance `mcp->txbuf[0]` could change before the response? No, because

map[Name:mcp_send_data_req_status]

map[References:[map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp2221_check_gpio_pinfunc SourceFile:drivers/hid/hid-mcp2221.c SourceLine:706] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp2221_write_raw SourceFile:drivers/hid/hid-mcp2221.c SourceLine:1125] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_cancel_last_cmd SourceFile:drivers/hid/hid-mcp2221.c SourceLine:218] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_chk_last_cmd_status SourceFile:drivers/hid/hid-mcp2221.c SourceLine:208] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_dir_set SourceFile:drivers/hid/hid-mcp2221.c SourceLine:760] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_get SourceFile:drivers/hid/hid-mcp2221.c SourceLine:723] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_get_direction SourceFile:drivers/hid/hid-mcp2221.c SourceLine:806] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_read_sram SourceFile:drivers/hid/hid-mcp2221.c SourceLine:646] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_gpio_set SourceFile:drivers/hid/hid-mcp2221.c SourceLine:743] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_i2c_smbus_read SourceFile:drivers/hid/hid-mcp2221.c SourceLine:344] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_i2c_smbus_read SourceFile:drivers/hid/hid-mcp2221.c SourceLine:357] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_i2c_write SourceFile:drivers/hid/hid-mcp2221.c SourceLine:284] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_init_work SourceFile:drivers/hid/hid-mcp2221.c SourceLine:1188] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_init_work SourceFile:drivers/hid/hid-mcp2221.c SourceLine:1199] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_set_i2c_speed SourceFile:drivers/hid/hid-mcp2221.c SourceLine:249] map[ReferenceKind:calls ReferencingEntityKind:function ReferencingEntityName:mcp_smbus_write SourceFile:drivers/hid/hid-mcp2221.c SourceLine:468]] TruncatedOutput:false]

gemini-3.1-pro-preview

							input: 56710
							output: 49
							thoughts: 12
						

Okay, here's my attempt at summarizing that thought process, keeping in mind I'm speaking to a fellow expert:

**Diving into `mcp_init_work`**

Alright, time to dig in. Let's get right to it – I need to take a look at the `mcp_init_work` function. That's where we'll start. It's the logical jumping-off point, and that's precisely where I'll begin. No need to waste time elsewhere when that's clearly the function to focus on.

map[ContextFile:drivers/hid/hid-mcp2221.c IncludeLines:true Name:mcp_init_work]

map[SourceCode:1176:	static void mcp_init_work(struct work_struct *work)
1177:	{
1178:		struct iio_dev *indio_dev;
1179:		struct mcp2221 *mcp = container_of(work, struct mcp2221, init_work.work);
1180:		struct mcp2221_iio *data;
1181:		static int retries = 5;
1182:		int ret, num_channels;
1183:	
1184:		hid_hw_power(mcp->hdev, PM_HINT_FULLON);
1185:		mutex_lock(&mcp->lock);
1186:	
1187:		mcp->txbuf[0] = MCP2221_GET_SRAM_SETTINGS;
1188:		ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
1189:	
1190:		if (ret == -EAGAIN)
1191:			goto reschedule_task;
1192:	
1193:		num_channels = mcp_iio_channels(mcp);
1194:		if (!num_channels)
1195:			goto unlock;
1196:	
1197:		mcp->txbuf[0] = MCP2221_READ_FLASH_DATA;
1198:		mcp->txbuf[1] = 0;
1199:		ret = mcp_send_data_req_status(mcp, mcp->txbuf, 2);
1200:	
1201:		if (ret == -EAGAIN)
1202:			goto reschedule_task;
1203:	
1204:		indio_dev = devm_iio_device_alloc(&mcp->hdev->dev, sizeof(*data));
1205:		if (!indio_dev)
1206:			goto unlock;
1207:	
1208:		data = iio_priv(indio_dev);
1209:		data->mcp = mcp;
1210:	
1211:		indio_dev->name = "mcp2221";
1212:		indio_dev->modes = INDIO_DIRECT_MODE;
1213:		indio_dev->info = &mcp2221_info;
1214:		indio_dev->channels = mcp->iio_channels;
1215:		indio_dev->num_channels = num_channels;
1216:	
1217:		devm_iio_device_register(&mcp->hdev->dev, indio_dev);
1218:	
1219:	unlock:
1220:		mutex_unlock(&mcp->lock);
1221:		hid_hw_power(mcp->hdev, PM_HINT_NORMAL);
1222:	
1223:		return;
1224:	
1225:	reschedule_task:
1226:		mutex_unlock(&mcp->lock);
1227:		hid_hw_power(mcp->hdev, PM_HINT_NORMAL);
1228:	
1229:		if (!retries--)
1230:			return;
1231:	
1232:		/* Device is not ready to read SRAM or FLASH data, try again */
1233:		schedule_delayed_work(&mcp->init_work, msecs_to_jiffies(100));
1234:	}
 SourceFile:drivers/hid/hid-mcp2221.c]

gemini-3.1-pro-preview

							input: 57883
							output: 23
							thoughts: 1848
						

**Deep Dive into the MCP2221 Data Handling Logic**

Okay, let's break this down systematically. My initial thought was that comparing `data[0]` with `mcp->txbuf[0]` in `mcp2221_raw_event` is safe because the command byte is always set in `mcp->txbuf[0]` before the data is sent.

But I had a nagging question: What if `mcp2221_raw_event` is called *before* `mcp_send_data_req_status` actually populates `mcp->txbuf[0]`? Then, `mcp->txbuf` is zero-initialized. Zero wouldn't match, and the function would return. But, zero is not a valid command byte, which made me think this is OK.

Then I wondered about `MCP2221_SUCCESS` (0). But that's used in `data[1]`, not `data[0]`. Okay, let's confirm the command bytes: `0x90`, `0x94`, `0x91`, `0x93`, `0x40`, `0x10`, `0x20`, `0x10`, `0x50`, `0x51`, `0x60`, `0x61`, `0xB0`. None of those are zero. So a zeroed `mcp->txbuf[0]` will *never* match a real command, which is safe.

Next scenario: What if `mcp_send_data_req_status` sets `mcp->txbuf[0]`, sends the report, but then times out? The timed-out command is still in `mcp->txbuf[0]`. Then, an unsolicited report *with the same command byte* arrives. It would trigger the processing and call `complete`. But because the thread is no longer waiting, the completion state is just set to done, and the next `mcp_send_data_req_status` would call `reinit_completion`, clearing the stray completion. The logic is robust, so this is safe!

Now, let's revisit that `mcp2221_raw_event` function again. I went over it again to check any corner cases. Is there a case where it would be called for an output or feature report? Nope. `raw_event` is only for input reports via the interrupt endpoint.

Another thought: What if `data[0]` is `MCP2221_I2C_PARAM_OR_STATUS` (0x10)? In that case, `mcp2221_raw_event` checks `mcp->txbuf[3]`. But before that, we do `data[0] != mcp->txbuf[0]`. It passes the check because `mcp->txbuf[0]` would be set to 0x10 already. It's correct because the logic works as intended.

To be extra careful, let me check other places that use `mcp->txbuf`. In `mcp_i2c_smbus_read`, the function sets `mcp->txbuf[0]`, then sends data, then sets `MCP2221_I2C_GET_DATA` to be sent. The approach is right.

Now, `mcp->gp_idx`. If `data[0] == mcp->txbuf[0]`, then `mcp->gp_idx` *must* be valid because it's set by the same function that set `mcp->txbuf[0]`. In `mcp_gpio_set`, `mcp->gp_idx` is calculated with an offset, and thus valid.

What about a timeout scenario? If `mcp_gpio_set` times out, `mcp->txbuf[0]` remains set, and a malicious device sends back a response with that same byte. `data[0]` would match, and it would access `data[mcp->gp_idx - 1]`. But since `mcp->gp_idx` is valid from the timed-out call, it's safe. What is `mcp->gp_idx` somehow 0? No way. `mcp->txbuf[0]` can only be set from `mcp_gpio_set` (or `dir`), and they will both set a valid `mcp->gp_idx`.

map[Expression:mcp->txbuf\[0\] =]

map[Output:drivers/hid/hid-mcp2221.c=203=static int mcp_chk_last_cmd_status(struct mcp2221 *mcp)
--
drivers/hid/hid-mcp2221.c-205-	memset(mcp->txbuf, 0, 8);
drivers/hid/hid-mcp2221.c:206:	mcp->txbuf[0] = MCP2221_I2C_PARAM_OR_STATUS;
drivers/hid/hid-mcp2221.c-207-
--
drivers/hid/hid-mcp2221.c=212=static int mcp_cancel_last_cmd(struct mcp2221 *mcp)
--
drivers/hid/hid-mcp2221.c-214-	memset(mcp->txbuf, 0, 8);
drivers/hid/hid-mcp2221.c:215:	mcp->txbuf[0] = MCP2221_I2C_PARAM_OR_STATUS;
drivers/hid/hid-mcp2221.c-216-	mcp->txbuf[2] = MCP2221_I2C_CANCEL;
--
drivers/hid/hid-mcp2221.c=240=static int mcp_set_i2c_speed(struct mcp2221 *mcp)
--
drivers/hid/hid-mcp2221.c-244-	memset(mcp->txbuf, 0, 8);
drivers/hid/hid-mcp2221.c:245:	mcp->txbuf[0] = MCP2221_I2C_PARAM_OR_STATUS;
drivers/hid/hid-mcp2221.c-246-	mcp->txbuf[3] = MCP2221_I2C_SET_SPEED;
--
drivers/hid/hid-mcp2221.c=267=static int mcp_i2c_write(struct mcp2221 *mcp,
--
drivers/hid/hid-mcp2221.c-276-	do {
drivers/hid/hid-mcp2221.c:277:		mcp->txbuf[0] = type;
drivers/hid/hid-mcp2221.c-278-		mcp->txbuf[1] = msg->len & 0xff;
--
drivers/hid/hid-mcp2221.c=319=static int mcp_i2c_smbus_read(struct mcp2221 *mcp,
--
drivers/hid/hid-mcp2221.c-326-
drivers/hid/hid-mcp2221.c:327:	mcp->txbuf[0] = type;
drivers/hid/hid-mcp2221.c-328-	if (msg) {
--
drivers/hid/hid-mcp2221.c-354-		memset(mcp->txbuf, 0, 4);
drivers/hid/hid-mcp2221.c:355:		mcp->txbuf[0] = MCP2221_I2C_GET_DATA;
drivers/hid/hid-mcp2221.c-356-
--
drivers/hid/hid-mcp2221.c=435=static int mcp_smbus_write(struct mcp2221 *mcp, u16 addr,
--
drivers/hid/hid-mcp2221.c-440-
drivers/hid/hid-mcp2221.c:441:	mcp->txbuf[0] = type;
drivers/hid/hid-mcp2221.c-442-	mcp->txbuf[1] = len + 1; /* 1 is due to command byte itself */
--
drivers/hid/hid-mcp2221.c=638=static int mcp_gpio_read_sram(struct mcp2221 *mcp)
--
drivers/hid/hid-mcp2221.c-642-	memset(mcp->txbuf, 0, 64);
drivers/hid/hid-mcp2221.c:643:	mcp->txbuf[0] = MCP2221_GET_SRAM_SETTINGS;
drivers/hid/hid-mcp2221.c-644-
--
drivers/hid/hid-mcp2221.c=657=static int mcp2221_check_gpio_pinfunc(struct mcp2221 *mcp)
--
drivers/hid/hid-mcp2221.c-685-	memset(mcp->txbuf, 0, 64);
drivers/hid/hid-mcp2221.c:686:	mcp->txbuf[0] = MCP2221_SET_SRAM_SETTINGS;
drivers/hid/hid-mcp2221.c-687-
--
drivers/hid/hid-mcp2221.c=712=static int mcp_gpio_get(struct gpio_chip *gc,
--
drivers/hid/hid-mcp2221.c-717-
drivers/hid/hid-mcp2221.c:718:	mcp->txbuf[0] = MCP2221_GPIO_GET;
drivers/hid/hid-mcp2221.c-719-
--
drivers/hid/hid-mcp2221.c=729=static int mcp_gpio_set(struct gpio_chip *gc, unsigned int offset, int value)
--
drivers/hid/hid-mcp2221.c-734-	memset(mcp->txbuf, 0, 18);
drivers/hid/hid-mcp2221.c:735:	mcp->txbuf[0] = MCP2221_GPIO_SET;
drivers/hid/hid-mcp2221.c-736-
--
drivers/hid/hid-mcp2221.c=749=static int mcp_gpio_dir_set(struct mcp2221 *mcp,
--
drivers/hid/hid-mcp2221.c-752-	memset(mcp->txbuf, 0, 18);
drivers/hid/hid-mcp2221.c:753:	mcp->txbuf[0] = MCP2221_GPIO_SET;
drivers/hid/hid-mcp2221.c-754-
--
drivers/hid/hid-mcp2221.c=795=static int mcp_gpio_get_direction(struct gpio_chip *gc,
--
drivers/hid/hid-mcp2221.c-800-
drivers/hid/hid-mcp2221.c:801:	mcp->txbuf[0] = MCP2221_GPIO_GET;
drivers/hid/hid-mcp2221.c-802-
--
drivers/hid/hid-mcp2221.c=1108=static int mcp2221_write_raw(struct iio_dev *indio_dev,
--
drivers/hid/hid-mcp2221.c-1121-	memset(mcp->txbuf, 0, 12);
drivers/hid/hid-mcp2221.c:1122:	mcp->txbuf[0] = MCP2221_SET_SRAM_SETTINGS;
drivers/hid/hid-mcp2221.c-1123-	mcp->txbuf[4] = BIT(7) | val;
--
drivers/hid/hid-mcp2221.c=1176=static void mcp_init_work(struct work_struct *work)
--
drivers/hid/hid-mcp2221.c-1186-
drivers/hid/hid-mcp2221.c:1187:	mcp->txbuf[0] = MCP2221_GET_SRAM_SETTINGS;
drivers/hid/hid-mcp2221.c-1188-	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
--
drivers/hid/hid-mcp2221.c-1196-
drivers/hid/hid-mcp2221.c:1197:	mcp->txbuf[0] = MCP2221_READ_FLASH_DATA;
drivers/hid/hid-mcp2221.c-1198-	mcp->txbuf[1] = 0;
]

gemini-3.1-pro-preview

							input: 62990
							output: 241
							thoughts: 904
						

**Analyzing and Securing the MCP2221 Communication Protocol**

Okay, let's think this through. My understanding is that `mcp->txbuf[0]` is solely set by the functions responsible for transmitting commands, specifically setting it to the command byte itself. The functions `mcp_gpio_set` and `mcp_gpio_dir_set` are unique in that they set it to `MCP2221_GPIO_SET`, and they both populate `mcp->gp_idx`. Similarly, `mcp_gpio_get` and `mcp_gpio_get_direction` set it to `MCP2221_GPIO_GET`, also populating `mcp->gp_idx`. Therefore, the logic `if (data[0] == mcp->txbuf[0])` seems to correctly validate that `mcp->gp_idx` holds a meaningful value for the given command.

However, consider this edge case: `mcp_gpio_set` is invoked, setting `mcp->txbuf[0] = MCP2221_GPIO_SET` and `mcp->gp_idx = 3`. Then, a timeout occurs. Subsequently, `mcp_gpio_get` is called, setting `mcp->txbuf[0] = MCP2221_GPIO_GET` and `mcp->gp_idx = 2`. Now, a *delayed* response from the *initial* `MCP2221_GPIO_SET` command finally arrives. In this scenario, `data[0]` would be `MCP2221_GPIO_SET`, but `mcp->txbuf[0]` would be `MCP2221_GPIO_GET`. This means `data[0] != mcp->txbuf[0]`. Thus, the old response is correctly disregarded. Excellent, this is precisely what we want!

So, the proposed fix, which is:
```c
	if (unlikely(size < 64))
		return 1;

	if (data[0] != mcp->txbuf[0])
		return 1;
```
seems robust. It ensures we only process responses that match our current command, effectively rejecting stale or unsolicited data.

Now, a crucial question: are there other circumstances where `mcp2221_raw_event` might be called with `mcp->txbuf[0]` not corresponding to the expected response? What about the possibility of an error code in `data[0]`? No, that's not how the MCP2221 works. The device always echoes the command byte in `data[0]`, and the error code, if any, is located in `data[1]`. Examining `mcp2221_raw_event`:
```c
	switch (data[0]) {

	case MCP2221_I2C_WR_DATA:
	case MCP2221_I2C_WR_NO_STOP:
	case MCP2221_I2C_RD_DATA:
	case MCP2221_I2C_RD_RPT_START:
		switch (data[1]) {
		case MCP2221_SUCCESS:
...
```
Confirms this. `data[0]` consistently holds the command byte.

Next consideration: what happens if `mcp2221_raw_event` is called with `size < 64`? Simply returning 1 would cause it to be ignored. Is it even *possible* for a valid response to be shorter than 64 bytes? The MCP2221 HID report descriptor *specifies* a report size of 64 bytes. If the USB host receives a short packet, the `size` might indeed be less than 64. However, `mcp2221_raw_event` access up to `data[60]` (for the check `data[3] > 60` and the `memcpy`). Also, `data[50]` is accessed for ADC data. This means that a report smaller than 64 bytes would lead to out-of-bounds reads. Therefore, `size` MUST be at least 64 bytes. A shorter packet is, in all cases, an invalid report.

To be extra certain, consider the potential for malicious USB devices. It is indeed conceivable that a rogue device could send a short, malformed report to trigger issues.

Therefore, the condition `if (unlikely(size < 64)) return 1;` is not only correct but essential for preventing potential vulnerabilities related to short reports.

Let's implement this patch and safeguard the system.

map[CurrentCode:static int mcp2221_raw_event(struct hid_device *hdev,
				struct hid_report *report, u8 *data, int size)
{
	u8 *buf;
	struct mcp2221 *mcp = hid_get_drvdata(hdev);

	switch (data[0]) { NewCode:static int mcp2221_raw_event(struct hid_device *hdev,
				struct hid_report *report, u8 *data, int size)
{
	u8 *buf;
	struct mcp2221 *mcp = hid_get_drvdata(hdev);

	if (unlikely(size < 64))
		return 1;

	if (data[0] != mcp->txbuf[0])
		return 1;

	switch (data[0]) { SourceFile:drivers/hid/hid-mcp2221.c]

map[]

gemini-3.1-pro-preview

							input: 65166
							output: 29
							thoughts: 7
						

Okay, I'm ready to dive into that "diff" and give you my expert take. Here's my thought process:

**Diving into the Code Change**

Alright, a diff is in front of me, which means we're looking at a comparison between two versions of some code, config, or data. My first instinct is to zoom in on the most crucial areas of the changes – those likely to have the biggest impact, or where I expect potential problems. I immediately start scanning for:

*   **Core Logic Alterations:** What fundamental algorithms or data structures have been modified? That's always my primary focus.
*   **Dependency Updates:** Any changes to external libraries or APIs? Those can introduce breaking changes or security vulnerabilities if not carefully vetted.
*   **Performance Implications:** Is the change likely to speed things up, slow things down, or introduce any new bottlenecks? I'm looking for anything that could impact throughput or latency.
*   **Security Concerns:** Did the change touch any areas related to authentication, authorization, or data handling? Any red flags there are going to get my immediate attention.
*   **Error Handling:** Are there any new error conditions, and how are they being handled? Proper error management is critical, and often an afterthought that can be improved.
*   **Edge Cases:** I'm mentally testing the changes against scenarios. Any potential edge cases I can see? The diff is likely to show what the developer tested, so I can use that to formulate my own tests.
*   **Stylistic Changes:** Does the code follow our style guide? Consistency is crucial for maintainability.

Now, as I go through the diff, I'm already formulating test cases, potential follow-up questions, and likely refactor suggestions in my head. I'm going to look for any area that is not quite consistent with the standard or the project's standards. My review is going to address what the code does, and what it *should* do, as well as considering if the change is a complete solution.

map[File:drivers/hid/hid-mcp2221.c]

map[Output:diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index e4ddd8e92..7f4f2110b 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -849,199 +849,205 @@ static int mcp_get_i2c_eng_state(struct mcp2221 *mcp,
 /*
  * MCP2221 uses interrupt endpoint for input reports. This function
  * is called by HID layer when it receives i/p report from mcp2221,
  * which is actually a response to the previously sent command.
  *
  * MCP2221A firmware specific return codes are parsed and 0 or
  * appropriate negative error code is returned. Delayed response
  * results in timeout error and stray reponses results in -EIO.
  */
 static int mcp2221_raw_event(struct hid_device *hdev,
 				struct hid_report *report, u8 *data, int size)
 {
 	u8 *buf;
 	struct mcp2221 *mcp = hid_get_drvdata(hdev);
 
+	if (unlikely(size < 64))
+		return 1;
+
+	if (data[0] != mcp->txbuf[0])
+		return 1;
+
 	switch (data[0]) {
 
 	case MCP2221_I2C_WR_DATA:
 	case MCP2221_I2C_WR_NO_STOP:
 	case MCP2221_I2C_RD_DATA:
 	case MCP2221_I2C_RD_RPT_START:
 		switch (data[1]) {
 		case MCP2221_SUCCESS:
 			mcp->status = 0;
 			break;
 		default:
 			mcp->status = mcp_get_i2c_eng_state(mcp, data, 2);
 		}
 		complete(&mcp->wait_in_report);
 		break;
 
 	case MCP2221_I2C_PARAM_OR_STATUS:
 		switch (data[1]) {
 		case MCP2221_SUCCESS:
 			if ((mcp->txbuf[3] == MCP2221_I2C_SET_SPEED) &&
 				(data[3] != MCP2221_I2C_SET_SPEED)) {
 				mcp->status = -EAGAIN;
 				break;
 			}
 			if (data[20] & MCP2221_I2C_MASK_ADDR_NACK) {
 				mcp->status = -ENXIO;
 				break;
 			}
 			mcp->status = mcp_get_i2c_eng_state(mcp, data, 8);
 #if IS_REACHABLE(CONFIG_IIO)
 			memcpy(&mcp->adc_values, &data[50], sizeof(mcp->adc_values));
 #endif
 			break;
 		default:
 			mcp->status = -EIO;
 		}
 		complete(&mcp->wait_in_report);
 		break;
 
 	case MCP2221_I2C_GET_DATA:
 		switch (data[1]) {
 		case MCP2221_SUCCESS:
 			if (data[2] == MCP2221_I2C_ADDR_NACK) {
 				mcp->status = -ENXIO;
 				break;
 			}
 			if (!mcp_get_i2c_eng_state(mcp, data, 2)
 				&& (data[3] == 0)) {
 				mcp->status = 0;
 				break;
 			}
 			if (data[3] == 127) {
 				mcp->status = -EIO;
 				break;
 			}
 			if (data[2] == MCP2221_I2C_READ_COMPL ||
 			    data[2] == MCP2221_I2C_READ_PARTIAL) {
 				if (!mcp->rxbuf || mcp->rxbuf_idx < 0 || data[3] > 60) {
 					mcp->status = -EINVAL;
 					break;
 				}
 				if (mcp->rxbuf_idx + data[3] > mcp->rxbuf_size) {
 					mcp->status = -EINVAL;
 					break;
 				}
 				buf = mcp->rxbuf;
 				memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
 				mcp->rxbuf_idx = mcp->rxbuf_idx + data[3];
 				mcp->status = 0;
 				break;
 			}
 			mcp->status = -EIO;
 			break;
 		default:
 			mcp->status = -EIO;
 		}
 		complete(&mcp->wait_in_report);
 		break;
 
 	case MCP2221_GPIO_GET:
 		switch (data[1]) {
 		case MCP2221_SUCCESS:
 			if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
 				(data[mcp->gp_idx + 1] == MCP2221_ALT_F_NOT_GPIOD)) {
 				mcp->status = -ENOENT;
 			} else {
 				mcp->status = !!data[mcp->gp_idx];
 				mcp->gpio_dir = data[mcp->gp_idx + 1];
 			}
 			break;
 		default:
 			mcp->status = -EAGAIN;
 		}
 		complete(&mcp->wait_in_report);
 		break;
 
 	case MCP2221_GPIO_SET:
 		switch (data[1]) {
 		case MCP2221_SUCCESS:
 			if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
 				(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
 				mcp->status = -ENOENT;
 			} else {
 				mcp->status = 0;
 			}
 			break;
 		default:
 			mcp->status = -EAGAIN;
 		}
 		complete(&mcp->wait_in_report);
 		break;
 
 	case MCP2221_SET_SRAM_SETTINGS:
 		switch (data[1]) {
 		case MCP2221_SUCCESS:
 			mcp->status = 0;
 			break;
 		default:
 			mcp->status = -EAGAIN;
 		}
 		complete(&mcp->wait_in_report);
 		break;
 
 	case MCP2221_GET_SRAM_SETTINGS:
 		switch (data[1]) {
 		case MCP2221_SUCCESS:
 			memcpy(&mcp->mode, &data[22], 4);
 #if IS_REACHABLE(CONFIG_IIO)
 			mcp->dac_value = data[6] & GENMASK(4, 0);
 #endif
 			mcp->status = 0;
 			break;
 		default:
 			mcp->status = -EAGAIN;
 		}
 		complete(&mcp->wait_in_report);
 		break;
 
 	case MCP2221_READ_FLASH_DATA:
 		switch (data[1]) {
 		case MCP2221_SUCCESS:
 			mcp->status = 0;
 
 			/* Only handles CHIP SETTINGS subpage currently */
 			if (mcp->txbuf[1] != 0) {
 				mcp->status = -EIO;
 				break;
 			}
 
 #if IS_REACHABLE(CONFIG_IIO)
 			{
 				u8 tmp;
 				/* DAC scale value */
 				tmp = FIELD_GET(GENMASK(7, 6), data[6]);
 				if ((data[6] & BIT(5)) && tmp)
 					mcp->dac_scale = tmp + 4;
 				else
 					mcp->dac_scale = 5;
 
 				/* ADC scale value */
 				tmp = FIELD_GET(GENMASK(4, 3), data[7]);
 				if ((data[7] & BIT(2)) && tmp)
 					mcp->adc_scale = tmp - 1;
 				else
 					mcp->adc_scale = 0;
 			}
 #endif
 
 			break;
 		default:
 			mcp->status = -EAGAIN;
 		}
 		complete(&mcp->wait_in_report);
 		break;
 
 	default:
 		mcp->status = -EIO;
 		complete(&mcp->wait_in_report);
 	}
 
 	return 1;
 }
 
 /* Device resource managed function for HID unregistration */
]

gemini-3.1-pro-preview

							input: 68021
							output: 903
							thoughts: 702
						

**Analyzing the Fix for the MCP2221 Driver Vulnerability**

Okay, this fix looks rock solid. The core issue, as I understand it, stems from `mcp2221_raw_event` being too trusting. It's processing incoming HID reports without validating if they're actually legitimate responses to a command we sent, and it's also not checking the report size.

The crux of the vulnerability lies in that unchecked `mcp->gp_idx` access. If a rogue device, or even a corrupted report, somehow throws a `MCP2221_GPIO_SET` response at the driver *before* we've actually sent a GPIO command, `mcp->gp_idx` will be uninitialized – likely zero. This immediately leads to an out-of-bounds read when we attempt to access `data[-1]`, and that's a serious problem, as it is a read from uninitialized memory.

The proposed solution neatly addresses this. First, a simple size check: we're verifying that `size` is at least 64 bytes, which is the expected report size from the MCP2221. That's a basic sanity check, but important.

Second, and more importantly, we introduce a crucial check: `data[0] == mcp->txbuf[0]`. This acts as a gatekeeper. Because `mcp->txbuf[0]` stores the command byte *only* when we send a command, and because `mcp->gp_idx` is *always* set at the same time for GPIO commands, this guarantees that the incoming report is actually a response to the command we just sent. This ensures that `mcp->gp_idx` is valid, it also ensures that it corresponds to the correct command type, and prevents any malicious report from corrupting or reading the data.

I did a quick spot check to confirm the validity of `mcp->gp_idx`. I looked through all the uses of `mcp->gp_idx` and made sure that it was always initialized alongside `mcp->txbuf[0]`. No uninitialized access here. I also checked all occurrences of where `mcp->txbuf[0]` could be set to `MCP2221_GPIO_SET` or `MCP2221_GPIO_GET` and confirm that `mcp->gp_idx` is initialized in all cases.

I'm confident this fix is complete and correct. It handles both the bounds check on `size` and the `mcp->gp_idx` issue effectively. Now I can move on to drafting the final response.

map[PatchDiff:diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index e4ddd8e92..7f4f2110b 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -861,6 +861,12 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 	u8 *buf;
 	struct mcp2221 *mcp = hid_get_drvdata(hdev);
 
+	if (unlikely(size < 64))
+		return 1;
+
+	if (data[0] != mcp->txbuf[0])
+		return 1;
+
 	switch (data[0]) {
 
 	case MCP2221_I2C_WR_DATA:
 TestError:]

gemini-3.1-pro-preview

map[FixesHash:328de1c519c5c0925151cae47944a1c1a0333bcd]

You are an experienced Linux kernel developer tasked with identifying the commit
that introduced the bug being fixed. Identifying the correct buggy commit is crucial
for proper kernel maintenance (backporting to stable trees, etc.).

Your investigation strategy:
1. Examine the patch that fixes the bug. Use git tools (like git-log or git-blame)
   to trace the history of the lines or functions modified by the patch.
2. Analyze the stack trace in the crash report. Identify the key files and functions
   involved in the crash and investigate their history to see when the problematic
   logic was introduced.
3. Compare the bug explanation with the commit history to find the point where
   the described logic error first appeared.

A bug is typically introduced when a piece of code is first written, or when
a refactoring changed its logic in a way that introduced the bug.
Trace the history of relevant symbols or find when specific code patterns were introduced/removed.

You must provide exactly one bug-introducing commit hash.
If you are unable to confidently determine the bug-introducing commit after investigation,
return an empty string rather than guessing.

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.

The crash is:

==================================================================
BUG: KASAN: slab-out-of-bounds in mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
Read of size 1 at addr ffff888111fe7fff by task ktimers/0/16

CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted syzkaller #1 PREEMPT_{RT,(full)} 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description+0x55/0x1e0 mm/kasan/report.c:378
 print_report+0x58/0x70 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
 __hid_input_report+0x42b/0x590 drivers/hid/hid-core.c:2161
 hid_irq_in+0x495/0x710 drivers/hid/usbhid/hid-core.c:286
 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657
 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005
 __run_hrtimer kernel/time/hrtimer.c:1930 [inline]
 __hrtimer_run_queues+0x405/0xb10 kernel/time/hrtimer.c:1994
 hrtimer_run_softirq+0x18f/0x260 kernel/time/hrtimer.c:2011
 handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 run_ktimerd+0x69/0x100 kernel/softirq.c:1151
 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

Allocated by task 2:
 kasan_save_stack mm/kasan/common.c:57 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
 unpoison_slab_object mm/kasan/common.c:340 [inline]
 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
 kasan_slab_alloc include/linux/kasan.h:253 [inline]
 slab_post_alloc_hook mm/slub.c:4569 [inline]
 slab_alloc_node mm/slub.c:4898 [inline]
 kmem_cache_alloc_node_noprof+0x22a/0x6e0 mm/slub.c:4950
 alloc_task_struct_node kernel/fork.c:187 [inline]
 dup_task_struct+0x52/0x840 kernel/fork.c:918
 copy_process+0x89b/0x4450 kernel/fork.c:2090
 kernel_clone+0x283/0x870 kernel/fork.c:2721
 kernel_thread+0x13f/0x1b0 kernel/fork.c:2782
 create_kthread kernel/kthread.c:459 [inline]
 kthreadd+0x4ec/0x6e0 kernel/kthread.c:817
 ret_from_fork+0x514/0xb70 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 ffff888111fe5880
 which belongs to the cache task_struct of size 7296
The buggy address is located 2815 bytes to the right of
 allocated 7296-byte region [ffff888111fe5880, ffff888111fe7500)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x111fe0
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff888116e25541
flags: 0x100000000000040(head|node=0|zone=2)
page_type: f5(slab)
raw: 0100000000000040 ffff8881012e0500 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800040004 00000000f5000000 ffff888116e25541
head: 0100000000000040 ffff8881012e0500 dead000000000100 dead000000000122
head: 0000000000000000 0000000800040004 00000000f5000000 ffff888116e25541
head: 0100000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
head: 0000000000000000 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 2388, tgid 2388 (kworker/u9:11), ts 15402053339, free_ts 0
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1858
 prep_new_page mm/page_alloc.c:1866 [inline]
 get_page_from_freelist+0x27c8/0x2840 mm/page_alloc.c:3946
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5226
 alloc_slab_page mm/slub.c:3278 [inline]
 allocate_slab+0x77/0x660 mm/slub.c:3467
 new_slab mm/slub.c:3525 [inline]
 refill_objects+0x33c/0x3d0 mm/slub.c:7271
 refill_sheaf mm/slub.c:2816 [inline]
 __pcs_replace_empty_main+0x373/0x720 mm/slub.c:4651
 alloc_from_pcs mm/slub.c:4749 [inline]
 slab_alloc_node mm/slub.c:4883 [inline]
 kmem_cache_alloc_node_noprof+0x4f4/0x6e0 mm/slub.c:4950
 alloc_task_struct_node kernel/fork.c:187 [inline]
 dup_task_struct+0x52/0x840 kernel/fork.c:918
 copy_process+0x89b/0x4450 kernel/fork.c:2090
 kernel_clone+0x283/0x870 kernel/fork.c:2721
 user_mode_thread+0x110/0x180 kernel/fork.c:2797
 call_usermodehelper_exec_work+0x5c/0x230 kernel/umh.c:171
 process_one_work kernel/workqueue.c:3314 [inline]
 process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397
 worker_thread+0x8a2/0xda0 kernel/workqueue.c:3478
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
page_owner free stack trace missing

Memory state around the buggy address:
 ffff888111fe7e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff888111fe7f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888111fe7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                ^
 ffff888111fe8000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff888111fe8080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================



The explanation of the root cause is:

An analysis of the crash report and the source code reveals that the root cause is an **out-of-bounds read due to a negative array index** in `mcp2221_raw_event()`, combined with a lack of bounds checking on the incoming HID report size.

### Detailed Explanation

1. **Uninitialized State**: 
   When the `mcp2221` device is probed, its state structure is allocated using `devm_kzalloc()`, which zero-initializes all fields. The `mcp->gp_idx` field (a `u8`) is initialized to `0`. It is only updated to a valid positive offset (e.g., 3, 7, 11, or 15) when the GPIO subsystem invokes the driver's GPIO operations like `mcp_gpio_set()`.

2. **The Vulnerability**:
   If the device sends an `MCP2221_GPIO_SET` (0x50) input report *before* any GPIO operations are performed (or if a malicious device/reproducer injects one), `mcp2221_raw_event()` processes the report while `mcp->gp_idx` is still `0`.
   
   Looking at `drivers/hid/hid-mcp2221.c` around line 964:
   ```c
   960:		case MCP2221_GPIO_SET:
   961:			switch (data[1]) {
   962:			case MCP2221_SUCCESS:
   963:				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
   964:					(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
   ```
   Because `mcp->gp_idx` is `0`, the expression `mcp->gp_idx - 1` promotes the `u8` to an `int`, resulting in `-1`. This causes the code to access `data[-1]`.

3. **Memory Layout and the KASAN Report**:
   The `data` pointer passed to `mcp2221_raw_event()` points to the URB transfer buffer, which is allocated by the USB core via `kmalloc()` (e.g., from the `kmalloc-64` cache). 
   
   In the crashing scenario, the SLUB allocator placed this 64-byte buffer at the very beginning of a new page, exactly at address `ffff888111fe8000`. 
   
   When the code evaluates `data[-1]`, it reads the address `ffff888111fe7fff`. This address is the last byte of the *previous* physical page. As shown in the KASAN report, the previous page (`pfn:0x111fe0`) was an order-3 slab page belonging to the `task_struct` cache. The last `task_struct` object in that page ended at `ffff888111fe7500`, and the remainder of the page was SLUB padding/redzone (filled with `fc`).
   
   KASAN intercepted the read at `ffff888111fe7fff` and correctly reported it as a slab-out-of-bounds read located 2815 bytes to the right of the `task_struct` object.

   ```text
    ffff888111fe7f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
   >ffff888111fe7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                   ^ (data[-1] at ffff888111fe7fff)
    ffff888111fe8000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  <-- data (urb->transfer_buffer)
   ```

### How to Fix

To fix this bug, `mcp2221_raw_event()` needs two corrections:
1. **Validate `mcp->gp_idx`**: Ensure that `mcp->gp_idx` is valid (e.g., `mcp->gp_idx > 0`) before using it as an array index.
2. **Bounds Checking**: The function completely lacks bounds checking on the `size` parameter. It blindly accesses `data[0]`, `data[1]`, and various other offsets (like `data[50]` in the `MCP2221_I2C_PARAM_OR_STATUS` case). It should verify that `size` is large enough for the specific report being processed before accessing the `data` array.


The patch that fixes the bug is:

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index e4ddd8e92..7f4f2110b 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -861,6 +861,12 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 	u8 *buf;
 	struct mcp2221 *mcp = hid_get_drvdata(hdev);
 
+	if (unlikely(size < 64))
+		return 1;
+
+	if (data[0] != mcp->txbuf[0])
+		return 1;
+
 	switch (data[0]) {
 
 	case MCP2221_I2C_WR_DATA:


Search for the commit(s) that introduced this bug.

gemini-3.1-pro-preview

							input: 7971
							output: 68
							thoughts: 210
						

**Pinpointing the Root Cause of the Out-of-Bounds Read**

Okay, so we've got a patch that fixes an out-of-bounds read in `mcp2221_raw_event()` within the `hid-mcp2221.c` driver. My immediate goal is to locate the exact commit that introduced this bug. The patch itself is quite telling; it's added two checks: `if (unlikely(size < 64))` and `if (data[0] != mcp->txbuf[0])` at the start of `mcp2221_raw_event()`. We need to figure out *why* these checks are necessary.

The accompanying explanation hits the nail on the head – it's all about `mcp->gp_idx` being used as an index and how if this index is zero, `data[mcp->gp_idx - 1]` becomes `data[-1]`, resulting in our out-of-bounds read.  It also notes the patch addresses the bounds checking on `size`. So, the core of the problem seems to be an unchecked index or a mismatch between the expected and actual size of the data.

My strategy is clear: I need to dig into the history of `drivers/hid/hid-mcp2221.c` focusing on the evolution of the `mcp2221_raw_event()` function. I'll be looking for changes related to `mcp->gp_idx`, how `size` is handled, and any modifications that might have introduced a logic error leading to an invalid index. Armed with that information, I should be able to pinpoint the culprit commit and understand the genesis of this bug.

map[CodeRegexp:mcp2221_raw_event Count:10 SourcePath:drivers/hid/hid-mcp2221.c SymbolName:mcp2221_raw_event]

map[Output:f097d246677b HID: mcp2221: fix OOB write in mcp2221_raw_event()
b56cc41a3ae7 hid: fix I2C read buffer overflow in raw_event() for mcp2221
2682468671aa HID: mcp2221: Handle reads greater than 60 bytes
daf405c8b9b9 HID: mcp2221: fix usage of tmp variable in mcp2221_raw_event()
960f9df7c620 HID: mcp2221: add ADC/DAC support via iio subsystem
deb3b88bbb7a HID: mcp2221: switch i2c registration to devm functions
567b8e9fed8a HID: mcp2221: Fix GPIO output handling
328de1c519c5 HID: mcp2221: add GPIO functionality support
67a95c21463d HID: mcp2221: add usb to i2c-smbus host bridge
]

gemini-3.1-pro-preview

							input: 8908
							output: 26
							thoughts: 124
						

**Debugging the MCP2221 GPIO Issue**

Okay, so this bug is definitely tied to either `MCP2221_GPIO_SET` or the `mcp->gp_idx` variable. My gut tells me it's probably related to how the GPIO functionality was initially implemented. The first thing I need to do is track down the code commit that introduced those elements into the `mcp2221_raw_event()` function. Let me see...ah, here's a likely candidate: commit `328de1c519c5`, "HID: mcp2221: add GPIO functionality support." That looks about right, given the description. Time to dig into the diff of that commit and see what changed around `mcp2221_raw_event()` and the GPIO setup. Hopefully, the issue reveals itself when I review the code.

map[Commit:328de1c519c5]

map[Output:commit 328de1c519c5c0925151cae47944a1c1a0333bcd
Author: Rishi Gupta <gupt21@gmail.com>
Date:   Tue Apr 14 22:18:14 2020 +0530

    HID: mcp2221: add GPIO functionality support
    
    MCP2221 has 4 pins that can be used as GPIO or configured
    for alternate functionality such as clock generation and
    IRQ detection. This patch adds support for GPIO functionality.
    
    To set direction of a pin or to toggle its state after it
    has been configured as GPIO, driver sends command to mcp2221
    and parses response received from mcp2221. Based on this
    response either 0 or appropriate error code is returned to
    GPIO framework.
    
    To get the direction or current state of a pin, driver
    sends command and read response from the device. Based on
    the response received from device direction or value
    is sent to the GPIO framework.
    
    Command from driver to mcp2221 device are output report.
    Response received from mcp2221 is input report.
    
    Datasheet (page 45-48) contains details about how to decode
    the response received from device:
    http://ww1.microchip.com/downloads/en/DeviceDoc/20005565B.pdf
    
    Signed-off-by: Rishi Gupta <gupt21@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index d958475f8c81..e1b93ce32e01 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -15,6 +15,7 @@
 #include <linux/hid.h>
 #include <linux/hidraw.h>
 #include <linux/i2c.h>
+#include <linux/gpio/driver.h>
 #include "hid-ids.h"
 
 /* Commands codes in a raw output report */
@@ -27,6 +28,8 @@ enum {
 	MCP2221_I2C_PARAM_OR_STATUS	= 0x10,
 	MCP2221_I2C_SET_SPEED = 0x20,
 	MCP2221_I2C_CANCEL = 0x10,
+	MCP2221_GPIO_SET = 0x50,
+	MCP2221_GPIO_GET = 0x51,
 };
 
 /* Response codes in a raw input report */
@@ -42,6 +45,8 @@ enum {
 	MCP2221_I2C_WRADDRL_SEND = 0x21,
 	MCP2221_I2C_ADDR_NACK = 0x25,
 	MCP2221_I2C_READ_COMPL = 0x55,
+	MCP2221_ALT_F_NOT_GPIOV = 0xEE,
+	MCP2221_ALT_F_NOT_GPIOD = 0xEF,
 };
 
 /*
@@ -59,6 +64,9 @@ struct mcp2221 {
 	int rxbuf_idx;
 	int status;
 	u8 cur_i2c_clk_div;
+	struct gpio_chip *gc;
+	u8 gp_idx;
+	u8 gpio_dir;
 };
 
 /*
@@ -526,6 +534,110 @@ static const struct i2c_algorithm mcp_i2c_algo = {
 	.functionality = mcp_i2c_func,
 };
 
+static int mcp_gpio_get(struct gpio_chip *gc,
+				unsigned int offset)
+{
+	int ret;
+	struct mcp2221 *mcp = gpiochip_get_data(gc);
+
+	mcp->txbuf[0] = MCP2221_GPIO_GET;
+
+	mcp->gp_idx = (offset + 1) * 2;
+
+	mutex_lock(&mcp->lock);
+	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
+	mutex_unlock(&mcp->lock);
+
+	return ret;
+}
+
+static void mcp_gpio_set(struct gpio_chip *gc,
+				unsigned int offset, int value)
+{
+	struct mcp2221 *mcp = gpiochip_get_data(gc);
+
+	memset(mcp->txbuf, 0, 18);
+	mcp->txbuf[0] = MCP2221_GPIO_SET;
+
+	mcp->gp_idx = ((offset + 1) * 4) - 1;
+
+	mcp->txbuf[mcp->gp_idx - 1] = 1;
+	mcp->txbuf[mcp->gp_idx] = !!value;
+
+	mutex_lock(&mcp->lock);
+	mcp_send_data_req_status(mcp, mcp->txbuf, 18);
+	mutex_unlock(&mcp->lock);
+}
+
+static int mcp_gpio_dir_set(struct mcp2221 *mcp,
+				unsigned int offset, u8 val)
+{
+	memset(mcp->txbuf, 0, 18);
+	mcp->txbuf[0] = MCP2221_GPIO_SET;
+
+	mcp->gp_idx = (offset + 1) * 5;
+
+	mcp->txbuf[mcp->gp_idx - 1] = 1;
+	mcp->txbuf[mcp->gp_idx] = val;
+
+	return mcp_send_data_req_status(mcp, mcp->txbuf, 18);
+}
+
+static int mcp_gpio_direction_input(struct gpio_chip *gc,
+				unsigned int offset)
+{
+	int ret;
+	struct mcp2221 *mcp = gpiochip_get_data(gc);
+
+	mutex_lock(&mcp->lock);
+	ret = mcp_gpio_dir_set(mcp, offset, 0);
+	mutex_unlock(&mcp->lock);
+
+	return ret;
+}
+
+static int mcp_gpio_direction_output(struct gpio_chip *gc,
+				unsigned int offset, int value)
+{
+	int ret;
+	struct mcp2221 *mcp = gpiochip_get_data(gc);
+
+	mutex_lock(&mcp->lock);
+	ret = mcp_gpio_dir_set(mcp, offset, 1);
+	mutex_unlock(&mcp->lock);
+
+	/* Can't configure as output, bailout early */
+	if (ret)
+		return ret;
+
+	mcp_gpio_set(gc, offset, value);
+
+	return 0;
+}
+
+static int mcp_gpio_get_direction(struct gpio_chip *gc,
+				unsigned int offset)
+{
+	int ret;
+	struct mcp2221 *mcp = gpiochip_get_data(gc);
+
+	mcp->txbuf[0] = MCP2221_GPIO_GET;
+
+	mcp->gp_idx = (offset + 1) * 2;
+
+	mutex_lock(&mcp->lock);
+	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
+	mutex_unlock(&mcp->lock);
+
+	if (ret)
+		return ret;
+
+	if (mcp->gpio_dir)
+		return GPIO_LINE_DIRECTION_IN;
+
+	return GPIO_LINE_DIRECTION_OUT;
+}
+
 /* Gives current state of i2c engine inside mcp2221 */
 static int mcp_get_i2c_eng_state(struct mcp2221 *mcp,
 				u8 *data, u8 idx)
@@ -638,6 +750,39 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 		complete(&mcp->wait_in_report);
 		break;
 
+	case MCP2221_GPIO_GET:
+		switch (data[1]) {
+		case MCP2221_SUCCESS:
+			if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
+				(data[mcp->gp_idx + 1] == MCP2221_ALT_F_NOT_GPIOD)) {
+				mcp->status = -ENOENT;
+			} else {
+				mcp->status = !!data[mcp->gp_idx];
+				mcp->gpio_dir = !!data[mcp->gp_idx + 1];
+			}
+			break;
+		default:
+			mcp->status = -EAGAIN;
+		}
+		complete(&mcp->wait_in_report);
+		break;
+
+	case MCP2221_GPIO_SET:
+		switch (data[1]) {
+		case MCP2221_SUCCESS:
+			if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
+				(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
+				mcp->status = -ENOENT;
+			} else {
+				mcp->status = 0;
+			}
+			break;
+		default:
+			mcp->status = -EAGAIN;
+		}
+		complete(&mcp->wait_in_report);
+		break;
+
 	default:
 		mcp->status = -EIO;
 		complete(&mcp->wait_in_report);
@@ -702,8 +847,32 @@ static int mcp2221_probe(struct hid_device *hdev,
 	}
 	i2c_set_adapdata(&mcp->adapter, mcp);
 
+	/* Setup GPIO chip */
+	mcp->gc = devm_kzalloc(&hdev->dev, sizeof(*mcp->gc), GFP_KERNEL);
+	if (!mcp->gc) {
+		ret = -ENOMEM;
+		goto err_gc;
+	}
+
+	mcp->gc->label = "mcp2221_gpio";
+	mcp->gc->direction_input = mcp_gpio_direction_input;
+	mcp->gc->direction_output = mcp_gpio_direction_output;
+	mcp->gc->get_direction = mcp_gpio_get_direction;
+	mcp->gc->set = mcp_gpio_set;
+	mcp->gc->get = mcp_gpio_get;
+	mcp->gc->ngpio = 4;
+	mcp->gc->base = -1;
+	mcp->gc->can_sleep = 1;
+	mcp->gc->parent = &hdev->dev;
+
+	ret = devm_gpiochip_add_data(&hdev->dev, mcp->gc, mcp);
+	if (ret)
+		goto err_gc;
+
 	return 0;
 
+err_gc:
+	i2c_del_adapter(&mcp->adapter);
 err_i2c:
 	hid_hw_close(mcp->hdev);
 err_hstop:
]

gemini-3.1-pro-preview

							input: 12309
							output: 28
							thoughts: 801
						

**Analyzing the MCP2221 Driver Vulnerability**

Okay, let's break this down. It looks like commit `328de1c519c5c0925151cae47944a1c1a0333bcd` is the culprit. This commit introduced `MCP2221_GPIO_SET` and `MCP2221_GPIO_GET` cases into `mcp2221_raw_event()`, along with `mcp->gp_idx`. I can see it immediately – the code added the problematic `data[mcp->gp_idx - 1]` access within the `MCP2221_GPIO_SET` case. That's a classic out-of-bounds read waiting to happen when `mcp->gp_idx` is zero.

I'm verifying there aren't any other contributing commits. So, it's an out-of-bounds read due to that negative index, and there's a lack of robust input validation in terms of HID report size.

The fix, with its bounds checking for `size` and the check on `data[0] != mcp->txbuf[0]`, should prevent the crash. However, the fix applies to the whole `mcp2221_raw_event()` function, not just the `MCP2221_GPIO_SET` case, while the crash specifically happens within `MCP2221_GPIO_SET`. It's pretty clear that if the `data[0] != mcp->txbuf[0]` check had been in place initially, the problematic processing of `MCP2221_GPIO_SET` wouldn't have even been triggered.

It's clear that the commit `328de1c519c5c0925151cae47944a1c1a0333bcd` introduced the `MCP2221_GPIO_SET` handler and this dangerous `mcp->gp_idx - 1` access. Before that, the `mcp2221_raw_event()` only handled I2C operations.

Now, I'm just curious, was there *any* size validation before this commit? That's the missing piece. I'll need to check the code before that specific commit to see.

map[Commit:328de1c519c5~1]

map[Output:commit c101e9bbce4ae2947b35a660f17d617fc3827595
Merge: 69c1fd97266b 4f8a21a6a933
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Apr 1 15:18:42 2020 -0700

    Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
    
    Pull HID updates from Jiri Kosina:
    
     - Logitech HID++ protocol support improvement from Filipe Laíns
    
     - probe fix for Logitech-G* devices from Hans de Goede
    
     - a few other small code cleanups and support for new device IDs
    
    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
      HID: rmi: Simplify an error handling path in 'rmi_hid_read_block()'
      HID: intel-ish-hid: hbm.h: Replace zero-length array with flexible-array member
      HID: intel-ish-hid: ishtp-dev.h: Replace zero-length array with flexible-array member
      HID: Add driver fixing Glorious PC Gaming Race mouse report descriptor
      HID: lg-g15: Do not fail the probe when we fail to disable F# emulation
      HID: appleir: Use devm_kzalloc() instead of kzalloc()
      HID: appleir: Remove unnecessary goto label
      HID: logitech-dj: add support for the static device in the Powerplay mat/receiver
      HID: mcp2221: add usb to i2c-smbus host bridge
      HID: logitech-dj: add debug msg when exporting a HID++ report descriptors
      HID: quirks: Remove ITE 8595 entry from hid_have_special_driver

]

gemini-3.1-pro-preview

							input: 14141
							output: 27
							thoughts: 51
						

Here's my take on those thoughts:

**Analyzing `mcp2221_raw_event()` in a New HID Driver**

Alright, let's dive into this `mcp2221_raw_event()` function. The commit message indicates this is a new HID driver, which likely means we're dealing with a USB-to-I2C-SMBus host bridge, specifically the MCP2221. That's good, I need to understand this new implementation and how it's handling raw events. I want to see if this raw event handler is well-designed. I'll need to figure out how it takes USB data from the device and translates that into I2C/SMBus transactions. What are the key elements of the event handling in this function? Data parsing, error handling, command sequencing, and importantly, how this function interacts with the higher-level I2C/SMBus drivers. I'll be looking for potential bottlenecks, race conditions, or anything that seems inefficient. It's crucial for the driver to be reliable and not block other operations. Finally I have to see how this function is integrated with the other functions in the driver, it's really the heart of the bridge functionality and it's imperative that the driver is well-structured and performs correctly.

map[Commit:67a95c21463d]

map[Output:commit 67a95c21463d066060b0f66d65a75d45bb386ffb
Author: Rishi Gupta <gupt21@gmail.com>
Date:   Tue Jan 28 09:48:57 2020 +0530

    HID: mcp2221: add usb to i2c-smbus host bridge
    
    MCP2221 is a USB HID to I2C/SMbus host bridge device. This
    commit implements i2c and smbus host adapter support. 7-bit
    address and i2c multi-message transaction is also supported.
    
    Signed-off-by: Rishi Gupta <gupt21@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

diff --git a/MAINTAINERS b/MAINTAINERS
index 8f27f40d22bb..352a67fe7598 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10236,6 +10236,13 @@ F:	drivers/net/can/m_can/m_can.c
 F:	drivers/net/can/m_can/m_can.h
 F:	drivers/net/can/m_can/m_can_platform.c
 
+MCP2221A MICROCHIP USB-HID TO I2C BRIDGE DRIVER
+M:	Rishi Gupta <gupt21@gmail.com>
+L:	linux-i2c@vger.kernel.org
+L:	linux-input@vger.kernel.org
+S:	Maintained
+F:	drivers/hid/hid-mcp2221.c
+
 MCP4018 AND MCP4531 MICROCHIP DIGITAL POTENTIOMETER DRIVERS
 M:	Peter Rosin <peda@axentia.se>
 L:	linux-iio@vger.kernel.org
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 494a39e74939..5db6e6a709e0 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1145,6 +1145,16 @@ config HID_ALPS
 	Say Y here if you have a Alps touchpads over i2c-hid or usbhid
 	and want support for its special functionalities.
 
+config HID_MCP2221
+	tristate "Microchip MCP2221 HID USB-to-I2C/SMbus host support"
+	depends on USB_HID && I2C
+	---help---
+	Provides I2C and SMBUS host adapter functionality over USB-HID
+	through MCP2221 device.
+
+	To compile this driver as a module, choose M here: the module
+	will be called hid-mcp2221.ko.
+
 endmenu
 
 endif # HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index bfefa365b1ce..21052a78a344 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_HID_LOGITECH_HIDPP)	+= hid-logitech-hidpp.o
 obj-$(CONFIG_HID_MACALLY)	+= hid-macally.o
 obj-$(CONFIG_HID_MAGICMOUSE)	+= hid-magicmouse.o
 obj-$(CONFIG_HID_MALTRON)	+= hid-maltron.o
+obj-$(CONFIG_HID_MCP2221)	+= hid-mcp2221.o
 obj-$(CONFIG_HID_MAYFLASH)	+= hid-mf.o
 obj-$(CONFIG_HID_MICROSOFT)	+= hid-microsoft.o
 obj-$(CONFIG_HID_MONTEREY)	+= hid-monterey.o
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 3a400ce603c4..53236ac34fcb 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -819,6 +819,7 @@
 #define USB_DEVICE_ID_PICK16F1454	0x0042
 #define USB_DEVICE_ID_PICK16F1454_V2	0xf2f7
 #define USB_DEVICE_ID_LUXAFOR		0xf372
+#define USB_DEVICE_ID_MCP2221		0x00dd
 
 #define USB_VENDOR_ID_MICROSOFT		0x045e
 #define USB_DEVICE_ID_SIDEWINDER_GV	0x003b
diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
new file mode 100644
index 000000000000..d958475f8c81
--- /dev/null
+++ b/drivers/hid/hid-mcp2221.c
@@ -0,0 +1,742 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * MCP2221A - Microchip USB to I2C Host Protocol Bridge
+ *
+ * Copyright (c) 2020, Rishi Gupta <gupt21@gmail.com>
+ *
+ * Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20005565B.pdf
+ */
+
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/mutex.h>
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/hid.h>
+#include <linux/hidraw.h>
+#include <linux/i2c.h>
+#include "hid-ids.h"
+
+/* Commands codes in a raw output report */
+enum {
+	MCP2221_I2C_WR_DATA = 0x90,
+	MCP2221_I2C_WR_NO_STOP = 0x94,
+	MCP2221_I2C_RD_DATA = 0x91,
+	MCP2221_I2C_RD_RPT_START = 0x93,
+	MCP2221_I2C_GET_DATA = 0x40,
+	MCP2221_I2C_PARAM_OR_STATUS	= 0x10,
+	MCP2221_I2C_SET_SPEED = 0x20,
+	MCP2221_I2C_CANCEL = 0x10,
+};
+
+/* Response codes in a raw input report */
+enum {
+	MCP2221_SUCCESS = 0x00,
+	MCP2221_I2C_ENG_BUSY = 0x01,
+	MCP2221_I2C_START_TOUT = 0x12,
+	MCP2221_I2C_STOP_TOUT = 0x62,
+	MCP2221_I2C_WRADDRL_TOUT = 0x23,
+	MCP2221_I2C_WRDATA_TOUT = 0x44,
+	MCP2221_I2C_WRADDRL_NACK = 0x25,
+	MCP2221_I2C_MASK_ADDR_NACK = 0x40,
+	MCP2221_I2C_WRADDRL_SEND = 0x21,
+	MCP2221_I2C_ADDR_NACK = 0x25,
+	MCP2221_I2C_READ_COMPL = 0x55,
+};
+
+/*
+ * There is no way to distinguish responses. Therefore next command
+ * is sent only after response to previous has been received. Mutex
+ * lock is used for this purpose mainly.
+ */
+struct mcp2221 {
+	struct hid_device *hdev;
+	struct i2c_adapter adapter;
+	struct mutex lock;
+	struct completion wait_in_report;
+	u8 *rxbuf;
+	u8 txbuf[64];
+	int rxbuf_idx;
+	int status;
+	u8 cur_i2c_clk_div;
+};
+
+/*
+ * Default i2c bus clock frequency 400 kHz. Modify this if you
+ * want to set some other frequency (min 50 kHz - max 400 kHz).
+ */
+static uint i2c_clk_freq = 400;
+
+/* Synchronously send output report to the device */
+static int mcp_send_report(struct mcp2221 *mcp,
+					u8 *out_report, size_t len)
+{
+	u8 *buf;
+	int ret;
+
+	buf = kmemdup(out_report, len, GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
+	/* mcp2221 uses interrupt endpoint for out reports */
+	ret = hid_hw_output_report(mcp->hdev, buf, len);
+	kfree(buf);
+
+	if (ret < 0)
+		return ret;
+	return 0;
+}
+
+/*
+ * Send o/p report to the device and wait for i/p report to be
+ * received from the device. If the device does not respond,
+ * we timeout.
+ */
+static int mcp_send_data_req_status(struct mcp2221 *mcp,
+			u8 *out_report, int len)
+{
+	int ret;
+	unsigned long t;
+
+	reinit_completion(&mcp->wait_in_report);
+
+	ret = mcp_send_report(mcp, out_report, len);
+	if (ret)
+		return ret;
+
+	t = wait_for_completion_timeout(&mcp->wait_in_report,
+							msecs_to_jiffies(4000));
+	if (!t)
+		return -ETIMEDOUT;
+
+	return mcp->status;
+}
+
+/* Check pass/fail for actual communication with i2c slave */
+static int mcp_chk_last_cmd_status(struct mcp2221 *mcp)
+{
+	memset(mcp->txbuf, 0, 8);
+	mcp->txbuf[0] = MCP2221_I2C_PARAM_OR_STATUS;
+
+	return mcp_send_data_req_status(mcp, mcp->txbuf, 8);
+}
+
+/* Cancels last command releasing i2c bus just in case occupied */
+static int mcp_cancel_last_cmd(struct mcp2221 *mcp)
+{
+	memset(mcp->txbuf, 0, 8);
+	mcp->txbuf[0] = MCP2221_I2C_PARAM_OR_STATUS;
+	mcp->txbuf[2] = MCP2221_I2C_CANCEL;
+
+	return mcp_send_data_req_status(mcp, mcp->txbuf, 8);
+}
+
+static int mcp_set_i2c_speed(struct mcp2221 *mcp)
+{
+	int ret;
+
+	memset(mcp->txbuf, 0, 8);
+	mcp->txbuf[0] = MCP2221_I2C_PARAM_OR_STATUS;
+	mcp->txbuf[3] = MCP2221_I2C_SET_SPEED;
+	mcp->txbuf[4] = mcp->cur_i2c_clk_div;
+
+	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 8);
+	if (ret) {
+		/* Small delay is needed here */
+		usleep_range(980, 1000);
+		mcp_cancel_last_cmd(mcp);
+	}
+
+	return 0;
+}
+
+/*
+ * An output report can contain minimum 1 and maximum 60 user data
+ * bytes. If the number of data bytes is more then 60, we send it
+ * in chunks of 60 bytes. Last chunk may contain exactly 60 or less
+ * bytes. Total number of bytes is informed in very first report to
+ * mcp2221, from that point onwards it first collect all the data
+ * from host and then send to i2c slave device.
+ */
+static int mcp_i2c_write(struct mcp2221 *mcp,
+				struct i2c_msg *msg, int type, u8 last_status)
+{
+	int ret, len, idx, sent;
+
+	idx = 0;
+	sent  = 0;
+	if (msg->len < 60)
+		len = msg->len;
+	else
+		len = 60;
+
+	do {
+		mcp->txbuf[0] = type;
+		mcp->txbuf[1] = msg->len & 0xff;
+		mcp->txbuf[2] = msg->len >> 8;
+		mcp->txbuf[3] = (u8)(msg->addr << 1);
+
+		memcpy(&mcp->txbuf[4], &msg->buf[idx], len);
+
+		ret = mcp_send_data_req_status(mcp, mcp->txbuf, len + 4);
+		if (ret)
+			return ret;
+
+		usleep_range(980, 1000);
+
+		if (last_status) {
+			ret = mcp_chk_last_cmd_status(mcp);
+			if (ret)
+				return ret;
+		}
+
+		sent = sent + len;
+		if (sent >= msg->len)
+			break;
+
+		idx = idx + len;
+		if ((msg->len - sent) < 60)
+			len = msg->len - sent;
+		else
+			len = 60;
+
+		/*
+		 * Testing shows delay is needed between successive writes
+		 * otherwise next write fails on first-try from i2c core.
+		 * This value is obtained through automated stress testing.
+		 */
+		usleep_range(980, 1000);
+	} while (len > 0);
+
+	return ret;
+}
+
+/*
+ * Device reads all data (0 - 65535 bytes) from i2c slave device and
+ * stores it in device itself. This data is read back from device to
+ * host in multiples of 60 bytes using input reports.
+ */
+static int mcp_i2c_smbus_read(struct mcp2221 *mcp,
+				struct i2c_msg *msg, int type, u16 smbus_addr,
+				u8 smbus_len, u8 *smbus_buf)
+{
+	int ret;
+	u16 total_len;
+
+	mcp->txbuf[0] = type;
+	if (msg) {
+		mcp->txbuf[1] = msg->len & 0xff;
+		mcp->txbuf[2] = msg->len >> 8;
+		mcp->txbuf[3] = (u8)(msg->addr << 1);
+		total_len = msg->len;
+		mcp->rxbuf = msg->buf;
+	} else {
+		mcp->txbuf[1] = smbus_len;
+		mcp->txbuf[2] = 0;
+		mcp->txbuf[3] = (u8)(smbus_addr << 1);
+		total_len = smbus_len;
+		mcp->rxbuf = smbus_buf;
+	}
+
+	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 4);
+	if (ret)
+		return ret;
+
+	mcp->rxbuf_idx = 0;
+
+	do {
+		memset(mcp->txbuf, 0, 4);
+		mcp->txbuf[0] = MCP2221_I2C_GET_DATA;
+
+		ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
+		if (ret)
+			return ret;
+
+		ret = mcp_chk_last_cmd_status(mcp);
+		if (ret)
+			return ret;
+
+		usleep_range(980, 1000);
+	} while (mcp->rxbuf_idx < total_len);
+
+	return ret;
+}
+
+static int mcp_i2c_xfer(struct i2c_adapter *adapter,
+				struct i2c_msg msgs[], int num)
+{
+	int ret;
+	struct mcp2221 *mcp = i2c_get_adapdata(adapter);
+
+	hid_hw_power(mcp->hdev, PM_HINT_FULLON);
+
+	mutex_lock(&mcp->lock);
+
+	/* Setting speed before every transaction is required for mcp2221 */
+	ret = mcp_set_i2c_speed(mcp);
+	if (ret)
+		goto exit;
+
+	if (num == 1) {
+		if (msgs->flags & I2C_M_RD) {
+			ret = mcp_i2c_smbus_read(mcp, msgs, MCP2221_I2C_RD_DATA,
+							0, 0, NULL);
+		} else {
+			ret = mcp_i2c_write(mcp, msgs, MCP2221_I2C_WR_DATA, 1);
+		}
+		if (ret)
+			goto exit;
+		ret = num;
+	} else if (num == 2) {
+		/* Ex transaction; send reg address and read its contents */
+		if (msgs[0].addr == msgs[1].addr &&
+			!(msgs[0].flags & I2C_M_RD) &&
+			 (msgs[1].flags & I2C_M_RD)) {
+
+			ret = mcp_i2c_write(mcp, &msgs[0],
+						MCP2221_I2C_WR_NO_STOP, 0);
+			if (ret)
+				goto exit;
+
+			ret = mcp_i2c_smbus_read(mcp, &msgs[1],
+						MCP2221_I2C_RD_RPT_START,
+						0, 0, NULL);
+			if (ret)
+				goto exit;
+			ret = num;
+		} else {
+			dev_err(&adapter->dev,
+				"unsupported multi-msg i2c transaction\n");
+			ret = -EOPNOTSUPP;
+		}
+	} else {
+		dev_err(&adapter->dev,
+			"unsupported multi-msg i2c transaction\n");
+		ret = -EOPNOTSUPP;
+	}
+
+exit:
+	hid_hw_power(mcp->hdev, PM_HINT_NORMAL);
+	mutex_unlock(&mcp->lock);
+	return ret;
+}
+
+static int mcp_smbus_write(struct mcp2221 *mcp, u16 addr,
+				u8 command, u8 *buf, u8 len, int type,
+				u8 last_status)
+{
+	int data_len, ret;
+
+	mcp->txbuf[0] = type;
+	mcp->txbuf[1] = len + 1; /* 1 is due to command byte itself */
+	mcp->txbuf[2] = 0;
+	mcp->txbuf[3] = (u8)(addr << 1);
+	mcp->txbuf[4] = command;
+
+	switch (len) {
+	case 0:
+		data_len = 5;
+		break;
+	case 1:
+		mcp->txbuf[5] = buf[0];
+		data_len = 6;
+		break;
+	case 2:
+		mcp->txbuf[5] = buf[0];
+		mcp->txbuf[6] = buf[1];
+		data_len = 7;
+		break;
+	default:
+		memcpy(&mcp->txbuf[5], buf, len);
+		data_len = len + 5;
+	}
+
+	ret = mcp_send_data_req_status(mcp, mcp->txbuf, data_len);
+	if (ret)
+		return ret;
+
+	if (last_status) {
+		usleep_range(980, 1000);
+
+		ret = mcp_chk_last_cmd_status(mcp);
+		if (ret)
+			return ret;
+	}
+
+	return ret;
+}
+
+static int mcp_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
+				unsigned short flags, char read_write,
+				u8 command, int size,
+				union i2c_smbus_data *data)
+{
+	int ret;
+	struct mcp2221 *mcp = i2c_get_adapdata(adapter);
+
+	hid_hw_power(mcp->hdev, PM_HINT_FULLON);
+
+	mutex_lock(&mcp->lock);
+
+	ret = mcp_set_i2c_speed(mcp);
+	if (ret)
+		goto exit;
+
+	switch (size) {
+
+	case I2C_SMBUS_QUICK:
+		if (read_write == I2C_SMBUS_READ)
+			ret = mcp_i2c_smbus_read(mcp, NULL, MCP2221_I2C_RD_DATA,
+						addr, 0, &data->byte);
+		else
+			ret = mcp_smbus_write(mcp, addr, command, NULL,
+						0, MCP2221_I2C_WR_DATA, 1);
+		break;
+	case I2C_SMBUS_BYTE:
+		if (read_write == I2C_SMBUS_READ)
+			ret = mcp_i2c_smbus_read(mcp, NULL, MCP2221_I2C_RD_DATA,
+						addr, 1, &data->byte);
+		else
+			ret = mcp_smbus_write(mcp, addr, command, NULL,
+						0, MCP2221_I2C_WR_DATA, 1);
+		break;
+	case I2C_SMBUS_BYTE_DATA:
+		if (read_write == I2C_SMBUS_READ) {
+			ret = mcp_smbus_write(mcp, addr, command, NULL,
+						0, MCP2221_I2C_WR_NO_STOP, 0);
+			if (ret)
+				goto exit;
+
+			ret = mcp_i2c_smbus_read(mcp, NULL,
+						MCP2221_I2C_RD_RPT_START,
+						addr, 1, &data->byte);
+		} else {
+			ret = mcp_smbus_write(mcp, addr, command, &data->byte,
+						1, MCP2221_I2C_WR_DATA, 1);
+		}
+		break;
+	case I2C_SMBUS_WORD_DATA:
+		if (read_write == I2C_SMBUS_READ) {
+			ret = mcp_smbus_write(mcp, addr, command, NULL,
+						0, MCP2221_I2C_WR_NO_STOP, 0);
+			if (ret)
+				goto exit;
+
+			ret = mcp_i2c_smbus_read(mcp, NULL,
+						MCP2221_I2C_RD_RPT_START,
+						addr, 2, (u8 *)&data->word);
+		} else {
+			ret = mcp_smbus_write(mcp, addr, command,
+						(u8 *)&data->word, 2,
+						MCP2221_I2C_WR_DATA, 1);
+		}
+		break;
+	case I2C_SMBUS_BLOCK_DATA:
+		if (read_write == I2C_SMBUS_READ) {
+			ret = mcp_smbus_write(mcp, addr, command, NULL,
+						0, MCP2221_I2C_WR_NO_STOP, 1);
+			if (ret)
+				goto exit;
+
+			mcp->rxbuf_idx = 0;
+			mcp->rxbuf = data->block;
+			mcp->txbuf[0] = MCP2221_I2C_GET_DATA;
+			ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
+			if (ret)
+				goto exit;
+		} else {
+			if (!data->block[0]) {
+				ret = -EINVAL;
+				goto exit;
+			}
+			ret = mcp_smbus_write(mcp, addr, command, data->block,
+						data->block[0] + 1,
+						MCP2221_I2C_WR_DATA, 1);
+		}
+		break;
+	case I2C_SMBUS_I2C_BLOCK_DATA:
+		if (read_write == I2C_SMBUS_READ) {
+			ret = mcp_smbus_write(mcp, addr, command, NULL,
+						0, MCP2221_I2C_WR_NO_STOP, 1);
+			if (ret)
+				goto exit;
+
+			mcp->rxbuf_idx = 0;
+			mcp->rxbuf = data->block;
+			mcp->txbuf[0] = MCP2221_I2C_GET_DATA;
+			ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
+			if (ret)
+				goto exit;
+		} else {
+			if (!data->block[0]) {
+				ret = -EINVAL;
+				goto exit;
+			}
+			ret = mcp_smbus_write(mcp, addr, command,
+						&data->block[1], data->block[0],
+						MCP2221_I2C_WR_DATA, 1);
+		}
+		break;
+	case I2C_SMBUS_PROC_CALL:
+		ret = mcp_smbus_write(mcp, addr, command,
+						(u8 *)&data->word,
+						2, MCP2221_I2C_WR_NO_STOP, 0);
+		if (ret)
+			goto exit;
+
+		ret = mcp_i2c_smbus_read(mcp, NULL,
+						MCP2221_I2C_RD_RPT_START,
+						addr, 2, (u8 *)&data->word);
+		break;
+	case I2C_SMBUS_BLOCK_PROC_CALL:
+		ret = mcp_smbus_write(mcp, addr, command, data->block,
+						data->block[0] + 1,
+						MCP2221_I2C_WR_NO_STOP, 0);
+		if (ret)
+			goto exit;
+
+		ret = mcp_i2c_smbus_read(mcp, NULL,
+						MCP2221_I2C_RD_RPT_START,
+						addr, I2C_SMBUS_BLOCK_MAX,
+						data->block);
+		break;
+	default:
+		dev_err(&mcp->adapter.dev,
+			"unsupported smbus transaction size:%d\n", size);
+		ret = -EOPNOTSUPP;
+	}
+
+exit:
+	hid_hw_power(mcp->hdev, PM_HINT_NORMAL);
+	mutex_unlock(&mcp->lock);
+	return ret;
+}
+
+static u32 mcp_i2c_func(struct i2c_adapter *adapter)
+{
+	return I2C_FUNC_I2C |
+			I2C_FUNC_SMBUS_READ_BLOCK_DATA |
+			I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
+			(I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_PEC);
+}
+
+static const struct i2c_algorithm mcp_i2c_algo = {
+	.master_xfer = mcp_i2c_xfer,
+	.smbus_xfer = mcp_smbus_xfer,
+	.functionality = mcp_i2c_func,
+};
+
+/* Gives current state of i2c engine inside mcp2221 */
+static int mcp_get_i2c_eng_state(struct mcp2221 *mcp,
+				u8 *data, u8 idx)
+{
+	int ret;
+
+	switch (data[idx]) {
+	case MCP2221_I2C_WRADDRL_NACK:
+	case MCP2221_I2C_WRADDRL_SEND:
+		ret = -ENXIO;
+		break;
+	case MCP2221_I2C_START_TOUT:
+	case MCP2221_I2C_STOP_TOUT:
+	case MCP2221_I2C_WRADDRL_TOUT:
+	case MCP2221_I2C_WRDATA_TOUT:
+		ret = -ETIMEDOUT;
+		break;
+	case MCP2221_I2C_ENG_BUSY:
+		ret = -EAGAIN;
+		break;
+	case MCP2221_SUCCESS:
+		ret = 0x00;
+		break;
+	default:
+		ret = -EIO;
+	}
+
+	return ret;
+}
+
+/*
+ * MCP2221 uses interrupt endpoint for input reports. This function
+ * is called by HID layer when it receives i/p report from mcp2221,
+ * which is actually a response to the previously sent command.
+ *
+ * MCP2221A firmware specific return codes are parsed and 0 or
+ * appropriate negative error code is returned. Delayed response
+ * results in timeout error and stray reponses results in -EIO.
+ */
+static int mcp2221_raw_event(struct hid_device *hdev,
+				struct hid_report *report, u8 *data, int size)
+{
+	u8 *buf;
+	struct mcp2221 *mcp = hid_get_drvdata(hdev);
+
+	switch (data[0]) {
+
+	case MCP2221_I2C_WR_DATA:
+	case MCP2221_I2C_WR_NO_STOP:
+	case MCP2221_I2C_RD_DATA:
+	case MCP2221_I2C_RD_RPT_START:
+		switch (data[1]) {
+		case MCP2221_SUCCESS:
+			mcp->status = 0;
+			break;
+		default:
+			mcp->status = mcp_get_i2c_eng_state(mcp, data, 2);
+		}
+		complete(&mcp->wait_in_report);
+		break;
+
+	case MCP2221_I2C_PARAM_OR_STATUS:
+		switch (data[1]) {
+		case MCP2221_SUCCESS:
+			if ((mcp->txbuf[3] == MCP2221_I2C_SET_SPEED) &&
+				(data[3] != MCP2221_I2C_SET_SPEED)) {
+				mcp->status = -EAGAIN;
+				break;
+			}
+			if (data[20] & MCP2221_I2C_MASK_ADDR_NACK) {
+				mcp->status = -ENXIO;
+				break;
+			}
+			mcp->status = mcp_get_i2c_eng_state(mcp, data, 8);
+			break;
+		default:
+			mcp->status = -EIO;
+		}
+		complete(&mcp->wait_in_report);
+		break;
+
+	case MCP2221_I2C_GET_DATA:
+		switch (data[1]) {
+		case MCP2221_SUCCESS:
+			if (data[2] == MCP2221_I2C_ADDR_NACK) {
+				mcp->status = -ENXIO;
+				break;
+			}
+			if (!mcp_get_i2c_eng_state(mcp, data, 2)
+				&& (data[3] == 0)) {
+				mcp->status = 0;
+				break;
+			}
+			if (data[3] == 127) {
+				mcp->status = -EIO;
+				break;
+			}
+			if (data[2] == MCP2221_I2C_READ_COMPL) {
+				buf = mcp->rxbuf;
+				memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
+				mcp->rxbuf_idx = mcp->rxbuf_idx + data[3];
+				mcp->status = 0;
+				break;
+			}
+			mcp->status = -EIO;
+			break;
+		default:
+			mcp->status = -EIO;
+		}
+		complete(&mcp->wait_in_report);
+		break;
+
+	default:
+		mcp->status = -EIO;
+		complete(&mcp->wait_in_report);
+	}
+
+	return 1;
+}
+
+static int mcp2221_probe(struct hid_device *hdev,
+					const struct hid_device_id *id)
+{
+	int ret;
+	struct mcp2221 *mcp;
+
+	mcp = devm_kzalloc(&hdev->dev, sizeof(*mcp), GFP_KERNEL);
+	if (!mcp)
+		return -ENOMEM;
+
+	ret = hid_parse(hdev);
+	if (ret) {
+		hid_err(hdev, "can't parse reports\n");
+		return ret;
+	}
+
+	ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
+	if (ret) {
+		hid_err(hdev, "can't start hardware\n");
+		return ret;
+	}
+
+	ret = hid_hw_open(hdev);
+	if (ret) {
+		hid_err(hdev, "can't open device\n");
+		goto err_hstop;
+	}
+
+	mutex_init(&mcp->lock);
+	init_completion(&mcp->wait_in_report);
+	hid_set_drvdata(hdev, mcp);
+	mcp->hdev = hdev;
+
+	/* Set I2C bus clock diviser */
+	if (i2c_clk_freq > 400)
+		i2c_clk_freq = 400;
+	if (i2c_clk_freq < 50)
+		i2c_clk_freq = 50;
+	mcp->cur_i2c_clk_div = (12000000 / (i2c_clk_freq * 1000)) - 3;
+
+	mcp->adapter.owner = THIS_MODULE;
+	mcp->adapter.class = I2C_CLASS_HWMON;
+	mcp->adapter.algo = &mcp_i2c_algo;
+	mcp->adapter.retries = 1;
+	mcp->adapter.dev.parent = &hdev->dev;
+	snprintf(mcp->adapter.name, sizeof(mcp->adapter.name),
+			"MCP2221 usb-i2c bridge on hidraw%d",
+			((struct hidraw *)hdev->hidraw)->minor);
+
+	ret = i2c_add_adapter(&mcp->adapter);
+	if (ret) {
+		hid_err(hdev, "can't add usb-i2c adapter: %d\n", ret);
+		goto err_i2c;
+	}
+	i2c_set_adapdata(&mcp->adapter, mcp);
+
+	return 0;
+
+err_i2c:
+	hid_hw_close(mcp->hdev);
+err_hstop:
+	hid_hw_stop(mcp->hdev);
+	return ret;
+}
+
+static void mcp2221_remove(struct hid_device *hdev)
+{
+	struct mcp2221 *mcp = hid_get_drvdata(hdev);
+
+	i2c_del_adapter(&mcp->adapter);
+	hid_hw_close(mcp->hdev);
+	hid_hw_stop(mcp->hdev);
+}
+
+static const struct hid_device_id mcp2221_devices[] = {
+	{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_MCP2221) },
+	{ }
+};
+MODULE_DEVICE_TABLE(hid, mcp2221_devices);
+
+static struct hid_driver mcp2221_driver = {
+	.name		= "mcp2221",
+	.id_table	= mcp2221_devices,
+	.probe		= mcp2221_probe,
+	.remove		= mcp2221_remove,
+	.raw_event	= mcp2221_raw_event,
+};
+
+/* Register with HID core */
+module_hid_driver(mcp2221_driver);
+
+MODULE_AUTHOR("Rishi Gupta <gupt21@gmail.com>");
+MODULE_DESCRIPTION("MCP2221 Microchip HID USB to I2C master bridge");
+MODULE_LICENSE("GPL v2");
]

gemini-3.1-pro-preview

							input: 24550
							output: 51
							thoughts: 1145
						

**Analyzing the MCP2221 Driver Vulnerability**

Okay, let's break this down methodically. The starting point is the crash report: a slab-out-of-bounds read within the `mcp2221_raw_event()` function. The core of the problem lies in an out-of-bounds access, specifically `data[-1]`, due to an integer underflow when `mcp->gp_idx` is zero. The explanation is clear: a `MCP2221_GPIO_SET` input report arrives *before* any GPIO operations are configured, leading to an incorrect state.

I see that the lack of proper size checking in `mcp2221_raw_event()` was introduced in commit `67a95c21463d066060b0f66d65a75d45bb386ffb`, the initial driver commit. My attention is drawn to the fact that the code blatantly accesses various `data[]` indices without any validation. I note that this commit also doesn't validate against `data[0] != mcp->txbuf[0]`.

But here's the crucial detail: The crash occurs because of the negative array index, meaning `data[-1]`. This specific error in logic, and the introduction of the GPIO functionality, including the offending line `data[mcp->gp_idx - 1]`, was introduced in commit `328de1c519c5c0925151cae47944a1c1a0333bcd`. This is the bug-introducing commit.

The fix patch addresses this by adding a size check (ensuring `size >= 64`) and checking that the first byte of the data matches what's expected (`data[0] != mcp->txbuf[0]`). This effectively mitigates the negative array index issue and prevents the vulnerability from being triggered in this scenario.

While the missing size check in `67a95c21463d066060b0f66d65a75d45bb386ffb` introduced a broader potential for out-of-bounds reads, the specific crash in question is directly caused by the logic introduced in `328de1c519c5c0925151cae47944a1c1a0333bcd`. If this commit hadn't existed, the reported crash wouldn't have materialized, even though the driver would remain vulnerable to other out-of-bounds scenarios due to the missing size check in the initial commit. Therefore, I'm confident that the root cause of the described crash is indeed found in `328de1c519c5c0925151cae47944a1c1a0333bcd`. Now, let's double-check other modifications to this part of the code, just to be thorough.

git log timed out. Please specify a tighter search scope (e.g. by providing a PathPrefix).

map[CodeRegexp:MCP2221_GPIO_SET Count:10 SourcePath:drivers/hid/hid-mcp2221.c]

map[Output:]

gemini-3.1-pro-preview

							input: 26443
							output: 51
							thoughts: 9
						

Okay, here's the summary, formatted as requested:

**Navigating the Router Configuration**

Alright, let's see... looking at this configuration, it's immediately apparent that I need to ensure proper routing. I should definitely be setting a `PathPrefix`. Without it, I'm just asking for trouble and potentially exposing internal services unintentionally. It would be a silly oversight, given the complexity I am working with. I should have it as an imperative to make it functional.

map[CodeRegexp:MCP2221_GPIO_SET Count:10 PathPrefix:drivers/hid/hid-mcp2221.c]

map[Output:328de1c519c5 HID: mcp2221: add GPIO functionality support
]

gemini-3.1-pro-preview

							input: 26642
							output: 56
							thoughts: 2713
						

**Analysis of the MCP2221 Driver Vulnerability and Fix**

Okay, so I'm diving into this MCP2221 driver issue. My initial thought is that `328de1c519c5` is the specific commit where `MCP2221_GPIO_SET` was introduced, which is a key piece of information. The crucial check in the fix is `data[0] != mcp->txbuf[0]`. This addition seems to be about verifying that the report type received matches what was *expected*. This effectively blocks the trigger that caused the `data[-1]` out-of-bounds access. The second check, `size < 64`, handles the scenario where the incoming report is too short and prevents an out-of-bounds read.

The primary bug seems to revolve around the `data[-1]` access – the root cause of the crash, directly resulting from `328de1c519c5c0925151cae47944a1c1a0333bcd`. But the concern is, even before this specific commit, the driver might be vulnerable to other unsolicited reports.

Now, which commit actually introduced the bug? Is it `328de1c519c5c0925151cae47944a1c1a0333bcd` that led to the crash, or `67a95c21463d066060b0f66d65a75d45bb386ffb` with its lack of size checks?

Let's dissect the crash report: "KASAN: slab-out-of-bounds in mcp2221_raw_event...Read of size 1 at addr...`. This clearly points to the `data[-1]` access. The explanation makes it clear: it's an out-of-bounds *read* due to a negative array index because of `mcp->gp_idx` being 0, which happens if there's no bounds checking on report size.

The fix itself:
```c
+	if (unlikely(size < 64))
+		return 1;
+
+	if (data[0] != mcp->txbuf[0])
+		return 1;
```
This is a comprehensive fix addressing both the `size` issue, and the unsolicited report issue. The unsolicited reports is the factor that results in `mcp->gp_idx` being 0 when `MCP2221_GPIO_SET` is processed.

If `data[0] != mcp->txbuf[0]` had been present earlier, the unsolicited `MCP2221_GPIO_SET` would have been discarded. Because `MCP2221_GPIO_SET` was only introduced in `328de1c519c5c0925151cae47944a1c1a0333bcd`, the bug is present there. Usually, it's the commit that adds the code that causes the crash that is considered the bug-introducing commit.

However, if there was no check for `data[0] != mcp->txbuf[0]`, the driver was indeed vulnerable to unsolicited reports prior to `328de1c519c5c0925151cae47944a1c1a0333bcd`. So, I'll need to check if there are other out-of-bounds accesses before the introducing commit.

Let's consider `67a95c21463d066060b0f66d65a75d45bb386ffb`. Here, `data[20]` is accessed. If `size` is less than 21, it’s an out-of-bounds read. This means the lack of size checking was already a latent bug. The `data[-1]` access due to `mcp->gp_idx - 1` when `mcp->gp_idx` is zero is a *logic* error introduced with `328de1c519c5c0925151cae47944a1c1a0333bcd`.

So if I must pick one, the fix addresses both issues: `size < 64` and `data[0] != mcp->txbuf[0]`. The `data[0] != mcp->txbuf[0]` check prevents the `data[-1]` crash because

map[CodeRegexp:if \\(unlikely\\(size < 64\\)\\) Count:1 PathPrefix:drivers/hid/hid-mcp2221.c]

map[Output:]

gemini-3.1-pro-preview

							input: 30449
							output: 35
							thoughts: 49
						

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

**Troubleshooting a Potential HID Driver Integration**

Right, so the expected functionality isn't working as I'd anticipated. My immediate thought is, "Okay, the patch hasn't landed in the main branch yet, or perhaps my regex for the relevant commit message wasn't quite right." I need to verify. Let's start with a quick search, focusing on the commit messages related to the `hid-mcp2221.c` driver, perhaps using specific keywords or hashes if I have them handy. Failing that, I'll bypass the search and just quickly examine the most recent commits directly within the `drivers/hid/hid-mcp2221.c` file itself. That should give me a good handle on what's been happening in the area and whether my expectation aligns with the current state of the code base.

map[Count:10 PathPrefix:drivers/hid/hid-mcp2221.c]

map[Output:f097d246677b HID: mcp2221: fix OOB write in mcp2221_raw_event()
ac977b900907 HID: mcp2221: Fix spelling mistake "Enfore" -> "Enforce"
200e6c6e94fa HID: mcp2221: Add module parameter to enfoce GPIO mode
ab05515757fc HID: mcp2221: use mcp_i2c_smbus_read for block reads
e31b556c0ba2 HID: mcp2221: cancel last I2C command on read error
b56cc41a3ae7 hid: fix I2C read buffer overflow in raw_event() for mcp2221
d9d87d90cc0b treewide: rename GPIO set callbacks back to their original names
a5db1591d082 HID: mcp-2221: Replace manual comparison with min() macro
0d6b550dce55 HID: mcp2221: set gpio pin mode
31a78afda1ef HID: mcp2221: use new line value setter callbacks
]

gemini-3.1-pro-preview

							input: 31044
							output: 27
							thoughts: 32
						

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

**Debugging: Identifying the Fix Commit**

Alright, time to get to the bottom of this. My initial thought is to quickly verify the status of the suspected fix. I need to know definitively if the resolution for this issue is contained within commit `f097d246677b`. That's the baseline, the critical first step. Is it already integrated into the mainline, or is it still sitting on a branch, perhaps awaiting review or further testing? Determining its merge status is paramount for understanding where the problem currently resides within the overall code base. Knowing this will immediately inform the next steps in my analysis. It's the most efficient starting point.

map[Commit:f097d246677b]

map[Output:commit f097d246677b03db814c5862f368cea341b76a00
Author: Florian Pradines <florian.pradines@gmail.com>
Date:   Sat May 9 09:45:17 2026 +0000

    HID: mcp2221: fix OOB write in mcp2221_raw_event()
    
    mcp2221_raw_event() copies device-supplied data into mcp->rxbuf at
    offset rxbuf_idx without checking that the copy fits within the
    destination buffer. A device responding with up to 60 bytes to a
    small I2C/SMBus read can overflow the buffer.
    
    Add a rxbuf_size field to struct mcp2221, set it alongside rxbuf in
    mcp_i2c_smbus_read(), and check rxbuf_idx + data[3] <= rxbuf_size
    before the memcpy.
    
    Reported-by: Benoît Sevens <bsevens@google.com>
    Signed-off-by: Florian Pradines <florian.pradines@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index be80970ab48e..e4ddd8e9293b 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -128,6 +128,7 @@ struct mcp2221 {
 	u8 *rxbuf;
 	u8 txbuf[64];
 	int rxbuf_idx;
+	int rxbuf_size;
 	int status;
 	u8 cur_i2c_clk_div;
 	struct gpio_chip *gc;
@@ -330,12 +331,14 @@ static int mcp_i2c_smbus_read(struct mcp2221 *mcp,
 		mcp->txbuf[3] = (u8)(msg->addr << 1);
 		total_len = msg->len;
 		mcp->rxbuf = msg->buf;
+		mcp->rxbuf_size = msg->len;
 	} else {
 		mcp->txbuf[1] = smbus_len;
 		mcp->txbuf[2] = 0;
 		mcp->txbuf[3] = (u8)(smbus_addr << 1);
 		total_len = smbus_len;
 		mcp->rxbuf = smbus_buf;
+		mcp->rxbuf_size = smbus_len;
 	}
 
 	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 4);
@@ -919,6 +922,10 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 					mcp->status = -EINVAL;
 					break;
 				}
+				if (mcp->rxbuf_idx + data[3] > mcp->rxbuf_size) {
+					mcp->status = -EINVAL;
+					break;
+				}
 				buf = mcp->rxbuf;
 				memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
 				mcp->rxbuf_idx = mcp->rxbuf_idx + data[3];
]

gemini-3.1-pro-preview

							input: 32189
							output: 51
							thoughts: 813
						

**Analyzing the MCP2221 Driver Crash**

Okay, so I've been given a potential fix patch for a crash in the `hid-mcp2221` driver. I need to assess this fix, understand the root cause, and ensure this patch is the correct solution.

First, this patch is new; it's not present in the logs. The crash, as indicated by the KASAN report, is a slab-out-of-bounds read within `mcp2221_raw_event`. Specifically, it involves accessing memory at `data[-1]`. The provided explanation is pretty clear: it's due to the logic handling `MCP2221_GPIO_SET` reports before any GPIO operations have occurred. This is because `mcp->gp_idx` remains at zero in this scenario, and the expression `mcp->gp_idx - 1` gets promoted to an integer, resulting in an out-of-bounds access.

The analysis is pinpointing the introduction of the vulnerability to commit `328de1c519c5c0925151cae47944a1c1a0333bcd`, which introduced the `MCP2221_GPIO_SET` handling and the `mcp->gp_idx` variable. If that commit hadn't landed, this specific crash would not exist.

The fix patch includes a size check (`size < 64`). Now, I see this check *also* addresses an earlier out-of-bounds read at `data[20]`, which was introduced in a different commit, `67a95c21463d066060b0f66d65a75d45bb386ffb`. However, the current KASAN report specifies the access to `data[-1]` which directly implicates `mcp->gp_idx - 1` and, therefore, the more recent commit. The fact that the report isolates the `data[-1]` access confirms the primary culprit.

To be certain, I'll need to double-check that no other commits have touched `mcp->gp_idx` or the `MCP2221_GPIO_SET` handling logic within the `mcp2221_raw_event` function. While the explanation suggests this is the specific trigger, it's always good practice to verify this. Then, I can properly validate this patch as the appropriate fix.

map[CodeRegexp:MCP2221_GPIO_SET Count:10 PathPrefix:drivers/hid/hid-mcp2221.c]

map[Output:328de1c519c5 HID: mcp2221: add GPIO functionality support
]

gemini-3.1-pro-preview

							input: 33633
							output: 48
							thoughts: 80
						

Okay, let's break this down.

**Analyzing the MCP2221_GPIO_SET Implementation**

Right, so I'm focusing on that `MCP2221_GPIO_SET` change. I'm pretty sure that the commit `328de1c519c5c0925151cae47944a1c1a0333bcd` is the one that actually *introduced* it, as I suspected. But, and this is crucial for solid analysis, I need to make *absolutely* certain that's the only one touching it. I'm going to quickly check if the `mcp->gp_idx` variable has been modified anywhere else in the code base, because indirect interactions are always a possibility, and I want to be comprehensive in my investigation of this particular function. No stone left unturned to be certain.

map[CodeRegexp:mcp->gp_idx Count:10 PathPrefix:drivers/hid/hid-mcp2221.c]

map[Output:ca6961d8a851 HID: mcp2221: fix get and get_direction for gpio
567b8e9fed8a HID: mcp2221: Fix GPIO output handling
328de1c519c5 HID: mcp2221: add GPIO functionality support
]

gemini-3.1-pro-preview

							input: 34046
							output: 26
							thoughts: 30
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Analyzing Commits**

Okay, time to dive in. My immediate focus is on commits `ca6961d8a851` and `567b8e9fed8a`. Given the context, this likely means I'm in the middle of debugging, code review, or perhaps investigating a specific bug report. I need to understand what changes were introduced by these specific revisions, and how those changes might relate to any issues I'm currently tracking. I'll need to rapidly parse the diffs, focusing on areas of the codebase I know are prone to these kinds of problems, and look for anything that stands out as a potential point of failure, or a potential fix. My expectation is that these commit hashes relate to specific functions I am concerned with. Understanding these commits will be the key to the next steps.

map[Commit:ca6961d8a851]

map[Output:commit ca6961d8a851f3720175f500be38fe9cee5a2c13
Author: Louis Morhet <lmorhet@kalrayinc.com>
Date:   Tue Apr 4 14:15:25 2023 +0200

    HID: mcp2221: fix get and get_direction for gpio
    
    The mcp2221_raw_event retrieves the value and direction of gpio on the
    same command, by setting the value on mcp->status and the direction on
    mcp->gpio_dir; and the offset at which they are read is based on
    mcp->gp_idx, set by the gpiochip callbacks.
    
    However, the individual gpiochip calls set the index to look for
    directly on the field they want to track. This create a "double offset"
    in the final read in the response report.
    
    Align the behaviour of mcp2221_raw_event and
    mcp_gpio_get/mcp_gpio_get_direction by putting gp_idx on those calls to
    the base offset of the gpio status struct.
    
    Signed-off-by: Louis Morhet <lmorhet@kalrayinc.com>
    Link: https://lore.kernel.org/r/dd0b23800a79d2a464e1e9ed429b018b69fd5df2.1680602387.git.lmorhet@kalrayinc.com
    Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index fa20ed4d395a..72883e0ce757 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -594,7 +594,7 @@ static int mcp_gpio_get(struct gpio_chip *gc,
 
 	mcp->txbuf[0] = MCP2221_GPIO_GET;
 
-	mcp->gp_idx = offsetof(struct mcp_get_gpio, gpio[offset].value);
+	mcp->gp_idx = offsetof(struct mcp_get_gpio, gpio[offset]);
 
 	mutex_lock(&mcp->lock);
 	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
@@ -675,7 +675,7 @@ static int mcp_gpio_get_direction(struct gpio_chip *gc,
 
 	mcp->txbuf[0] = MCP2221_GPIO_GET;
 
-	mcp->gp_idx = offsetof(struct mcp_get_gpio, gpio[offset].direction);
+	mcp->gp_idx = offsetof(struct mcp_get_gpio, gpio[offset]);
 
 	mutex_lock(&mcp->lock);
 	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
]

gemini-3.1-pro-preview

							input: 35117
							output: 25
							thoughts: 13
						

Okay, here's my attempt at summarizing the thought process, tailored for an expert audience, and written in the first person:

**Analyzing the Data Stream: Initial Assessment**

Alright, I'm looking at this data stream labeled `567b8e9fed8a`. Immediately, the hexadecimal format jumps out – that's often a sign of encoded or serialized data. My initial thought is to identify the likely encoding or serialization method. Is it a hash? A UUID? Could it be base64, hex-encoded binary, or something more complex like ASN.1? Given the length, it's probably not a simple cryptographic hash like MD5, SHA-1, or even SHA-256 – those are usually shorter, although truncated hashes are a possibility. I need to quickly run through my mental checklist: known encoding schemes, common data serialization libraries, and perhaps even check if there's any context from prior analysis that would give me a hint. The lack of immediately recognizable patterns suggests it's not plain text, so I need to bring out the heavy artillery. Time to grab some tools and start cracking the code.

map[Commit:567b8e9fed8a]

map[Output:commit 567b8e9fed8add9e20885be38ecd73bb0e07406b
Author: Lars Povlsen <lars.povlsen@microchip.com>
Date:   Wed Nov 4 23:02:23 2020 +0100

    HID: mcp2221: Fix GPIO output handling
    
    The mcp2221 driver GPIO output handling has has several issues.
    
    * A wrong value is used for the GPIO direction.
    
    * Wrong offsets are calculated for some GPIO set value/set direction
      operations, when offset is larger than 0.
    
    This has been fixed by introducing proper manifest constants for the
    direction encoding, and using 'offsetof' when calculating GPIO
    register offsets.
    
    The updated driver has been tested with the Sparx5 pcb134/pcb135
    board, which has the mcp2221 device with several (output) GPIO's.
    
    Fixes: 328de1c519c5c092 ("HID: mcp2221: add GPIO functionality support")
    Reviewed-by: Rishi Gupta <gupt21@gmail.com>
    Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index 0d27ccb55dd9..4211b9839209 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -49,6 +49,36 @@ enum {
 	MCP2221_ALT_F_NOT_GPIOD = 0xEF,
 };
 
+/* MCP GPIO direction encoding */
+enum {
+	MCP2221_DIR_OUT = 0x00,
+	MCP2221_DIR_IN = 0x01,
+};
+
+#define MCP_NGPIO	4
+
+/* MCP GPIO set command layout */
+struct mcp_set_gpio {
+	u8 cmd;
+	u8 dummy;
+	struct {
+		u8 change_value;
+		u8 value;
+		u8 change_direction;
+		u8 direction;
+	} gpio[MCP_NGPIO];
+} __packed;
+
+/* MCP GPIO get command layout */
+struct mcp_get_gpio {
+	u8 cmd;
+	u8 dummy;
+	struct {
+		u8 direction;
+		u8 value;
+	} gpio[MCP_NGPIO];
+} __packed;
+
 /*
  * There is no way to distinguish responses. Therefore next command
  * is sent only after response to previous has been received. Mutex
@@ -542,7 +572,7 @@ static int mcp_gpio_get(struct gpio_chip *gc,
 
 	mcp->txbuf[0] = MCP2221_GPIO_GET;
 
-	mcp->gp_idx = (offset + 1) * 2;
+	mcp->gp_idx = offsetof(struct mcp_get_gpio, gpio[offset].value);
 
 	mutex_lock(&mcp->lock);
 	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
@@ -559,7 +589,7 @@ static void mcp_gpio_set(struct gpio_chip *gc,
 	memset(mcp->txbuf, 0, 18);
 	mcp->txbuf[0] = MCP2221_GPIO_SET;
 
-	mcp->gp_idx = ((offset + 1) * 4) - 1;
+	mcp->gp_idx = offsetof(struct mcp_set_gpio, gpio[offset].value);
 
 	mcp->txbuf[mcp->gp_idx - 1] = 1;
 	mcp->txbuf[mcp->gp_idx] = !!value;
@@ -575,7 +605,7 @@ static int mcp_gpio_dir_set(struct mcp2221 *mcp,
 	memset(mcp->txbuf, 0, 18);
 	mcp->txbuf[0] = MCP2221_GPIO_SET;
 
-	mcp->gp_idx = (offset + 1) * 5;
+	mcp->gp_idx = offsetof(struct mcp_set_gpio, gpio[offset].direction);
 
 	mcp->txbuf[mcp->gp_idx - 1] = 1;
 	mcp->txbuf[mcp->gp_idx] = val;
@@ -590,7 +620,7 @@ static int mcp_gpio_direction_input(struct gpio_chip *gc,
 	struct mcp2221 *mcp = gpiochip_get_data(gc);
 
 	mutex_lock(&mcp->lock);
-	ret = mcp_gpio_dir_set(mcp, offset, 0);
+	ret = mcp_gpio_dir_set(mcp, offset, MCP2221_DIR_IN);
 	mutex_unlock(&mcp->lock);
 
 	return ret;
@@ -603,7 +633,7 @@ static int mcp_gpio_direction_output(struct gpio_chip *gc,
 	struct mcp2221 *mcp = gpiochip_get_data(gc);
 
 	mutex_lock(&mcp->lock);
-	ret = mcp_gpio_dir_set(mcp, offset, 1);
+	ret = mcp_gpio_dir_set(mcp, offset, MCP2221_DIR_OUT);
 	mutex_unlock(&mcp->lock);
 
 	/* Can't configure as output, bailout early */
@@ -623,7 +653,7 @@ static int mcp_gpio_get_direction(struct gpio_chip *gc,
 
 	mcp->txbuf[0] = MCP2221_GPIO_GET;
 
-	mcp->gp_idx = (offset + 1) * 2;
+	mcp->gp_idx = offsetof(struct mcp_get_gpio, gpio[offset].direction);
 
 	mutex_lock(&mcp->lock);
 	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
@@ -632,7 +662,7 @@ static int mcp_gpio_get_direction(struct gpio_chip *gc,
 	if (ret)
 		return ret;
 
-	if (mcp->gpio_dir)
+	if (mcp->gpio_dir == MCP2221_DIR_IN)
 		return GPIO_LINE_DIRECTION_IN;
 
 	return GPIO_LINE_DIRECTION_OUT;
@@ -758,7 +788,7 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 				mcp->status = -ENOENT;
 			} else {
 				mcp->status = !!data[mcp->gp_idx];
-				mcp->gpio_dir = !!data[mcp->gp_idx + 1];
+				mcp->gpio_dir = data[mcp->gp_idx + 1];
 			}
 			break;
 		default:
@@ -860,7 +890,7 @@ static int mcp2221_probe(struct hid_device *hdev,
 	mcp->gc->get_direction = mcp_gpio_get_direction;
 	mcp->gc->set = mcp_gpio_set;
 	mcp->gc->get = mcp_gpio_get;
-	mcp->gc->ngpio = 4;
+	mcp->gc->ngpio = MCP_NGPIO;
 	mcp->gc->base = -1;
 	mcp->gc->can_sleep = 1;
 	mcp->gc->parent = &hdev->dev;
]

gemini-3.1-pro-preview

							input: 37475
							output: 51
							thoughts: 1558
						

**Analysis of the MCP2221 Driver Crash**

Okay, let's break this down systematically. I'm looking at a crash report in the MCP2221 HID driver, and it's pinpointing a slab-out-of-bounds read. The root cause appears to be accessing `data[-1]`. I remember seeing that `gp_idx` calculation change in `567b8e9fed8a`, but that wasn't the issue. It was changed to use `offsetof`, which looks correct: `mcp->gp_idx = offsetof(struct mcp_set_gpio, gpio[offset].value)`. Given the struct layout, the offset is at least 3, so that alone isn't the problem.

The key observation is that the crash occurs when `mcp->gp_idx` is zero. Specifically, the expression `data[mcp->gp_idx - 1]` leads to an access of `data[-1]`, and that is a classic out-of-bounds error. The report is clear about this, and the backtrace points directly to that line.

I'm thinking, where was `MCP2221_GPIO_SET` added? I recall it was in `328de1c519c5c0925151cae47944a1c1a0333bcd`. Let me double-check:
```c
+	case MCP2221_GPIO_SET:
+		switch (data[1]) {
+		case MCP2221_SUCCESS:
+			if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
+				(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
```
Bingo. That's it. Before this commit, the driver didn't handle the `MCP2221_GPIO_SET` command. It would fall through to the `default` case, and the input report would not be processed in a way that could cause the out-of-bounds read.

Now, let's consider the fix patch. It introduced `if (unlikely(size < 64)) return 1;`. That's meant to catch out-of-bounds reads if the report is too small. But the crash is *specifically* `data[-1]`, not `data[20]` or something like that. The fix *didn't* address the -1 access.

Wait a second, let me re-examine the fix more closely.
```c
+	if (unlikely(size < 64))
+		return 1;
+
+	if (data[0] != mcp->txbuf[0])
+		return 1;
```
Okay, the `size < 64` *does* catch smaller reports, but the `data[0] != mcp->txbuf[0]` check is the important part here. That check verifies that the incoming report is a response to a command we sent, i.e., that `MCP2221_GPIO_SET` has *already* been handled, and therefore, that `mcp->gp_idx` has already been initialized. This effectively prevents the condition that leads to `data[-1]`.

So, the original bug was introduced in `328de1c519c5c0925151cae47944a1c1a0333bcd`. The fix *does* solve the problem, though the original reasoning regarding the out of bounds was somewhat confused. It prevented a *different* kind of out-of-bounds read, but more importantly, it prevented the -1 access. The fix works because it makes sure that if the report is of the correct kind, then `mcp->gp_idx` will have been initialized.

Therefore, my conclusion is that the bug-introducing commit is definitely `328de1c519c5c0925151cae47944a1c1a0333bcd`.

map[Commit:328de1c519c5c0925151cae47944a1c1a0333bcd]

map[Output:commit 328de1c519c5c0925151cae47944a1c1a0333bcd
Author: Rishi Gupta <gupt21@gmail.com>
Date:   Tue Apr 14 22:18:14 2020 +0530

    HID: mcp2221: add GPIO functionality support
    
    MCP2221 has 4 pins that can be used as GPIO or configured
    for alternate functionality such as clock generation and
    IRQ detection. This patch adds support for GPIO functionality.
    
    To set direction of a pin or to toggle its state after it
    has been configured as GPIO, driver sends command to mcp2221
    and parses response received from mcp2221. Based on this
    response either 0 or appropriate error code is returned to
    GPIO framework.
    
    To get the direction or current state of a pin, driver
    sends command and read response from the device. Based on
    the response received from device direction or value
    is sent to the GPIO framework.
    
    Command from driver to mcp2221 device are output report.
    Response received from mcp2221 is input report.
    
    Datasheet (page 45-48) contains details about how to decode
    the response received from device:
    http://ww1.microchip.com/downloads/en/DeviceDoc/20005565B.pdf
    
    Signed-off-by: Rishi Gupta <gupt21@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index d958475f8c81..e1b93ce32e01 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -15,6 +15,7 @@
 #include <linux/hid.h>
 #include <linux/hidraw.h>
 #include <linux/i2c.h>
+#include <linux/gpio/driver.h>
 #include "hid-ids.h"
 
 /* Commands codes in a raw output report */
@@ -27,6 +28,8 @@ enum {
 	MCP2221_I2C_PARAM_OR_STATUS	= 0x10,
 	MCP2221_I2C_SET_SPEED = 0x20,
 	MCP2221_I2C_CANCEL = 0x10,
+	MCP2221_GPIO_SET = 0x50,
+	MCP2221_GPIO_GET = 0x51,
 };
 
 /* Response codes in a raw input report */
@@ -42,6 +45,8 @@ enum {
 	MCP2221_I2C_WRADDRL_SEND = 0x21,
 	MCP2221_I2C_ADDR_NACK = 0x25,
 	MCP2221_I2C_READ_COMPL = 0x55,
+	MCP2221_ALT_F_NOT_GPIOV = 0xEE,
+	MCP2221_ALT_F_NOT_GPIOD = 0xEF,
 };
 
 /*
@@ -59,6 +64,9 @@ struct mcp2221 {
 	int rxbuf_idx;
 	int status;
 	u8 cur_i2c_clk_div;
+	struct gpio_chip *gc;
+	u8 gp_idx;
+	u8 gpio_dir;
 };
 
 /*
@@ -526,6 +534,110 @@ static const struct i2c_algorithm mcp_i2c_algo = {
 	.functionality = mcp_i2c_func,
 };
 
+static int mcp_gpio_get(struct gpio_chip *gc,
+				unsigned int offset)
+{
+	int ret;
+	struct mcp2221 *mcp = gpiochip_get_data(gc);
+
+	mcp->txbuf[0] = MCP2221_GPIO_GET;
+
+	mcp->gp_idx = (offset + 1) * 2;
+
+	mutex_lock(&mcp->lock);
+	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
+	mutex_unlock(&mcp->lock);
+
+	return ret;
+}
+
+static void mcp_gpio_set(struct gpio_chip *gc,
+				unsigned int offset, int value)
+{
+	struct mcp2221 *mcp = gpiochip_get_data(gc);
+
+	memset(mcp->txbuf, 0, 18);
+	mcp->txbuf[0] = MCP2221_GPIO_SET;
+
+	mcp->gp_idx = ((offset + 1) * 4) - 1;
+
+	mcp->txbuf[mcp->gp_idx - 1] = 1;
+	mcp->txbuf[mcp->gp_idx] = !!value;
+
+	mutex_lock(&mcp->lock);
+	mcp_send_data_req_status(mcp, mcp->txbuf, 18);
+	mutex_unlock(&mcp->lock);
+}
+
+static int mcp_gpio_dir_set(struct mcp2221 *mcp,
+				unsigned int offset, u8 val)
+{
+	memset(mcp->txbuf, 0, 18);
+	mcp->txbuf[0] = MCP2221_GPIO_SET;
+
+	mcp->gp_idx = (offset + 1) * 5;
+
+	mcp->txbuf[mcp->gp_idx - 1] = 1;
+	mcp->txbuf[mcp->gp_idx] = val;
+
+	return mcp_send_data_req_status(mcp, mcp->txbuf, 18);
+}
+
+static int mcp_gpio_direction_input(struct gpio_chip *gc,
+				unsigned int offset)
+{
+	int ret;
+	struct mcp2221 *mcp = gpiochip_get_data(gc);
+
+	mutex_lock(&mcp->lock);
+	ret = mcp_gpio_dir_set(mcp, offset, 0);
+	mutex_unlock(&mcp->lock);
+
+	return ret;
+}
+
+static int mcp_gpio_direction_output(struct gpio_chip *gc,
+				unsigned int offset, int value)
+{
+	int ret;
+	struct mcp2221 *mcp = gpiochip_get_data(gc);
+
+	mutex_lock(&mcp->lock);
+	ret = mcp_gpio_dir_set(mcp, offset, 1);
+	mutex_unlock(&mcp->lock);
+
+	/* Can't configure as output, bailout early */
+	if (ret)
+		return ret;
+
+	mcp_gpio_set(gc, offset, value);
+
+	return 0;
+}
+
+static int mcp_gpio_get_direction(struct gpio_chip *gc,
+				unsigned int offset)
+{
+	int ret;
+	struct mcp2221 *mcp = gpiochip_get_data(gc);
+
+	mcp->txbuf[0] = MCP2221_GPIO_GET;
+
+	mcp->gp_idx = (offset + 1) * 2;
+
+	mutex_lock(&mcp->lock);
+	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
+	mutex_unlock(&mcp->lock);
+
+	if (ret)
+		return ret;
+
+	if (mcp->gpio_dir)
+		return GPIO_LINE_DIRECTION_IN;
+
+	return GPIO_LINE_DIRECTION_OUT;
+}
+
 /* Gives current state of i2c engine inside mcp2221 */
 static int mcp_get_i2c_eng_state(struct mcp2221 *mcp,
 				u8 *data, u8 idx)
@@ -638,6 +750,39 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 		complete(&mcp->wait_in_report);
 		break;
 
+	case MCP2221_GPIO_GET:
+		switch (data[1]) {
+		case MCP2221_SUCCESS:
+			if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
+				(data[mcp->gp_idx + 1] == MCP2221_ALT_F_NOT_GPIOD)) {
+				mcp->status = -ENOENT;
+			} else {
+				mcp->status = !!data[mcp->gp_idx];
+				mcp->gpio_dir = !!data[mcp->gp_idx + 1];
+			}
+			break;
+		default:
+			mcp->status = -EAGAIN;
+		}
+		complete(&mcp->wait_in_report);
+		break;
+
+	case MCP2221_GPIO_SET:
+		switch (data[1]) {
+		case MCP2221_SUCCESS:
+			if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
+				(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
+				mcp->status = -ENOENT;
+			} else {
+				mcp->status = 0;
+			}
+			break;
+		default:
+			mcp->status = -EAGAIN;
+		}
+		complete(&mcp->wait_in_report);
+		break;
+
 	default:
 		mcp->status = -EIO;
 		complete(&mcp->wait_in_report);
@@ -702,8 +847,32 @@ static int mcp2221_probe(struct hid_device *hdev,
 	}
 	i2c_set_adapdata(&mcp->adapter, mcp);
 
+	/* Setup GPIO chip */
+	mcp->gc = devm_kzalloc(&hdev->dev, sizeof(*mcp->gc), GFP_KERNEL);
+	if (!mcp->gc) {
+		ret = -ENOMEM;
+		goto err_gc;
+	}
+
+	mcp->gc->label = "mcp2221_gpio";
+	mcp->gc->direction_input = mcp_gpio_direction_input;
+	mcp->gc->direction_output = mcp_gpio_direction_output;
+	mcp->gc->get_direction = mcp_gpio_get_direction;
+	mcp->gc->set = mcp_gpio_set;
+	mcp->gc->get = mcp_gpio_get;
+	mcp->gc->ngpio = 4;
+	mcp->gc->base = -1;
+	mcp->gc->can_sleep = 1;
+	mcp->gc->parent = &hdev->dev;
+
+	ret = devm_gpiochip_add_data(&hdev->dev, mcp->gc, mcp);
+	if (ret)
+		goto err_gc;
+
 	return 0;
 
+err_gc:
+	i2c_del_adapter(&mcp->adapter);
 err_i2c:
 	hid_hw_close(mcp->hdev);
 err_hstop:
]

gemini-3.1-pro-preview

							input: 43069
							output: 53
							thoughts: 94
						

Okay, here's my understanding, thinking through this as if it were my own process:

**Identifying the Culprit Commit**

Alright, after reviewing the history, it's pretty clear. The commit with the identifier `328de1c519c5c0925151cae47944a1c1a0333bcd` is the one that introduced the bug we're tracking. No doubt about it, based on the diffs and my understanding of the codebase. Therefore, I will formally declare that specific commit as the root cause in the system. Setting the result to `328de1c519c5c0925151cae47944a1c1a0333bcd` is the next logical step.

map[FixesHash:328de1c519c5c0925151cae47944a1c1a0333bcd]

map[FixesHash:328de1c519c5c0925151cae47944a1c1a0333bcd]

map[Fixes:map[Hash:328de1c519c5c0925151cae47944a1c1a0333bcd Title:HID: mcp2221: add GPIO functionality support]]

map[Recipients:[map[Email:bentiss@kernel.org Name:Benjamin Tissoires To:true] map[Email:gupt21@gmail.com Name:Rishi Gupta To:true] map[Email:jikos@kernel.org Name:Jiri Kosina To:true] map[Email:linux-i2c@vger.kernel.org Name: To:true] map[Email:linux-input@vger.kernel.org Name: To:true] map[Email:linux-kernel@vger.kernel.org Name: To:false]]]

map[RecentCommits:HID: mcp2221: fix OOB write in mcp2221_raw_event()
HID: mcp2221: Fix spelling mistake "Enfore" -> "Enforce"
HID: mcp2221: Add module parameter to enfoce GPIO mode
HID: mcp2221: use mcp_i2c_smbus_read for block reads
HID: mcp2221: cancel last I2C command on read error
hid: fix I2C read buffer overflow in raw_event() for mcp2221
treewide: rename GPIO set callbacks back to their original names
HID: mcp-2221: Replace manual comparison with min() macro
HID: mcp2221: set gpio pin mode
HID: mcp2221: use new line value setter callbacks
HID: mcp2221: Remove unnecessary semicolon
HID: mcp-2221: cancel delayed_work only when CONFIG_IIO is enabled
HID: mcp2221: Handle reads greater than 60 bytes
HID: mcp2221: Don't set bus speed on every transfer
HID: mcp2221: Set ACPI companion
HID: mcp2221: Allow IO to start during probe
HID: mcp2221: Set driver data before I2C adapter add
HID: mcp2221: fix get and get_direction for gpio
HID: mcp2221: fix report layout for gpio get
HID: mcp-2221: prevent UAF in delayed work
]

gemini-3.1-pro-preview

You are an experienced Linux kernel developer tasked with writing a commit description for
a kernel bug fixing commit. The description should start with a one-line summary,
and then include description of the bug being fixed, and how it's fixed by the provided patch.

Your final reply should contain only the text of the commit description.
Phrase the one-line summary so that it is not longer than 72 characters.
IMPORTANT: Do not wrap lines manually (e.g., at 80 characters); we will reformat the text
automatically, so keep paragraphs as single lines without newlines.

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

The crash that corresponds to the bug is:

==================================================================
BUG: KASAN: slab-out-of-bounds in mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
Read of size 1 at addr ffff888111fe7fff by task ktimers/0/16

CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted syzkaller #1 PREEMPT_{RT,(full)} 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description+0x55/0x1e0 mm/kasan/report.c:378
 print_report+0x58/0x70 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
 __hid_input_report+0x42b/0x590 drivers/hid/hid-core.c:2161
 hid_irq_in+0x495/0x710 drivers/hid/usbhid/hid-core.c:286
 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657
 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005
 __run_hrtimer kernel/time/hrtimer.c:1930 [inline]
 __hrtimer_run_queues+0x405/0xb10 kernel/time/hrtimer.c:1994
 hrtimer_run_softirq+0x18f/0x260 kernel/time/hrtimer.c:2011
 handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 run_ktimerd+0x69/0x100 kernel/softirq.c:1151
 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

Allocated by task 2:
 kasan_save_stack mm/kasan/common.c:57 [inline]
 kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
 unpoison_slab_object mm/kasan/common.c:340 [inline]
 __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
 kasan_slab_alloc include/linux/kasan.h:253 [inline]
 slab_post_alloc_hook mm/slub.c:4569 [inline]
 slab_alloc_node mm/slub.c:4898 [inline]
 kmem_cache_alloc_node_noprof+0x22a/0x6e0 mm/slub.c:4950
 alloc_task_struct_node kernel/fork.c:187 [inline]
 dup_task_struct+0x52/0x840 kernel/fork.c:918
 copy_process+0x89b/0x4450 kernel/fork.c:2090
 kernel_clone+0x283/0x870 kernel/fork.c:2721
 kernel_thread+0x13f/0x1b0 kernel/fork.c:2782
 create_kthread kernel/kthread.c:459 [inline]
 kthreadd+0x4ec/0x6e0 kernel/kthread.c:817
 ret_from_fork+0x514/0xb70 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 ffff888111fe5880
 which belongs to the cache task_struct of size 7296
The buggy address is located 2815 bytes to the right of
 allocated 7296-byte region [ffff888111fe5880, ffff888111fe7500)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x111fe0
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff888116e25541
flags: 0x100000000000040(head|node=0|zone=2)
page_type: f5(slab)
raw: 0100000000000040 ffff8881012e0500 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800040004 00000000f5000000 ffff888116e25541
head: 0100000000000040 ffff8881012e0500 dead000000000100 dead000000000122
head: 0000000000000000 0000000800040004 00000000f5000000 ffff888116e25541
head: 0100000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
head: 0000000000000000 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 2388, tgid 2388 (kworker/u9:11), ts 15402053339, free_ts 0
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1858
 prep_new_page mm/page_alloc.c:1866 [inline]
 get_page_from_freelist+0x27c8/0x2840 mm/page_alloc.c:3946
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5226
 alloc_slab_page mm/slub.c:3278 [inline]
 allocate_slab+0x77/0x660 mm/slub.c:3467
 new_slab mm/slub.c:3525 [inline]
 refill_objects+0x33c/0x3d0 mm/slub.c:7271
 refill_sheaf mm/slub.c:2816 [inline]
 __pcs_replace_empty_main+0x373/0x720 mm/slub.c:4651
 alloc_from_pcs mm/slub.c:4749 [inline]
 slab_alloc_node mm/slub.c:4883 [inline]
 kmem_cache_alloc_node_noprof+0x4f4/0x6e0 mm/slub.c:4950
 alloc_task_struct_node kernel/fork.c:187 [inline]
 dup_task_struct+0x52/0x840 kernel/fork.c:918
 copy_process+0x89b/0x4450 kernel/fork.c:2090
 kernel_clone+0x283/0x870 kernel/fork.c:2721
 user_mode_thread+0x110/0x180 kernel/fork.c:2797
 call_usermodehelper_exec_work+0x5c/0x230 kernel/umh.c:171
 process_one_work kernel/workqueue.c:3314 [inline]
 process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397
 worker_thread+0x8a2/0xda0 kernel/workqueue.c:3478
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
page_owner free stack trace missing

Memory state around the buggy address:
 ffff888111fe7e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff888111fe7f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888111fe7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                ^
 ffff888111fe8000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff888111fe8080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================



Other crashes triggered:

==================================================================
BUG: KASAN: use-after-free in mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
Read of size 1 at addr ffff8881b72fffff by task ktimers/1/29

CPU: 1 UID: 0 PID: 29 Comm: ktimers/1 Not tainted syzkaller #1 PREEMPT_{RT,(full)} 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_address_description+0x55/0x1e0 mm/kasan/report.c:378
 print_report+0x58/0x70 mm/kasan/report.c:482
 kasan_report+0x117/0x150 mm/kasan/report.c:595
 mcp2221_raw_event+0x10b0/0x12a0 drivers/hid/hid-mcp2221.c:964
 __hid_input_report+0x42b/0x590 drivers/hid/hid-core.c:2161
 hid_irq_in+0x495/0x710 drivers/hid/usbhid/hid-core.c:286
 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657
 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005
 __run_hrtimer kernel/time/hrtimer.c:1930 [inline]
 __hrtimer_run_queues+0x405/0xb10 kernel/time/hrtimer.c:1994
 hrtimer_run_softirq+0x18f/0x260 kernel/time/hrtimer.c:2011
 handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622
 __do_softirq kernel/softirq.c:656 [inline]
 run_ktimerd+0x69/0x100 kernel/softirq.c:1151
 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
 </TASK>

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1b72ff
flags: 0x500000000000000(node=1|zone=2)
raw: 0500000000000000 dead000000000100 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x440dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_COMP), pid 6037, tgid 6037 (syz-executor), ts 125633981260, free_ts 463441946812
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x231/0x280 mm/page_alloc.c:1858
 prep_new_page mm/page_alloc.c:1866 [inline]
 get_page_from_freelist+0x27c8/0x2840 mm/page_alloc.c:3946
 __alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5226
 alloc_pages_mpol+0xd1/0x380 mm/mempolicy.c:2490
 alloc_frozen_pages_noprof mm/mempolicy.c:2561 [inline]
 alloc_pages_noprof+0xd2/0x2f0 mm/mempolicy.c:2581
 pagetable_alloc_noprof include/linux/mm.h:3651 [inline]
 __pte_alloc_one_noprof include/asm-generic/pgalloc.h:76 [inline]
 pte_alloc_one+0x22/0x380 arch/x86/mm/pgtable.c:18
 __pte_alloc+0x25/0x1a0 mm/memory.c:453
 do_anonymous_page mm/memory.c:5338 [inline]
 do_pte_missing+0x21a2/0x2750 mm/memory.c:4548
 handle_pte_fault mm/memory.c:6411 [inline]
 __handle_mm_fault mm/memory.c:6549 [inline]
 handle_mm_fault+0xd09/0x13c0 mm/memory.c:6718
 do_user_addr_fault+0xa73/0x1340 arch/x86/mm/fault.c:1334
 handle_page_fault arch/x86/mm/fault.c:1474 [inline]
 exc_page_fault+0x6a/0xc0 arch/x86/mm/fault.c:1527
 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:618
page last free pid 20 tgid 20 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 __free_pages_prepare mm/page_alloc.c:1402 [inline]
 __free_frozen_pages+0xf48/0x1080 mm/page_alloc.c:2943
 __tlb_remove_table_free mm/mmu_gather.c:228 [inline]
 tlb_remove_table_rcu+0x85/0x100 mm/mmu_gather.c:291
 rcu_do_batch kernel/rcu/tree.c:2617 [inline]
 rcu_core kernel/rcu/tree.c:2869 [inline]
 rcu_cpu_kthread+0x99e/0x1470 kernel/rcu/tree.c:2957
 smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160
 kthread+0x388/0x470 kernel/kthread.c:436
 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Memory state around the buggy address:
 ffff8881b72ffe80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff8881b72fff00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff8881b72fff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                                                                ^
 ffff8881b7300000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff8881b7300080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================




The explanation of the root cause of the bug is:

An analysis of the crash report and the source code reveals that the root cause is an **out-of-bounds read due to a negative array index** in `mcp2221_raw_event()`, combined with a lack of bounds checking on the incoming HID report size.

### Detailed Explanation

1. **Uninitialized State**: 
   When the `mcp2221` device is probed, its state structure is allocated using `devm_kzalloc()`, which zero-initializes all fields. The `mcp->gp_idx` field (a `u8`) is initialized to `0`. It is only updated to a valid positive offset (e.g., 3, 7, 11, or 15) when the GPIO subsystem invokes the driver's GPIO operations like `mcp_gpio_set()`.

2. **The Vulnerability**:
   If the device sends an `MCP2221_GPIO_SET` (0x50) input report *before* any GPIO operations are performed (or if a malicious device/reproducer injects one), `mcp2221_raw_event()` processes the report while `mcp->gp_idx` is still `0`.
   
   Looking at `drivers/hid/hid-mcp2221.c` around line 964:
   ```c
   960:		case MCP2221_GPIO_SET:
   961:			switch (data[1]) {
   962:			case MCP2221_SUCCESS:
   963:				if ((data[mcp->gp_idx] == MCP2221_ALT_F_NOT_GPIOV) ||
   964:					(data[mcp->gp_idx - 1] == MCP2221_ALT_F_NOT_GPIOV)) {
   ```
   Because `mcp->gp_idx` is `0`, the expression `mcp->gp_idx - 1` promotes the `u8` to an `int`, resulting in `-1`. This causes the code to access `data[-1]`.

3. **Memory Layout and the KASAN Report**:
   The `data` pointer passed to `mcp2221_raw_event()` points to the URB transfer buffer, which is allocated by the USB core via `kmalloc()` (e.g., from the `kmalloc-64` cache). 
   
   In the crashing scenario, the SLUB allocator placed this 64-byte buffer at the very beginning of a new page, exactly at address `ffff888111fe8000`. 
   
   When the code evaluates `data[-1]`, it reads the address `ffff888111fe7fff`. This address is the last byte of the *previous* physical page. As shown in the KASAN report, the previous page (`pfn:0x111fe0`) was an order-3 slab page belonging to the `task_struct` cache. The last `task_struct` object in that page ended at `ffff888111fe7500`, and the remainder of the page was SLUB padding/redzone (filled with `fc`).
   
   KASAN intercepted the read at `ffff888111fe7fff` and correctly reported it as a slab-out-of-bounds read located 2815 bytes to the right of the `task_struct` object.

   ```text
    ffff888111fe7f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
   >ffff888111fe7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                   ^ (data[-1] at ffff888111fe7fff)
    ffff888111fe8000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  <-- data (urb->transfer_buffer)
   ```

### How to Fix

To fix this bug, `mcp2221_raw_event()` needs two corrections:
1. **Validate `mcp->gp_idx`**: Ensure that `mcp->gp_idx` is valid (e.g., `mcp->gp_idx > 0`) before using it as an array index.
2. **Bounds Checking**: The function completely lacks bounds checking on the `size` parameter. It blindly accesses `data[0]`, `data[1]`, and various other offsets (like `data[50]` in the `MCP2221_I2C_PARAM_OR_STATUS` case). It should verify that `size` is large enough for the specific report being processed before accessing the `data` array.

The diff of the bug fix is:

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index e4ddd8e92..7f4f2110b 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -861,6 +861,12 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 	u8 *buf;
 	struct mcp2221 *mcp = hid_get_drvdata(hdev);
 
+	if (unlikely(size < 64))
+		return 1;
+
+	if (data[0] != mcp->txbuf[0])
+		return 1;
+
 	switch (data[0]) {
 
 	case MCP2221_I2C_WR_DATA:


Additional description of the patch:

An analysis of the crash report and the driver's source code reveals that the root cause is an out-of-bounds read due to a negative array index in `mcp2221_raw_event()`, combined with a lack of bounds checking on the incoming HID report size.

### Detailed Explanation

1. **Uninitialized State & Stray Reports**: 
   When the `mcp2221` device is probed, its state structure is allocated using `devm_kzalloc()`, which zero-initializes all fields. The `mcp->gp_idx` field is initialized to `0`. It is only updated to a valid positive offset when the GPIO subsystem invokes the driver's GPIO operations (like `mcp_gpio_set()`).
   The `mcp2221_raw_event()` function is called for any incoming HID input report. It blindly processes the report based on the command byte `data[0]`, without verifying if the report is actually a response to the command the driver just sent.

2. **The Vulnerability**:
   If the device sends an `MCP2221_GPIO_SET` (0x50) input report *before* any GPIO operations are performed (or if a malicious device/reproducer injects one), `mcp2221_raw_event()` processes the report while `mcp->gp_idx` is still `0`.
   Because `mcp->gp_idx` is `0`, the expression `mcp->gp_idx - 1` results in `-1`, causing the code to access `data[-1]`. This reads out of the bounds of the URB transfer buffer, triggering the KASAN slab-out-of-bounds report.

3. **Lack of Bounds Checking**:
   The function completely lacks bounds checking on the `size` parameter. It blindly accesses various offsets (like `data[50]` in the `MCP2221_I2C_PARAM_OR_STATUS` case). The expected report size for MCP2221 is 64 bytes.

### The Fix

To fix this bug comprehensively, we need to ensure that `mcp2221_raw_event()` only processes valid responses to the currently pending command, and that the report size is correct.

1. **Size Validation**: We add a check to ensure `size >= 64` at the beginning of the function. If the size is smaller, we ignore the report.
2. **Command Validation**: The driver always stores the command byte it sends in `mcp->txbuf[0]`. The MCP2221 device always echoes this command byte in the first byte of its response (`data[0]`). By checking `if (data[0] != mcp->txbuf[0])`, we can safely ignore any stray, delayed, or malicious reports that do not match the currently pending command.
   Since `mcp->txbuf[0]` and `mcp->gp_idx` are always set together when sending GPIO commands, this check inherently guarantees that `mcp->gp_idx` is valid and correctly initialized for the specific command being processed, preventing the `-1` index access.

I have applied the following patch to `drivers/hid/hid-mcp2221.c`:

```c
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -858,6 +858,12 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 	u8 *buf;
 	struct mcp2221 *mcp = hid_get_drvdata(hdev);
 
+	if (unlikely(size < 64))
+		return 1;
+
+	if (data[0] != mcp->txbuf[0])
+		return 1;
+
 	switch (data[0]) {
 
 	case MCP2221_I2C_WR_DATA:
```

Here are summaries of recent commits that touched the same files.
Format the summary line consistently with these, look how prefixes
are specified, letter capitalization, style, etc. 

HID: mcp2221: fix OOB write in mcp2221_raw_event()
HID: mcp2221: Fix spelling mistake "Enfore" -> "Enforce"
HID: mcp2221: Add module parameter to enfoce GPIO mode
HID: mcp2221: use mcp_i2c_smbus_read for block reads
HID: mcp2221: cancel last I2C command on read error
hid: fix I2C read buffer overflow in raw_event() for mcp2221
treewide: rename GPIO set callbacks back to their original names
HID: mcp-2221: Replace manual comparison with min() macro
HID: mcp2221: set gpio pin mode
HID: mcp2221: use new line value setter callbacks
HID: mcp2221: Remove unnecessary semicolon
HID: mcp-2221: cancel delayed_work only when CONFIG_IIO is enabled
HID: mcp2221: Handle reads greater than 60 bytes
HID: mcp2221: Don't set bus speed on every transfer
HID: mcp2221: Set ACPI companion
HID: mcp2221: Allow IO to start during probe
HID: mcp2221: Set driver data before I2C adapter add
HID: mcp2221: fix get and get_direction for gpio
HID: mcp2221: fix report layout for gpio get
HID: mcp-2221: prevent UAF in delayed work

HID: mcp2221: fix OOB read in mcp2221_raw_event()

syzbot reported a slab-out-of-bounds read in mcp2221_raw_event(). This happens because the driver does not validate the size of the incoming HID report and blindly processes it based on the command byte data[0], without verifying if the report is actually a response to the command the driver just sent.

If the device sends an MCP2221_GPIO_SET (0x50) input report before any GPIO operations are performed (or if a malicious device injects one), mcp->gp_idx is still 0. The expression mcp->gp_idx - 1 results in -1, causing the code to access data[-1], which reads out of the bounds of the URB transfer buffer.

To fix this, ensure that the report size is at least 64 bytes (the expected report size for MCP2221). Also, verify that the incoming report matches the currently pending command by checking data[0] != mcp->txbuf[0]. Since mcp->txbuf[0] and mcp->gp_idx are always set together when sending GPIO commands, this check inherently guarantees that mcp->gp_idx is valid and correctly initialized for the specific command being processed, preventing the out-of-bounds access.

gemini-3.1-pro-preview

							input: 11303
							output: 297
							thoughts: 1187
						

**Analyzing and Fixing the MCP2221 Driver's Out-of-Bounds Read**

Okay, so I'm looking at this bug report from syzbot, and it's a slab-out-of-bounds read in `mcp2221_raw_event()`. My initial thought is that the driver isn't properly validating the input report it receives from the MCP2221 device. It seems to be blindly processing the data based on the command byte, `data[0]`, without checking if it's a legitimate response to a command the driver actually sent.

The root cause appears to be that `mcp->gp_idx` can be zero in certain scenarios, specifically if the device sends an `MCP2221_GPIO_SET` (0x50) input report *before* any GPIO operations have been performed, or potentially a malicious device injects one. This leads to the expression `mcp->gp_idx - 1` evaluating to -1. The consequence of this is an attempted access of `data[-1]`, which is obviously outside the bounds of the URB transfer buffer, hence the out-of-bounds read.

The solution I'm proposing involves two checks to prevent this. First, I want to ensure that the report size is at least 64 bytes. This size is the expected report size for the MCP2221. Second, and crucially, I'm verifying that the incoming report matches the currently pending command by checking that `data[0] != mcp->txbuf[0]`. Since `mcp->txbuf[0]` and `mcp->gp_idx` are always set together when the driver *sends* GPIO commands, this comparison inherently guarantees that `mcp->gp_idx` is valid and properly initialized for the specific command being processed. This effectively prevents the out-of-bounds access.

I'm aiming for a commit summary of "HID: mcp2221: fix OOB read in mcp2221_raw_event()", because it mirrors the wording of a previous commit which dealt with a write issue. It's concise and accurately reflects the nature of the fix. I think the description above is a good, concise explanation of the problem and the proposed solution. I will send it off to the mailing list.

map[PatchDescription:HID: mcp2221: fix OOB read in mcp2221_raw_event()

syzbot reported a slab-out-of-bounds read in mcp2221_raw_event(). This
happens because the driver does not validate the size of the incoming
HID report and blindly processes it based on the command byte data[0],
without verifying if the report is actually a response to the command
the driver just sent.

If the device sends an MCP2221_GPIO_SET (0x50) input report before any
GPIO operations are performed (or if a malicious device injects one),
mcp->gp_idx is still 0. The expression mcp->gp_idx - 1 results in -1,
causing the code to access data[-1], which reads out of the bounds of
the URB transfer buffer.

To fix this, ensure that the report size is at least 64 bytes (the
expected report size for MCP2221). Also, verify that the incoming report
matches the currently pending command by checking data[0] !=
mcp->txbuf[0]. Since mcp->txbuf[0] and mcp->gp_idx are always set
together when sending GPIO commands, this check inherently guarantees
that mcp->gp_idx is valid and correctly initialized for the specific
command being processed, preventing the out-of-bounds access.]

map[AckedBy:<nil> ReportedBy:<nil> ReviewedBy:<nil> TestedBy:<nil>]