{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.0.8-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.0.8-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.0.8-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  net: dsa: Fix possible memory leaks in dsa_loop_init()  kmemleak reported memory leaks in dsa_loop_init():  kmemleak: 12 new suspected memory leaks  unreferenced object 0xffff8880138ce000 (size 2048):   comm \"modprobe\", pid 390, jiffies 4295040478 (age 238.976s)   backtrace:     [\u003c000000006a94f1d5\u003e] kmalloc_trace+0x26/0x60     [\u003c00000000a9c44622\u003e] phy_device_create+0x5d/0x970     [\u003c00000000d0ee2afc\u003e] get_phy_device+0xf3/0x2b0     [\u003c00000000dca0c71f\u003e] __fixed_phy_register.part.0+0x92/0x4e0     [\u003c000000008a834798\u003e] fixed_phy_register+0x84/0xb0     [\u003c0000000055223fcb\u003e] dsa_loop_init+0xa9/0x116 [dsa_loop]     ...  There are two reasons for memleak in dsa_loop_init().  First, fixed_phy_register() create and register phy_device:  fixed_phy_register()   get_phy_device()     phy_device_create() # freed by phy_device_free()   phy_device_register() # freed by phy_device_remove()  But fixed_phy_unregister() only calls phy_device_remove(). So the memory allocated in phy_device_create() is leaked.  Second, when mdio_driver_register() fail in dsa_loop_init(), it just returns and there is no cleanup for phydevs.  Fix the problems by catching the error of mdio_driver_register() in dsa_loop_init(), then calling both fixed_phy_unregister() and phy_device_free() to release phydevs. Also add a function for phydevs cleanup to avoid duplacate.",
  "id": "DEBIAN-CVE-2022-49926",
  "modified": "2026-09-01T19:48:45.944755025Z",
  "published": "2025-05-01T15:16:18.440Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2022-49926"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2022-49926"
  ]
}