Vulnerability-Lookup

GHSA-9M6W-7G2Q-R25C

Vulnerability from github – Published: 2026-09-24 18:31 – Updated: 2026-09-25 06:30

Details

In the Linux kernel, the following vulnerability has been resolved:

i2c: smbus: reject oversized block transfers in the common path

The SMBus block transfer length data->block[0] is validated in i2c_smbus_xfer_emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus_xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked.

Add an early validation in __i2c_smbus_xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus_write tracepoint, all native smbus_xfer driver implementations, and the emulated path.

Two distinct bugs are fixed by this change:

Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h) trace_smbus_write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221.

BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91 Call Trace: __asan_memcpy+0x23/0x80 trace_event_raw_event_smbus_write+0x27c/0x530 __i2c_smbus_xfer+0x43a/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c) stub_xfer() implements .smbus_xfer directly and only clamps block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union.

UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type '__u8 [34]' Call Trace: __ubsan_handle_out_of_bounds+0xd7/0x120 stub_xfer+0x1971/0x198f [i2c_stub] __i2c_smbus_xfer+0x306/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-93287"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-24T17:17:09Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: smbus: reject oversized block transfers in the common path\n\nThe SMBus block transfer length data-\u003eblock[0] is validated in\ni2c_smbus_xfer_emulated() but that check runs too late for tracepoints\nand is skipped entirely when the adapter provides a native smbus_xfer\nimplementation. This allows user-controlled oversized block lengths to\nreach tracepoint memcpy calls and driver callbacks unchecked.\n\nAdd an early validation in __i2c_smbus_xfer() that rejects block\ntransfers whose caller-supplied length is zero or exceeds\nI2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback\nruns. data-\u003eblock[0] is filled in by the device on SMBus block reads,\nso the check is scoped to operations where the length is actually\nsupplied by the caller. This is consistent with the existing -EINVAL\nconvention in the emulated path and protects all downstream consumers\nat once: the smbus_write tracepoint, all native smbus_xfer driver\nimplementations, and the emulated path.\n\nTwo distinct bugs are fixed by this change:\n\nBug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h)\n  trace_smbus_write() fires before any validation and copies\n  data-\u003eblock[0]+1 bytes into a 34-byte event buffer. With\n  block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221.\n\n BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530\n Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91\n Call Trace:\n  \u003cTASK\u003e\n  __asan_memcpy+0x23/0x80\n  trace_event_raw_event_smbus_write+0x27c/0x530\n  __i2c_smbus_xfer+0x43a/0xa40\n  i2c_smbus_xfer+0x19e/0x340\n  i2cdev_ioctl_smbus+0x38f/0x7f0\n  i2cdev_ioctl+0x35e/0x680\n  __x64_sys_ioctl+0x147/0x1e0\n  do_syscall_64+0xcf/0x15a0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  \u003c/TASK\u003e\n\nBug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c)\n  stub_xfer() implements .smbus_xfer directly and only clamps\n  block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With\n  block[0]=0xff and command=0 the loop accesses block[1+i] for\n  i up to 254, far past the 34-byte union.\n\n UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44\n index 34 is out of range for type \u0027__u8 [34]\u0027\n Call Trace:\n  \u003cTASK\u003e\n  __ubsan_handle_out_of_bounds+0xd7/0x120\n  stub_xfer+0x1971/0x198f [i2c_stub]\n  __i2c_smbus_xfer+0x306/0xa40\n  i2c_smbus_xfer+0x19e/0x340\n  i2cdev_ioctl_smbus+0x38f/0x7f0\n  i2cdev_ioctl+0x35e/0x680\n  __x64_sys_ioctl+0x147/0x1e0\n  do_syscall_64+0xcf/0x15a0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  \u003c/TASK\u003e\n\nBoth traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.",
  "id": "GHSA-9m6w-7g2q-r25c",
  "modified": "2026-09-25T06:30:29Z",
  "published": "2026-09-24T18:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93287"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3051cd060fa496df42954291fa2306ed2eab4ecc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c4b478bc50b7ca9865e237909941253a0f7111a2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f09edffba97d37b1fdff5f818a9a45f8a98ac171"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2026-93287 (GCVE-0-2026-93287)

Vulnerability from cvelistv5 – Published: 2026-09-24 16:02 – Updated: 2026-09-25 05:10

Title

i2c: smbus: reject oversized block transfers in the common path

Summary

In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: reject oversized block transfers in the common path The SMBus block transfer length data->block[0] is validated in i2c_smbus_xfer_emulated() but that check runs too late for tracepoints and is skipped entirely when the adapter provides a native smbus_xfer implementation. This allows user-controlled oversized block lengths to reach tracepoint memcpy calls and driver callbacks unchecked. Add an early validation in __i2c_smbus_xfer() that rejects block transfers whose caller-supplied length is zero or exceeds I2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback runs. data->block[0] is filled in by the device on SMBus block reads, so the check is scoped to operations where the length is actually supplied by the caller. This is consistent with the existing -EINVAL convention in the emulated path and protects all downstream consumers at once: the smbus_write tracepoint, all native smbus_xfer driver implementations, and the emulated path. Two distinct bugs are fixed by this change: Bug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h) trace_smbus_write() fires before any validation and copies data->block[0]+1 bytes into a 34-byte event buffer. With block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221. BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530 Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91 Call Trace: <TASK> __asan_memcpy+0x23/0x80 trace_event_raw_event_smbus_write+0x27c/0x530 __i2c_smbus_xfer+0x43a/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Bug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c) stub_xfer() implements .smbus_xfer directly and only clamps block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With block[0]=0xff and command=0 the loop accesses block[1+i] for i up to 254, far past the 34-byte union. UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44 index 34 is out of range for type '__u8 [34]' Call Trace: <TASK> __ubsan_handle_out_of_bounds+0xd7/0x120 stub_xfer+0x1971/0x198f [i2c_stub] __i2c_smbus_xfer+0x306/0xa40 i2c_smbus_xfer+0x19e/0x340 i2cdev_ioctl_smbus+0x38f/0x7f0 i2cdev_ioctl+0x35e/0x680 __x64_sys_ioctl+0x147/0x1e0 do_syscall_64+0xcf/0x15a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Both traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN.

Severity

7.8 (High)


                        
                          CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Assigner

Linux mitre root

References

3 references

URL	Tags
https://git.kernel.org/stable/c/f09edffba97d37b1f…
https://git.kernel.org/stable/c/c4b478bc50b7ca986…
https://git.kernel.org/stable/c/3051cd060fa496df4…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: 4710317891e4824ce1510a6b5066abbd3e917750 , < f09edffba97d37b1fdff5f818a9a45f8a98ac171 (git) Affected: 4710317891e4824ce1510a6b5066abbd3e917750 , < c4b478bc50b7ca9865e237909941253a0f7111a2 (git) Affected: 4710317891e4824ce1510a6b5066abbd3e917750 , < 3051cd060fa496df42954291fa2306ed2eab4ecc (git)
Linux	Linux	Affected: 2.6.33 Unaffected: 0 , < 2.6.33 (semver) Unaffected: 6.12.111 , ≤ 6.12.* (semver) Unaffected: 6.18.53 , ≤ 6.18.* (semver) Unaffected: 7.1 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/i2c/i2c-core-smbus.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "f09edffba97d37b1fdff5f818a9a45f8a98ac171",
              "status": "affected",
              "version": "4710317891e4824ce1510a6b5066abbd3e917750",
              "versionType": "git"
            },
            {
              "lessThan": "c4b478bc50b7ca9865e237909941253a0f7111a2",
              "status": "affected",
              "version": "4710317891e4824ce1510a6b5066abbd3e917750",
              "versionType": "git"
            },
            {
              "lessThan": "3051cd060fa496df42954291fa2306ed2eab4ecc",
              "status": "affected",
              "version": "4710317891e4824ce1510a6b5066abbd3e917750",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/i2c/i2c-core-smbus.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.33"
            },
            {
              "lessThan": "2.6.33",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.111",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.53",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.111",
                  "versionStartIncluding": "2.6.33",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.53",
                  "versionStartIncluding": "2.6.33",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1",
                  "versionStartIncluding": "2.6.33",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: smbus: reject oversized block transfers in the common path\n\nThe SMBus block transfer length data-\u003eblock[0] is validated in\ni2c_smbus_xfer_emulated() but that check runs too late for tracepoints\nand is skipped entirely when the adapter provides a native smbus_xfer\nimplementation. This allows user-controlled oversized block lengths to\nreach tracepoint memcpy calls and driver callbacks unchecked.\n\nAdd an early validation in __i2c_smbus_xfer() that rejects block\ntransfers whose caller-supplied length is zero or exceeds\nI2C_SMBUS_BLOCK_MAX before any tracepoint fires or driver callback\nruns. data-\u003eblock[0] is filled in by the device on SMBus block reads,\nso the check is scoped to operations where the length is actually\nsupplied by the caller. This is consistent with the existing -EINVAL\nconvention in the emulated path and protects all downstream consumers\nat once: the smbus_write tracepoint, all native smbus_xfer driver\nimplementations, and the emulated path.\n\nTwo distinct bugs are fixed by this change:\n\nBug 1: smbus_write tracepoint OOB (include/trace/events/smbus.h)\n  trace_smbus_write() fires before any validation and copies\n  data-\u003eblock[0]+1 bytes into a 34-byte event buffer. With\n  block[0]=0xfe the tracepoint copies 255 bytes, overflowing by 221.\n\n BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_smbus_write+0x27c/0x530\n Read of size 255 at addr ffff88800d98fcf8 by task poc_smbus/91\n Call Trace:\n  \u003cTASK\u003e\n  __asan_memcpy+0x23/0x80\n  trace_event_raw_event_smbus_write+0x27c/0x530\n  __i2c_smbus_xfer+0x43a/0xa40\n  i2c_smbus_xfer+0x19e/0x340\n  i2cdev_ioctl_smbus+0x38f/0x7f0\n  i2cdev_ioctl+0x35e/0x680\n  __x64_sys_ioctl+0x147/0x1e0\n  do_syscall_64+0xcf/0x15a0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  \u003c/TASK\u003e\n\nBug 2: i2c-stub I2C_SMBUS_I2C_BLOCK_DATA OOB (drivers/i2c/i2c-stub.c)\n  stub_xfer() implements .smbus_xfer directly and only clamps\n  block[0] against 256-command, not I2C_SMBUS_BLOCK_MAX. With\n  block[0]=0xff and command=0 the loop accesses block[1+i] for\n  i up to 254, far past the 34-byte union.\n\n UBSAN: array-index-out-of-bounds in drivers/i2c/i2c-stub.c:223:44\n index 34 is out of range for type \u0027__u8 [34]\u0027\n Call Trace:\n  \u003cTASK\u003e\n  __ubsan_handle_out_of_bounds+0xd7/0x120\n  stub_xfer+0x1971/0x198f [i2c_stub]\n  __i2c_smbus_xfer+0x306/0xa40\n  i2c_smbus_xfer+0x19e/0x340\n  i2cdev_ioctl_smbus+0x38f/0x7f0\n  i2cdev_ioctl+0x35e/0x680\n  __x64_sys_ioctl+0x147/0x1e0\n  do_syscall_64+0xcf/0x15a0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  \u003c/TASK\u003e\n\nBoth traces reproduced on v7.0-rc6+i2c/for-current with KASAN+UBSAN."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - Attacker-controlled data is data-\u003eblock[0] copied from the I2C_SMBUS ioctl in i2cdev_ioctl_smbus() (i2cdev_ioctl \u2192 i2cdev_ioctl_smbus \u2192 i2c_smbus_xfer \u2192 __i2c_smbus_xfer). That byte is supplied by the local process, not by a network protocol or a remote I2C slave.\nAC:L - A single I2C_SMBUS ioctl with attacker-chosen block[0] (e.g. 0xfe) is consumed in __i2c_smbus_xfer() before any length check, so trace_smbus_write() memcpy()s block[0]+1 bytes and native callbacks such as stub_xfer() index block[1+i] with that length. There is no race or uninfluenced hardware failure.\nPR:L - i2cdev_open() and i2cdev_ioctl() contain no capable() check; I2C_SMBUS is allowed to whoever can open /dev/i2c-N. That node is commonly 0660 group i2c (i2c-tools udev), so an unprivileged i2c-group user reaches i2cdev_ioctl_smbus() without root or a user-namespace capability.\nUI:N - The attacker opens /dev/i2c-N and issues the I2C_SMBUS ioctl with a crafted i2c_smbus_ioctl_data themselves; no separate victim action is required.\nS:U - Overflows land in the host kernel\u0027s i2cdev_ioctl_smbus() stack union and in the smbus_write trace-event buffer handled by that same kernel. This is ordinary local kernel memory corruption, not a VM, IOMMU, or sandbox-authority crossing.\nC:H - With block[0]=0xfe, trace_smbus_write() memcpy()s 255 bytes from the 34-byte union i2c_smbus_data temp on i2cdev_ioctl_smbus()\u0027s stack, disclosing 221 bytes of adjacent kernel stack. stub_xfer() I2C_SMBUS_I2C_BLOCK_DATA writes likewise read block[1+i] past that union.\nI:H - The same memcpy writes 255 bytes into smbus_write\u0027s 34-byte __entry-\u003ebuf, overflowing the ftrace event by 221 bytes. stub_xfer() I2C_SMBUS_I2C_BLOCK_DATA reads write past temp.block[33] on i2cdev_ioctl_smbus()\u0027s kernel stack, a stack overflow that can corrupt return state.\nA:H - The 221-byte out-of-bounds read/write in trace_event_raw_event_smbus_write() and the stub_xfer() store past union i2c_smbus_data.block[33] produce a kernel oops/panic, matching the KASAN and UBSAN reports cited in the fix."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-25T05:10:01.737Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/f09edffba97d37b1fdff5f818a9a45f8a98ac171"
        },
        {
          "url": "https://git.kernel.org/stable/c/c4b478bc50b7ca9865e237909941253a0f7111a2"
        },
        {
          "url": "https://git.kernel.org/stable/c/3051cd060fa496df42954291fa2306ed2eab4ecc"
        }
      ],
      "title": "i2c: smbus: reject oversized block transfers in the common path",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-93287",
    "datePublished": "2026-09-24T16:02:11.296Z",
    "dateReserved": "2026-09-17T16:02:15.099Z",
    "dateUpdated": "2026-09-25T05:10:01.737Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-9M6W-7G2Q-R25C

CVE-2026-93287 (GCVE-0-2026-93287)

Tags

Sightings

Nomenclature

Related by attack behaviour