Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2022-49390 (GCVE-0-2022-49390)
Vulnerability from cvelistv5 – Published: 2025-02-26 02:11 – Updated: 2026-08-05 08:54- CWE-416 - Use After Free
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
2bce1ebed17da54c65042ec2b962e3234bad5b47 , < 78933cbc143b82d02330e00900d2fd08f2682f4e
(git)
Affected: 2bce1ebed17da54c65042ec2b962e3234bad5b47 , < d130282179aa6051449ac8f8df1115769998a665 (git) Affected: 2bce1ebed17da54c65042ec2b962e3234bad5b47 , < 196a888ca6571deb344468e1d7138e3273206335 (git) Affected: 1861904a6092ed411203c6a02c75bfc45b27cc3c (git) Affected: 3a2675a2d97a68332fa5c33043038bfeb31455a8 (git) Affected: b0add6db3d5ec4561cab257358871a9d3df7f0a3 (git) Affected: 4.14.154 , < 4.15 (semver) Affected: 4.19.84 , < 4.20 (semver) Affected: 5.3.11 , < 5.4 (semver) |
guessed | |
| Linux | Linux |
Affected:
5.4
Unaffected: 0 , < 5.4 (semver) Unaffected: 5.17.15 , ≤ 5.17.* (semver) Unaffected: 5.18.3 , ≤ 5.18.* (semver) Unaffected: 5.19 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2022-49390",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-27T17:58:33.560218Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-416",
"description": "CWE-416 Use After Free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-02-27T18:02:28.747Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/macsec.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "78933cbc143b82d02330e00900d2fd08f2682f4e",
"status": "affected",
"version": "2bce1ebed17da54c65042ec2b962e3234bad5b47",
"versionType": "git"
},
{
"lessThan": "d130282179aa6051449ac8f8df1115769998a665",
"status": "affected",
"version": "2bce1ebed17da54c65042ec2b962e3234bad5b47",
"versionType": "git"
},
{
"lessThan": "196a888ca6571deb344468e1d7138e3273206335",
"status": "affected",
"version": "2bce1ebed17da54c65042ec2b962e3234bad5b47",
"versionType": "git"
},
{
"status": "affected",
"version": "1861904a6092ed411203c6a02c75bfc45b27cc3c",
"versionType": "git"
},
{
"status": "affected",
"version": "3a2675a2d97a68332fa5c33043038bfeb31455a8",
"versionType": "git"
},
{
"status": "affected",
"version": "b0add6db3d5ec4561cab257358871a9d3df7f0a3",
"versionType": "git"
},
{
"lessThan": "4.15",
"status": "affected",
"version": "4.14.154",
"versionType": "semver"
},
{
"lessThan": "4.20",
"status": "affected",
"version": "4.19.84",
"versionType": "semver"
},
{
"lessThan": "5.4",
"status": "affected",
"version": "5.3.11",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/macsec.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.4"
},
{
"lessThan": "5.4",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.17.*",
"status": "unaffected",
"version": "5.17.15",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.18.*",
"status": "unaffected",
"version": "5.18.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.17.15",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.18.3",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.19",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.14.154",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.19.84",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.3.11",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\")\nand commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem."
}
],
"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 - Exploitation requires creating and tearing down macsec/veth netdevices via rtnetlink (ip link), which is a local syscall/netlink interface, not reachable from remote packet processing.\nAC:L - An attacker who creates a macsec device over a veth and then deletes the lower device fully controls both sides of the teardown that triggers the UAF; syzkaller hits this reliably without depending on conditions outside attacker influence.\nPR:L - Creating macsec requires CAP_NET_ADMIN, but that capability is checked in the network namespace\u0027s user_ns (netlink_net_capable/ns_capable), so an unprivileged user with user+net namespaces (unshare -Urn) can trigger it; macsec is also netnsok and autoloadable via rtnl-link-macsec.\nUI:N - The attacker triggers the bug entirely through their own netlink operations to create and destroy devices; no victim action is required.\nS:U - This is a standard in-kernel use-after-free enabling local privilege escalation within the same kernel security authority, not a VM/IOMMU/sandbox boundary escape.\nC:H - Use-after-free of the underlying net_device allows the freed object to be reclaimed and its contents controlled, enabling arbitrary kernel memory disclosure primitives.\nI:H - UAF of a large net_device object is exploitable via heap spraying for arbitrary write and control-flow hijacking, consistent with treating kernel UAFs as high integrity impact.\nA:H - The UAF is observed as a KASAN use-after-free in macsec_get_iflink during linkwatch processing and can cause kernel oops/panic even without full exploitation."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T08:54:59.892Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/78933cbc143b82d02330e00900d2fd08f2682f4e"
},
{
"url": "https://git.kernel.org/stable/c/d130282179aa6051449ac8f8df1115769998a665"
},
{
"url": "https://git.kernel.org/stable/c/196a888ca6571deb344468e1d7138e3273206335"
}
],
"title": "macsec: fix UAF bug for real_dev",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2022-49390",
"datePublished": "2025-02-26T02:11:23.327Z",
"dateReserved": "2025-02-26T02:08:31.561Z",
"dateUpdated": "2026-08-05T08:54:59.892Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2022-49390",
"date": "2026-09-30",
"epss": "0.0027",
"percentile": "0.17382"
},
"microsoft_vex": {
"current_release_date": "2026-02-18T01:14:55.000Z",
"cve": "CVE-2022-49390",
"id": "msrc_CVE-2022-49390",
"initial_release_date": "2025-02-02T00:00:00.000Z",
"product_status:known_not_affected": "2",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "macsec: fix UAF bug for real_dev",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2022-49390.json",
"version": "2"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/macsec.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "78933cbc143b82d02330e00900d2fd08f2682f4e",
"status": "affected",
"version": "2bce1ebed17da54c65042ec2b962e3234bad5b47",
"versionType": "git"
},
{
"lessThan": "d130282179aa6051449ac8f8df1115769998a665",
"status": "affected",
"version": "2bce1ebed17da54c65042ec2b962e3234bad5b47",
"versionType": "git"
},
{
"lessThan": "196a888ca6571deb344468e1d7138e3273206335",
"status": "affected",
"version": "2bce1ebed17da54c65042ec2b962e3234bad5b47",
"versionType": "git"
},
{
"status": "affected",
"version": "1861904a6092ed411203c6a02c75bfc45b27cc3c",
"versionType": "git"
},
{
"status": "affected",
"version": "3a2675a2d97a68332fa5c33043038bfeb31455a8",
"versionType": "git"
},
{
"status": "affected",
"version": "b0add6db3d5ec4561cab257358871a9d3df7f0a3",
"versionType": "git"
},
{
"lessThan": "4.15",
"status": "affected",
"version": "4.14.154",
"versionType": "semver"
},
{
"lessThan": "4.20",
"status": "affected",
"version": "4.19.84",
"versionType": "semver"
},
{
"lessThan": "5.4",
"status": "affected",
"version": "5.3.11",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/macsec.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.4"
},
{
"lessThan": "5.4",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.17.*",
"status": "unaffected",
"version": "5.17.15",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.18.*",
"status": "unaffected",
"version": "5.18.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "344FEFB4-E393-4E04-905A-4734AC267EC1",
"versionEndExcluding": "4.15",
"versionStartIncluding": "4.14.154",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B7EACEB9-7173-47F4-83A4-AE06CE74D78B",
"versionEndExcluding": "4.20",
"versionStartIncluding": "4.19.84",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "ADA13345-8170-4521-B0CB-44DDF2C0713F",
"versionEndExcluding": "5.17.15",
"versionStartIncluding": "5.3.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8E122216-2E9E-4B3E-B7B8-D575A45BA3C2",
"versionEndExcluding": "5.18.3",
"versionStartIncluding": "5.18",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\")\nand commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: macsec: se corrige el error UAF para real_dev Crea un nuevo dispositivo macsec pero no obtiene la referencia a real_dev. Esto no puede garantizar que real_dev se libere despu\u00e9s de macsec. Esto activar\u00e1 el error UAF para real_dev de la siguiente manera: ==================================================================== ERROR: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161 Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748 Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327 After commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\") and commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem. "
}
],
"id": "CVE-2022-49390",
"lastModified": "2026-06-17T05:17:54.840",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2022-49390",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-27T17:58:33.560218Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-02-26T07:01:15.620",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/196a888ca6571deb344468e1d7138e3273206335"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/78933cbc143b82d02330e00900d2fd08f2682f4e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d130282179aa6051449ac8f8df1115769998a665"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-416"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-29T21:06:00+00:00",
"cve": "CVE-2022-49390",
"id": "CVE-2022-49390",
"initial_release_date": "2022-01-01T00:00:00+00:00",
"product_status:known_affected": "184",
"product_status:known_not_affected": "90",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: macsec: fix UAF bug for real_dev",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2022/cve-2022-49390.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2022-49390",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-27T17:58:33.560218Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-416",
"description": "CWE-416 Use After Free",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-02-27T17:58:35.320Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/macsec.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "78933cbc143b82d02330e00900d2fd08f2682f4e",
"status": "affected",
"version": "2bce1ebed17da54c65042ec2b962e3234bad5b47",
"versionType": "git"
},
{
"lessThan": "d130282179aa6051449ac8f8df1115769998a665",
"status": "affected",
"version": "2bce1ebed17da54c65042ec2b962e3234bad5b47",
"versionType": "git"
},
{
"lessThan": "196a888ca6571deb344468e1d7138e3273206335",
"status": "affected",
"version": "2bce1ebed17da54c65042ec2b962e3234bad5b47",
"versionType": "git"
},
{
"status": "affected",
"version": "1861904a6092ed411203c6a02c75bfc45b27cc3c",
"versionType": "git"
},
{
"status": "affected",
"version": "3a2675a2d97a68332fa5c33043038bfeb31455a8",
"versionType": "git"
},
{
"status": "affected",
"version": "b0add6db3d5ec4561cab257358871a9d3df7f0a3",
"versionType": "git"
},
{
"lessThan": "4.15",
"status": "affected",
"version": "4.14.154",
"versionType": "semver"
},
{
"lessThan": "4.20",
"status": "affected",
"version": "4.19.84",
"versionType": "semver"
},
{
"lessThan": "5.4",
"status": "affected",
"version": "5.3.11",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/macsec.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.4"
},
{
"lessThan": "5.4",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.17.*",
"status": "unaffected",
"version": "5.17.15",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.18.*",
"status": "unaffected",
"version": "5.18.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.17.15",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.18.3",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.19",
"versionStartIncluding": "5.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.14.154",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "4.19.84",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionStartIncluding": "5.3.11",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\")\nand commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-23T15:22:03.515Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/78933cbc143b82d02330e00900d2fd08f2682f4e"
},
{
"url": "https://git.kernel.org/stable/c/d130282179aa6051449ac8f8df1115769998a665"
},
{
"url": "https://git.kernel.org/stable/c/196a888ca6571deb344468e1d7138e3273206335"
}
],
"title": "macsec: fix UAF bug for real_dev",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2022-49390",
"datePublished": "2025-02-26T02:11:23.327Z",
"dateReserved": "2025-02-26T02:08:31.561Z",
"dateUpdated": "2026-05-23T15:22:03.515Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2026-AVI-0106
Vulnerability from certfr_avis - Published: 2026-01-30 - Updated: 2026-01-30
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une élévation de privilèges, une atteinte à la confidentialité des données et un contournement de la politique de sécurité.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 14.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2021-47485",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47485"
},
{
"name": "CVE-2025-22036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22036"
},
{
"name": "CVE-2024-50195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50195"
},
{
"name": "CVE-2024-56606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56606"
},
{
"name": "CVE-2022-48986",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48986"
},
{
"name": "CVE-2024-27078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27078"
},
{
"name": "CVE-2024-56756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56756"
},
{
"name": "CVE-2025-21647",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21647"
},
{
"name": "CVE-2024-49959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49959"
},
{
"name": "CVE-2025-21715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21715"
},
{
"name": "CVE-2024-46827",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46827"
},
{
"name": "CVE-2022-49390",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49390"
},
{
"name": "CVE-2024-57850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57850"
},
{
"name": "CVE-2024-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53197"
},
{
"name": "CVE-2025-21704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21704"
},
{
"name": "CVE-2024-53164",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53164"
},
{
"name": "CVE-2024-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53217"
},
{
"name": "CVE-2022-49026",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49026"
},
{
"name": "CVE-2025-21692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21692"
},
{
"name": "CVE-2025-39993",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39993"
},
{
"name": "CVE-2025-38352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38352"
},
{
"name": "CVE-2024-26689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26689"
},
{
"name": "CVE-2024-50090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50090"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
}
],
"initial_release_date": "2026-01-30T00:00:00",
"last_revision_date": "2026-01-30T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0106",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-01-30T00:00:00.000000"
}
],
"risks": [
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une \u00e9l\u00e9vation de privil\u00e8ges, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et un contournement de la politique de s\u00e9curit\u00e9.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-01-29",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7986-1",
"url": "https://ubuntu.com/security/notices/USN-7986-1"
},
{
"published_at": "2026-01-29",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7987-2",
"url": "https://ubuntu.com/security/notices/USN-7987-2"
},
{
"published_at": "2026-01-29",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7988-1",
"url": "https://ubuntu.com/security/notices/USN-7988-1"
},
{
"published_at": "2026-01-29",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7987-1",
"url": "https://ubuntu.com/security/notices/USN-7987-1"
},
{
"published_at": "2026-01-29",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7988-2",
"url": "https://ubuntu.com/security/notices/USN-7988-2"
},
{
"published_at": "2026-01-29",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu LSN-0117-1",
"url": "https://ubuntu.com/security/notices/LSN-0117-1"
}
]
}
CERTFR-2026-AVI-0112
Vulnerability from certfr_avis - Published: 2026-02-02 - Updated: 2026-02-02
De multiples vulnérabilités ont été découvertes dans les produits VMware. Elles permettent à un attaquant de provoquer un problème de sécurité non spécifié par l'éditeur.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| VMware | Tanzu Platform | Foundation Core pour VMware Tanzu Platform versions antérieures à 3.1.7 | ||
| VMware | Tanzu Kubernetes Grid Integrated Edition | Tanzu Kubernetes Grid Integrated Edition (TKGi) - Mgmt Console versions antérieures à 1.24.0 | ||
| VMware | Tanzu Platform | Isolation Segmentation pour VMware Tanzu Platform versions antérieures à 10.2.7+LTS-T | ||
| VMware | N/A | NodeJS Buildpack versions antérieures à 1.8.74 | ||
| VMware | Tanzu Platform | Foundation Core pour VMware Tanzu Platform versions antérieures à 3.2.3 | ||
| VMware | Tanzu Platform | Telemetry pour VMware Tanzu Platform versions antérieures à 2.4.0 | ||
| VMware | N/A | Platform Automation Toolkit versions antérieures à 5.4.0 | ||
| VMware | N/A | VMware Harbor Registry versions antérieures à 2.14.0 | ||
| VMware | Tanzu Platform | Isolation Segmentation pour VMware Tanzu Platform versions antérieures à 10.3.4 |
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Foundation Core pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 3.1.7",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Kubernetes Grid Integrated Edition (TKGi) - Mgmt Console versions ant\u00e9rieures \u00e0 1.24.0",
"product": {
"name": "Tanzu Kubernetes Grid Integrated Edition",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Isolation Segmentation pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 10.2.7+LTS-T",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "NodeJS Buildpack versions ant\u00e9rieures \u00e0 1.8.74",
"product": {
"name": "N/A",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Foundation Core pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 3.2.3",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Telemetry pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 2.4.0",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Platform Automation Toolkit versions ant\u00e9rieures \u00e0 5.4.0",
"product": {
"name": "N/A",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "VMware Harbor Registry versions ant\u00e9rieures \u00e0 2.14.0",
"product": {
"name": "N/A",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Isolation Segmentation pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 10.3.4",
"product": {
"name": "Tanzu Platform",
"vendor": {
"name": "VMware",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2025-8715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8715"
},
{
"name": "CVE-2025-53547",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53547"
},
{
"name": "CVE-2025-58183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58183"
},
{
"name": "CVE-2025-9231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9231"
},
{
"name": "CVE-2025-68973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68973"
},
{
"name": "CVE-2025-10148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10148"
},
{
"name": "CVE-2025-14087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14087"
},
{
"name": "CVE-2025-22872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22872"
},
{
"name": "CVE-2025-28164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-28164"
},
{
"name": "CVE-2025-0913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0913"
},
{
"name": "CVE-2025-47907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47907"
},
{
"name": "CVE-2026-24882",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24882"
},
{
"name": "CVE-2023-45288",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45288"
},
{
"name": "CVE-2025-6075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6075"
},
{
"name": "CVE-2025-22228",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22228"
},
{
"name": "CVE-2025-58185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58185"
},
{
"name": "CVE-2025-55752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55752"
},
{
"name": "CVE-2025-58767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58767"
},
{
"name": "CVE-2024-38819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38819"
},
{
"name": "CVE-2025-55198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55198"
},
{
"name": "CVE-2025-15284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15284"
},
{
"name": "CVE-2026-1485",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1485"
},
{
"name": "CVE-2022-49390",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49390"
},
{
"name": "CVE-2025-48060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48060"
},
{
"name": "CVE-2025-21855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21855"
},
{
"name": "CVE-2024-21510",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21510"
},
{
"name": "CVE-2025-14512",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14512"
},
{
"name": "CVE-2025-8291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8291"
},
{
"name": "CVE-2025-61921",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61921"
},
{
"name": "CVE-2023-34231",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34231"
},
{
"name": "CVE-2025-61727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61727"
},
{
"name": "CVE-2025-64718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64718"
},
{
"name": "CVE-2024-28180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28180"
},
{
"name": "CVE-2025-65637",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-65637"
},
{
"name": "CVE-2025-22233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22233"
},
{
"name": "CVE-2025-47910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47910"
},
{
"name": "CVE-2024-38820",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38820"
},
{
"name": "CVE-2025-10966",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10966"
},
{
"name": "CVE-2025-47906",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47906"
},
{
"name": "CVE-2025-31133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31133"
},
{
"name": "CVE-2025-64505",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64505"
},
{
"name": "CVE-2025-58188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58188"
},
{
"name": "CVE-2025-4674",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4674"
},
{
"name": "CVE-2022-29526",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29526"
},
{
"name": "CVE-2025-65945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-65945"
},
{
"name": "CVE-2025-28162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-28162"
},
{
"name": "CVE-2025-55754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55754"
},
{
"name": "CVE-2025-64506",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64506"
},
{
"name": "CVE-2025-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52881"
},
{
"name": "CVE-2025-22868",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22868"
},
{
"name": "CVE-2025-3360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3360"
},
{
"name": "CVE-2025-64720",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64720"
},
{
"name": "CVE-2025-61724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61724"
},
{
"name": "CVE-2025-61723",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61723"
},
{
"name": "CVE-2025-9232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9232"
},
{
"name": "CVE-2025-61795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61795"
},
{
"name": "CVE-2025-14762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14762"
},
{
"name": "CVE-2025-8713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8713"
},
{
"name": "CVE-2025-66471",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66471"
},
{
"name": "CVE-2026-21441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21441"
},
{
"name": "CVE-2024-45337",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45337"
},
{
"name": "CVE-2024-53427",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53427"
},
{
"name": "CVE-2025-61725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61725"
},
{
"name": "CVE-2025-65018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-65018"
},
{
"name": "CVE-2025-7039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7039"
},
{
"name": "CVE-2025-12818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12818"
},
{
"name": "CVE-2025-48989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48989"
},
{
"name": "CVE-2026-24842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24842"
},
{
"name": "CVE-2025-22874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22874"
},
{
"name": "CVE-2025-55199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55199"
},
{
"name": "CVE-2025-61594",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61594"
},
{
"name": "CVE-2025-47912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47912"
},
{
"name": "CVE-2025-11414",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11414"
},
{
"name": "CVE-2025-54410",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54410"
},
{
"name": "CVE-2025-52565",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52565"
},
{
"name": "CVE-2026-24883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24883"
},
{
"name": "CVE-2025-39964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39964"
},
{
"name": "CVE-2025-39993",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39993"
},
{
"name": "CVE-2025-58186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58186"
},
{
"name": "CVE-2025-8714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8714"
},
{
"name": "CVE-2025-9086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9086"
},
{
"name": "CVE-2025-58187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58187"
},
{
"name": "CVE-2025-13601",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13601"
},
{
"name": "CVE-2025-12817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12817"
},
{
"name": "CVE-2025-4673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4673"
},
{
"name": "CVE-2025-22871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22871"
},
{
"name": "CVE-2024-38828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38828"
},
{
"name": "CVE-2025-6966",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6966"
},
{
"name": "CVE-2025-58181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58181"
},
{
"name": "CVE-2025-8959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8959"
},
{
"name": "CVE-2025-47914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47914"
},
{
"name": "CVE-2025-40018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40018"
},
{
"name": "CVE-2024-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53218"
},
{
"name": "CVE-2025-67499",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-67499"
},
{
"name": "CVE-2025-58058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58058"
},
{
"name": "CVE-2025-22869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22869"
},
{
"name": "CVE-2025-58189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58189"
},
{
"name": "CVE-2025-22870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22870"
},
{
"name": "CVE-2025-11413",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11413"
},
{
"name": "CVE-2024-23337",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23337"
},
{
"name": "CVE-2025-61748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61748"
},
{
"name": "CVE-2025-22235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22235"
},
{
"name": "CVE-2025-9230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9230"
},
{
"name": "CVE-2025-7339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7339"
},
{
"name": "CVE-2024-53090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53090"
},
{
"name": "CVE-2025-8916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8916"
},
{
"name": "CVE-2025-23419",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23419"
},
{
"name": "CVE-2025-8885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8885"
},
{
"name": "CVE-2025-41249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41249"
},
{
"name": "CVE-2025-11412",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11412"
},
{
"name": "CVE-2026-1484",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1484"
},
{
"name": "CVE-2025-7424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7424"
},
{
"name": "CVE-2024-50067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50067"
},
{
"name": "CVE-2024-47220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47220"
},
{
"name": "CVE-2025-54388",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54388"
},
{
"name": "CVE-2026-1489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1489"
},
{
"name": "CVE-2026-24881",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24881"
},
{
"name": "CVE-2025-41242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41242"
},
{
"name": "CVE-2024-38816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38816"
},
{
"name": "CVE-2025-53057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53057"
},
{
"name": "CVE-2025-6442",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6442"
},
{
"name": "CVE-2025-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53066"
},
{
"name": "CVE-2016-1000027",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000027"
},
{
"name": "CVE-2025-61729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61729"
},
{
"name": "CVE-2025-11494",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11494"
},
{
"name": "CVE-2024-47691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47691"
},
{
"name": "CVE-2025-66418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66418"
}
],
"initial_release_date": "2026-02-02T00:00:00",
"last_revision_date": "2026-02-02T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0112",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-02-02T00:00:00.000000"
}
],
"risks": [
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits VMware. Elles permettent \u00e0 un attaquant de provoquer un probl\u00e8me de s\u00e9curit\u00e9 non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits VMware",
"vendor_advisories": [
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36902",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36902"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36908",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36908"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36897",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36897"
},
{
"published_at": "2026-02-01",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36912",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36912"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36904",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36904"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36900",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36900"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36903",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36903"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36909",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36909"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36899",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36899"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36906",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36906"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36907",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36907"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36901",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36901"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36905",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36905"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36898",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36898"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36910",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36910"
},
{
"published_at": "2026-02-02",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36911",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36911"
}
]
}
厂商已发布了漏洞修复程序,请及时关注更新: https://git.kernel.org/stable/c/196a888ca6571deb344468e1d7138e3273206335
| Name | Linux Kernel |
|---|
{
"cves": {
"cve": {
"cveNumber": "CVE-2022-49390",
"cveUrl": "https://nvd.nist.gov/vuln/detail/CVE-2022-49390"
}
},
"description": "Linux kernel\u662f\u7f8e\u56fdLinux\u57fa\u91d1\u4f1a\u7684\u5f00\u6e90\u64cd\u4f5c\u7cfb\u7edfLinux\u6240\u4f7f\u7528\u7684\u5185\u6838\u3002\n\nLinux kernel\u5b58\u5728\u5185\u5b58\u9519\u8bef\u5f15\u7528\u6f0f\u6d1e\uff0c\u8be5\u6f0f\u6d1e\u6e90\u4e8emacsec\u8bbe\u5907\u672a\u83b7\u53d6real_dev\u7684\u5f15\u7528\uff0c\u653b\u51fb\u8005\u53ef\u5229\u7528\u8be5\u6f0f\u6d1e\u5bfc\u81f4\u91ca\u653e\u540e\u91cd\u7528\u3002",
"formalWay": "\u5382\u5546\u5df2\u53d1\u5e03\u4e86\u6f0f\u6d1e\u4fee\u590d\u7a0b\u5e8f\uff0c\u8bf7\u53ca\u65f6\u5173\u6ce8\u66f4\u65b0\uff1a\r\nhttps://git.kernel.org/stable/c/196a888ca6571deb344468e1d7138e3273206335",
"isEvent": "\u901a\u7528\u8f6f\u786c\u4ef6\u6f0f\u6d1e",
"number": "CNVD-2025-04679",
"openTime": "2025-03-10",
"patchDescription": "Linux kernel\u662f\u7f8e\u56fdLinux\u57fa\u91d1\u4f1a\u7684\u5f00\u6e90\u64cd\u4f5c\u7cfb\u7edfLinux\u6240\u4f7f\u7528\u7684\u5185\u6838\u3002\r\n\r\nLinux kernel\u5b58\u5728\u5185\u5b58\u9519\u8bef\u5f15\u7528\u6f0f\u6d1e\uff0c\u8be5\u6f0f\u6d1e\u6e90\u4e8emacsec\u8bbe\u5907\u672a\u83b7\u53d6real_dev\u7684\u5f15\u7528\uff0c\u653b\u51fb\u8005\u53ef\u5229\u7528\u8be5\u6f0f\u6d1e\u5bfc\u81f4\u91ca\u653e\u540e\u91cd\u7528\u3002\u76ee\u524d\uff0c\u4f9b\u5e94\u5546\u53d1\u5e03\u4e86\u5b89\u5168\u516c\u544a\u53ca\u76f8\u5173\u8865\u4e01\u4fe1\u606f\uff0c\u4fee\u590d\u4e86\u6b64\u6f0f\u6d1e\u3002",
"patchName": "Linux kernel macsec\u5185\u5b58\u9519\u8bef\u5f15\u7528\u6f0f\u6d1e\u7684\u8865\u4e01",
"products": {
"product": "Linux Kernel"
},
"referenceLink": "https://nvd.nist.gov/vuln/detail/CVE-2022-49390",
"serverity": "\u4e2d",
"submitTime": "2025-03-05",
"title": "Linux kernel macsec\u5185\u5b58\u9519\u8bef\u5f15\u7528\u6f0f\u6d1e"
}
FKIE_CVE-2022-49390
Vulnerability from fkie_nvd - Published: 2025-02-26 07:01 - Updated: 2026-06-17 05:17| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/196a888ca6571deb344468e1d7138e3273206335 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/78933cbc143b82d02330e00900d2fd08f2682f4e | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/d130282179aa6051449ac8f8df1115769998a665 | Patch |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/macsec.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "78933cbc143b82d02330e00900d2fd08f2682f4e",
"status": "affected",
"version": "2bce1ebed17da54c65042ec2b962e3234bad5b47",
"versionType": "git"
},
{
"lessThan": "d130282179aa6051449ac8f8df1115769998a665",
"status": "affected",
"version": "2bce1ebed17da54c65042ec2b962e3234bad5b47",
"versionType": "git"
},
{
"lessThan": "196a888ca6571deb344468e1d7138e3273206335",
"status": "affected",
"version": "2bce1ebed17da54c65042ec2b962e3234bad5b47",
"versionType": "git"
},
{
"status": "affected",
"version": "1861904a6092ed411203c6a02c75bfc45b27cc3c",
"versionType": "git"
},
{
"status": "affected",
"version": "3a2675a2d97a68332fa5c33043038bfeb31455a8",
"versionType": "git"
},
{
"status": "affected",
"version": "b0add6db3d5ec4561cab257358871a9d3df7f0a3",
"versionType": "git"
},
{
"lessThan": "4.15",
"status": "affected",
"version": "4.14.154",
"versionType": "semver"
},
{
"lessThan": "4.20",
"status": "affected",
"version": "4.19.84",
"versionType": "semver"
},
{
"lessThan": "5.4",
"status": "affected",
"version": "5.3.11",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/macsec.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.4"
},
{
"lessThan": "5.4",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.17.*",
"status": "unaffected",
"version": "5.17.15",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.18.*",
"status": "unaffected",
"version": "5.18.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "5.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "344FEFB4-E393-4E04-905A-4734AC267EC1",
"versionEndExcluding": "4.15",
"versionStartIncluding": "4.14.154",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B7EACEB9-7173-47F4-83A4-AE06CE74D78B",
"versionEndExcluding": "4.20",
"versionStartIncluding": "4.19.84",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "ADA13345-8170-4521-B0CB-44DDF2C0713F",
"versionEndExcluding": "5.17.15",
"versionStartIncluding": "5.3.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8E122216-2E9E-4B3E-B7B8-D575A45BA3C2",
"versionEndExcluding": "5.18.3",
"versionStartIncluding": "5.18",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\")\nand commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: macsec: se corrige el error UAF para real_dev Crea un nuevo dispositivo macsec pero no obtiene la referencia a real_dev. Esto no puede garantizar que real_dev se libere despu\u00e9s de macsec. Esto activar\u00e1 el error UAF para real_dev de la siguiente manera: ==================================================================== ERROR: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161 Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748 Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327 After commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\") and commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem. "
}
],
"id": "CVE-2022-49390",
"lastModified": "2026-06-17T05:17:54.840",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2022-49390",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-02-27T17:58:33.560218Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-02-26T07:01:15.620",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/196a888ca6571deb344468e1d7138e3273206335"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/78933cbc143b82d02330e00900d2fd08f2682f4e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d130282179aa6051449ac8f8df1115769998a665"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-416"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
GHSA-W9JF-HMJ5-FP54
Vulnerability from github – Published: 2025-02-27 18:31 – Updated: 2025-02-27 18:31In the Linux kernel, the following vulnerability has been resolved:
macsec: fix UAF bug for real_dev
Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following:
================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161
Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748
Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327
After commit faab39f63c1f ("net: allow out-of-order netdev unregistration") and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.
{
"affected": [],
"aliases": [
"CVE-2022-49390"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:15Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\")\nand commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem.",
"id": "GHSA-w9jf-hmj5-fp54",
"modified": "2025-02-27T18:31:08Z",
"published": "2025-02-27T18:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49390"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/196a888ca6571deb344468e1d7138e3273206335"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/78933cbc143b82d02330e00900d2fd08f2682f4e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d130282179aa6051449ac8f8df1115769998a665"
}
],
"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"
}
]
}
MSRC_CVE-2022-49390
Vulnerability from csaf_microsoft - Published: 2025-02-02 00:00 - Updated: 2026-02-18 01:14OESA-2025-1408 (CVE-2022-49059)
Vulnerability from osv_openeuler – Published: 2025-04-11 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: add flush_workqueue to prevent uaf
Our detector found a concurrent use-after-free bug when detaching an NCI device. The main reason for this bug is the unexpected scheduling between the used delayed mechanism (timer and workqueue).
The race can be demonstrated below:
Thread-1 Thread-2 | nci_dev_up() | nci_open_device() | __nci_request(nci_reset_req) | nci_send_cmd | queue_work(cmd_work) nci_unregister_device() | nci_close_device() | ... del_timer_sync(cmd_timer)[1] | ... | Worker nci_free_device() | nci_cmd_work() kfree(ndev)[3] | mod_timer(cmd_timer)[2]
In short, the cleanup routine thought that the cmd_timer has already been detached by [1] but the mod_timer can re-attach the timer [2], even it is already released [3], resulting in UAF.
This UAF is easy to trigger, crash trace by POC is like below
[ 66.703713] ================================================================== [ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490 [ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33 [ 66.703974] [ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5 [ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work [ 66.703974] Call Trace: [ 66.703974] <TASK> [ 66.703974] dump_stack_lvl+0x57/0x7d [ 66.703974] print_report.cold+0x5e/0x5db [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] kasan_report+0xbe/0x1c0 [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] enqueue_timer+0x448/0x490 [ 66.703974] __mod_timer+0x5e6/0xb80 [ 66.703974] ? mark_held_locks+0x9e/0xe0 [ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410 [ 66.703974] ? queue_work_on+0x61/0x80 [ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130 [ 66.703974] process_one_work+0x8bb/0x1510 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230 [ 66.703974] ? rwlock_bug.part.0+0x90/0x90 [ 66.703974] ? _raw_spin_lock_irq+0x41/0x50 [ 66.703974] worker_thread+0x575/0x1190 [ 66.703974] ? process_one_work+0x1510/0x1510 [ 66.703974] kthread+0x2a0/0x340 [ 66.703974] ? kthread_complete_and_exit+0x20/0x20 [ 66.703974] ret_from_fork+0x22/0x30 [ 66.703974] </TASK> [ 66.703974] [ 66.703974] Allocated by task 267: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] __kasan_kmalloc+0x81/0xa0 [ 66.703974] nci_allocate_device+0xd3/0x390 [ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0 [ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd [ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0 [ 66.703974] tty_ioctl+0x764/0x1310 [ 66.703974] __x64_sys_ioctl+0x122/0x190 [ 66.703974] do_syscall_64+0x3b/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 66.703974] [ 66.703974] Freed by task 406: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] kasan_set_track+0x21/0x30 [ 66.703974] kasan_set_free_info+0x20/0x30 [ 66.703974] __kasan_slab_free+0x108/0x170 [ 66.703974] kfree+0xb0/0x330 [ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0 [ 66.703974] nci_uart_tty_close+0xdf/0x180 [ 66.703974] tty_ldisc_kill+0x73/0x110 [ 66.703974] tty_ldisc_hangup+0x281/0x5b0 [ 66.703974] __tty_hangup.part.0+0x431/0x890 [ 66.703974] tty_release+0x3a8/0xc80 [ 66.703974] __fput+0x1f0/0x8c0 [ 66.703974] task_work_run+0xc9/0x170 [ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0 [ 66.703974] syscall_exit_to_user_mode+0x19/0x50 [ 66.703974] do_syscall_64+0x48/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x ---truncated---(CVE-2022-49059)
In the Linux kernel, the following vulnerability has been resolved:
drbd: Fix five use after free bugs in get_initial_state
In get_initial_state, it calls notify_initial_state_done(skb,..) if cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(), the skb will be freed by nlmsg_free(skb). Then get_initial_state will goto out and the freed skb will be used by return value skb->len, which is a uaf bug.
What's worse, the same problem goes even further: skb can also be freed in the notify_state_change -> notify_state calls below. Thus 4 additional uaf bugs happened.
My patch lets the problem callee functions: notify_initial_state_done and notify_*_state_change return an error code if errors happen. So that the error codes could be propagated and the uaf bugs can be avoid.
v2 reports a compilation warning. This v3 fixed this warning and built successfully in my local environment with no additional warnings. v2: https://lore.kernel.org/patchwork/patch/1435218/(CVE-2022-49085)
In the Linux kernel, the following vulnerability has been resolved:
virtio_console: eliminate anonymous module_init & module_exit
Eliminate anonymous module_init() and module_exit(), which can lead to confusion or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log.
Give each of these init and exit functions unique driver-specific names to eliminate the anonymous names.
Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init
Example 2: (initcall_debug log) calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1 initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned 0 after 74 usecs(CVE-2022-49100)
In the Linux kernel, the following vulnerability has been resolved:
drivers: usb: host: Fix deadlock in oxu_bus_suspend()
There is a deadlock in oxu_bus_suspend(), which is shown below:
(Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ...
We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever.
This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock.(CVE-2022-49313)
In the Linux kernel, the following vulnerability has been resolved:
firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle
kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add()
If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object.
Fix this issue by calling kobject_put().(CVE-2022-49370)
In the Linux kernel, the following vulnerability has been resolved:
tipc: check attribute length for bearer name
syzbot reported uninit-value:
BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline] BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:644 [inline] string+0x4f9/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50 _printk+0x18d/0x1cf kernel/printk/printk.c:2293 tipc_enable_bearer net/tipc/bearer.c:371 [inline] __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]
- Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.
- Do not use 'illegal name' in printing message.(CVE-2022-49374)
In the Linux kernel, the following vulnerability has been resolved:
usb: usbip: fix a refcount leak in stub_probe()
usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails after that, usb_put_dev() needs to be called to release the reference.
Fix this by moving usb_put_dev() to sdev_free error path handling.
Find this by code review.(CVE-2022-49389)
In the Linux kernel, the following vulnerability has been resolved:
macsec: fix UAF bug for real_dev
Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following:
================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161
Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748
Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327
After commit faab39f63c1f ("net: allow out-of-order netdev unregistration") and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.(CVE-2022-49390)
In the Linux kernel, the following vulnerability has been resolved:
phy: qcom-qmp: fix reset-controller leak on probe errors
Make sure to release the lane reset controller in case of a late probe error (e.g. probe deferral).
Note that due to the reset controller being defined in devicetree in "lane" child nodes, devm_reset_control_get_exclusive() cannot be used directly.(CVE-2022-49396)
In the Linux kernel, the following vulnerability has been resolved:
tty: fix deadlock caused by calling printk() under tty_port->lock
pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below:
CPU0 CPU1 CPU2
---- ---- ----
lock(console_owner);
lock(&port_lock_key);
lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner);
As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant.
Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided.
Syzbot reported the following lockdep error:
====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted
syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023
but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...]
-> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
-> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated---(CVE-2022-49441)
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix listen() setting the bar too high for the prealloc rings
AF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bump up the sysctl), but whilst the preallocation circular buffers have 32 slots in them, one of them has to be a dead slot because we're using CIRC_CNT().
This means that listen(rxrpc_sock, 32) will cause an oops when the socket is closed because rxrpc_service_prealloc_one() allocated one too many calls and rxrpc_discard_prealloc() won't then be able to get rid of them because it'll think the ring is empty. rxrpc_release_calls_on_socket() then tries to abort them, but oopses because call->peer isn't yet set.
Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match the ring capacity.
BUG: kernel NULL pointer dereference, address: 0000000000000086 ... RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc] Call Trace: <TASK> ? __wake_up_common_lock+0x7a/0x90 ? rxrpc_notify_socket+0x8e/0x140 [rxrpc] ? rxrpc_abort_call+0x4c/0x60 [rxrpc] rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc] rxrpc_release+0xc9/0x1c0 [rxrpc] __sock_release+0x37/0xa0 sock_close+0x11/0x20 __fput+0x89/0x240 task_work_run+0x59/0x90 do_exit+0x319/0xaa0(CVE-2022-49450)
In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix list protocols enumeration in the base protocol
While enumerating protocols implemented by the SCMI platform using BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is currently validated in an improper way since the check employs a sum between unsigned integers that could overflow and cause the check itself to be silently bypassed if the returned value 'loop_num_ret' is big enough.
Fix the validation avoiding the addition.(CVE-2022-49451)
In the Linux kernel, the following vulnerability has been resolved:
drm: msm: fix possible memory leak in mdp5_crtc_cursor_set()
drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo needs to be put when msm_gem_get_and_pin_iova fails.(CVE-2022-49467)
In the Linux kernel, the following vulnerability has been resolved:
regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt
of_node_get() returns a node with refcount incremented. Calling of_node_put() to drop the reference when not needed anymore.(CVE-2022-49481)
In the Linux kernel, the following vulnerability has been resolved:
drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()
It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref.(CVE-2022-49491)
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: pmac32-cpufreq: Fix refcount leak bug
In pmac_cpufreq_init_MacRISC3(), we need to add corresponding of_node_put() for the three node pointers whose refcount have been incremented by of_find_node_by_name().(CVE-2022-49621)
In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()
In fsl_mc_bus_remove(), mc->root_mc_bus_dev->mc_io is passed to fsl_destroy_mc_io(). However, mc->root_mc_bus_dev is already freed in fsl_mc_device_remove(). Then reference to mc->root_mc_bus_dev->mc_io triggers KASAN use-after-free. To avoid the use-after-free, keep the reference to mc->root_mc_bus_dev->mc_io in a local variable and pass to fsl_destroy_mc_io().
This patch needs rework to apply to kernels older than v5.15.(CVE-2022-49711)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init
If the function sdma_load_context() fails, the sdma_desc will be freed, but the allocated desc->bd is forgot to be freed.
We already met the sdma_load_context() failure case and the log as below: [ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready ...
In this case, the desc->bd will not be freed without this change.(CVE-2022-49746)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: Fix double increment of client_count in dma_chan_get()
The first time dma_chan_get() is called for a channel the channel client_count is incorrectly incremented twice for public channels, first in balance_ref_count(), and again prior to returning. This results in an incorrect client count which will lead to the channel resources not being freed when they should be. A simple test of repeated module load and unload of async_tx on a Dell Power Edge R7425 also shows this resulting in a kref underflow warning.
[ 124.329662] async_tx: api initialized (async) [ 129.000627] async_tx: api initialized (async) [ 130.047839] ------------[ cut here ]------------ [ 130.052472] refcount_t: underflow; use-after-free. [ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [ 130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash dm_log dm_mod [last unloaded: async_tx] [ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not tainted 5.14.0-185.el9.x86_64 #1 [ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.18.0 01/17/2022 [ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110 [ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d 26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff 48 c7 [ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286 [ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000 [ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0 [ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff [ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970 [ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000) knlGS:0000000000000000 [ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0 [ 130.219729] Call Trace: [ 130.222192] <TASK> [ 130.224305] dma_chan_put+0x10d/0x110 [ 130.227988] dmaengine_put+0x7a/0xa0 [ 130.231575] __do_sys_delete_module.constprop.0+0x178/0x280 [ 130.237157] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [ 130.242652] do_syscall_64+0x5c/0x90 [ 130.246240] ? exc_page_fault+0x62/0x150 [ 130.250178] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 130.255243] RIP: 0033:0x7f6463a3f5ab [ 130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48 [ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab [ 130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8 [ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000 [ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8 [ 130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8 [ 130.320875] </TASK> [ 130.323081] ---[ end trace eff7156d56b5cf25 ]---
cat /sys/class/dma/dma0chan*/in_use would get the wrong result. 2 2 2
Test-by: Jie Hai <haijie1@huawei.com>(CVE-2022-49753)
In the Linux kernel, the following vulnerability has been resolved:
EDAC/highbank: Fix memory leak in highbank_mc_probe()
When devres_open_group() fails, it returns -ENOMEM without freeing memory allocated by edac_mc_alloc().
Call edac_mc_free() on the error handling path to avoid a memory leak.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path()
snd_hda_get_connections() can return a negative error code. It may lead to accessing 'conn' array at a negative index.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52988)
In the Linux kernel, the following vulnerability has been resolved:
HID: betop: check shape of output reports
betopff_init() only checks the total sum of the report counts for each report field to be at least 4, but hid_betopff_play() expects 4 report fields. A device advertising an output report with one field and 4 report counts would pass the check but crash the kernel with a NULL pointer dereference in hid_betopff_play().(CVE-2023-53015)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation
To mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to insufficient speculative store bypass mitigation") inserts lfence instructions after 1) initializing a stack slot and 2) spilling a pointer to the stack.
However, this does not cover cases where a stack slot is first initialized with a pointer (subject to sanitization) but then overwritten with a scalar (not subject to sanitization because the slot was already initialized). In this case, the second write may be subject to speculative store bypass (SSB) creating a speculative pointer-as-scalar type confusion. This allows the program to subsequently leak the numerical pointer value using, for example, a branch-based cache side channel.
To fix this, also sanitize scalars if they write a stack slot that previously contained a pointer. Assuming that pointer-spills are only generated by LLVM on register-pressure, the performance impact on most real-world BPF programs should be small.
The following unprivileged BPF bytecode drafts a minimal exploit and the mitigation:
[...] // r6 = 0 or 1 (skalar, unknown user input) // r7 = accessible ptr for side channel // r10 = frame pointer (fp), to be leaked // r9 = r10 # fp alias to encourage ssb (u64 )(r9 - 8) = r10 // fp[-8] = ptr, to be leaked // lfence added here because of pointer spill to stack. // // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor // for no r9-r10 dependency. // (u64 )(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID, // store may be subject to SSB // // fix: also add an lfence when the slot contained a ptr // r8 = (u64 )(r9 - 8) // r8 = architecturally a scalar, speculatively a ptr // // leak ptr using branch-based cache side channel: r8 &= 1 // choose bit to leak if r8 == 0 goto SLOW // no mispredict // architecturally dead code if input r6 is 0, // only executes speculatively iff ptr bit is 1 r8 = (u64 )(r7 + 0) # encode bit in cache (0: slow, 1: fast) SLOW: [...]
After running this, the program can time the access to *(r7 + 0) to determine whether the chosen pointer bit was 0 or 1. Repeat this 64 times to recover the whole address on amd64.
In summary, sanitization can only be skipped if one scalar is overwritten with another scalar. Scalar-confusion due to speculative store bypass can not lead to invalid accesses because the pointer bounds deducted during verification are enforced using branchless logic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic") for details.
Do not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks} because speculative leaks are likely unexpected if these were enabled. For example, leaking the address to a protected log file may be acceptable while disabling the mitigation might unintentionally leak the address into the cached-state of a map that is accessible to unprivileged processes.(CVE-2023-53024)
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Fix double free in error path
If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it.
Reviewed by: Ricardo Ribalda <ribalda@chromium.org>(CVE-2024-57980)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: sch_sfq: don't allow 1 packet limit
The current implementation does not work correctly with a limit of 1. iproute2 actually checks for this and this patch adds the check in kernel as well.
This fixes the following syzkaller reported crash:
UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270
The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1):
tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1
Scenario that triggers the crash:
-
the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1
-
TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later.
-
the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL.
At this point, assuming no more packets are queued, when sch_dequeue runs again it will decrement the qlen for the current empty slot causing an underflow and the subsequent out of bounds access.(CVE-2024-57996)
In the Linux kernel, the following vulnerability has been resolved:
partitions: mac: fix handling of bogus partition table
Fix several issues in partition probing:
- The bailout for a bad partoffset must use put_dev_sector(), since the preceding read_part_sector() succeeded.
- If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory.
- We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2504.2.0.0323.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2504.2.0.0323.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2504.2.0.0323.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfc: nci: add flush_workqueue to prevent uaf\n\nOur detector found a concurrent use-after-free bug when detaching an\nNCI device. The main reason for this bug is the unexpected scheduling\nbetween the used delayed mechanism (timer and workqueue).\n\nThe race can be demonstrated below:\n\nThread-1 Thread-2\n | nci_dev_up()\n | nci_open_device()\n | __nci_request(nci_reset_req)\n | nci_send_cmd\n | queue_work(cmd_work)\nnci_unregister_device() |\n nci_close_device() | ...\n del_timer_sync(cmd_timer)[1] |\n... | Worker\nnci_free_device() | nci_cmd_work()\n kfree(ndev)[3] | mod_timer(cmd_timer)[2]\n\nIn short, the cleanup routine thought that the cmd_timer has already\nbeen detached by [1] but the mod_timer can re-attach the timer [2], even\nit is already released [3], resulting in UAF.\n\nThis UAF is easy to trigger, crash trace by POC is like below\n\n[ 66.703713] ==================================================================\n[ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490\n[ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33\n[ 66.703974]\n[ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5\n[ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work\n[ 66.703974] Call Trace:\n[ 66.703974] \u0026lt;TASK\u0026gt;\n[ 66.703974] dump_stack_lvl+0x57/0x7d\n[ 66.703974] print_report.cold+0x5e/0x5db\n[ 66.703974] ? enqueue_timer+0x448/0x490\n[ 66.703974] kasan_report+0xbe/0x1c0\n[ 66.703974] ? enqueue_timer+0x448/0x490\n[ 66.703974] enqueue_timer+0x448/0x490\n[ 66.703974] __mod_timer+0x5e6/0xb80\n[ 66.703974] ? mark_held_locks+0x9e/0xe0\n[ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0\n[ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410\n[ 66.703974] ? queue_work_on+0x61/0x80\n[ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130\n[ 66.703974] process_one_work+0x8bb/0x1510\n[ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410\n[ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230\n[ 66.703974] ? rwlock_bug.part.0+0x90/0x90\n[ 66.703974] ? _raw_spin_lock_irq+0x41/0x50\n[ 66.703974] worker_thread+0x575/0x1190\n[ 66.703974] ? process_one_work+0x1510/0x1510\n[ 66.703974] kthread+0x2a0/0x340\n[ 66.703974] ? kthread_complete_and_exit+0x20/0x20\n[ 66.703974] ret_from_fork+0x22/0x30\n[ 66.703974] \u0026lt;/TASK\u0026gt;\n[ 66.703974]\n[ 66.703974] Allocated by task 267:\n[ 66.703974] kasan_save_stack+0x1e/0x40\n[ 66.703974] __kasan_kmalloc+0x81/0xa0\n[ 66.703974] nci_allocate_device+0xd3/0x390\n[ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0\n[ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd\n[ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0\n[ 66.703974] tty_ioctl+0x764/0x1310\n[ 66.703974] __x64_sys_ioctl+0x122/0x190\n[ 66.703974] do_syscall_64+0x3b/0x90\n[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae\n[ 66.703974]\n[ 66.703974] Freed by task 406:\n[ 66.703974] kasan_save_stack+0x1e/0x40\n[ 66.703974] kasan_set_track+0x21/0x30\n[ 66.703974] kasan_set_free_info+0x20/0x30\n[ 66.703974] __kasan_slab_free+0x108/0x170\n[ 66.703974] kfree+0xb0/0x330\n[ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0\n[ 66.703974] nci_uart_tty_close+0xdf/0x180\n[ 66.703974] tty_ldisc_kill+0x73/0x110\n[ 66.703974] tty_ldisc_hangup+0x281/0x5b0\n[ 66.703974] __tty_hangup.part.0+0x431/0x890\n[ 66.703974] tty_release+0x3a8/0xc80\n[ 66.703974] __fput+0x1f0/0x8c0\n[ 66.703974] task_work_run+0xc9/0x170\n[ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0\n[ 66.703974] syscall_exit_to_user_mode+0x19/0x50\n[ 66.703974] do_syscall_64+0x48/0x90\n[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x\n---truncated---(CVE-2022-49059)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrbd: Fix five use after free bugs in get_initial_state\n\nIn get_initial_state, it calls notify_initial_state_done(skb,..) if\ncb-\u0026gt;args[5]==1. If genlmsg_put() failed in notify_initial_state_done(),\nthe skb will be freed by nlmsg_free(skb).\nThen get_initial_state will goto out and the freed skb will be used by\nreturn value skb-\u0026gt;len, which is a uaf bug.\n\nWhat\u0026apos;s worse, the same problem goes even further: skb can also be\nfreed in the notify_*_state_change -\u0026gt; notify_*_state calls below.\nThus 4 additional uaf bugs happened.\n\nMy patch lets the problem callee functions: notify_initial_state_done\nand notify_*_state_change return an error code if errors happen.\nSo that the error codes could be propagated and the uaf bugs can be avoid.\n\nv2 reports a compilation warning. This v3 fixed this warning and built\nsuccessfully in my local environment with no additional warnings.\nv2: https://lore.kernel.org/patchwork/patch/1435218/(CVE-2022-49085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_console: eliminate anonymous module_init \u0026amp; module_exit\n\nEliminate anonymous module_init() and module_exit(), which can lead to\nconfusion or ambiguity when reading System.map, crashes/oops/bugs,\nor an initcall_debug log.\n\nGive each of these init and exit functions unique driver-specific\nnames to eliminate the anonymous names.\n\nExample 1: (System.map)\n ffffffff832fc78c t init\n ffffffff832fc79e t init\n ffffffff832fc8f8 t init\n\nExample 2: (initcall_debug log)\n calling init+0x0/0x12 @ 1\n initcall init+0x0/0x12 returned 0 after 15 usecs\n calling init+0x0/0x60 @ 1\n initcall init+0x0/0x60 returned 0 after 2 usecs\n calling init+0x0/0x9a @ 1\n initcall init+0x0/0x9a returned 0 after 74 usecs(CVE-2022-49100)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: usb: host: Fix deadlock in oxu_bus_suspend()\n\nThere is a deadlock in oxu_bus_suspend(), which is shown below:\n\n (Thread 1) | (Thread 2)\n | timer_action()\noxu_bus_suspend() | mod_timer()\n spin_lock_irq() //(1) | (wait a time)\n ... | oxu_watchdog()\n del_timer_sync() | spin_lock_irq() //(2)\n (wait timer to stop) | ...\n\nWe hold oxu-\u0026gt;lock in position (1) of thread 1, and use\ndel_timer_sync() to wait timer to stop, but timer handler\nalso need oxu-\u0026gt;lock in position (2) of thread 2. As a result,\noxu_bus_suspend() will block forever.\n\nThis patch extracts del_timer_sync() from the protection of\nspin_lock_irq(), which could let timer handler to obtain\nthe needed lock.(CVE-2022-49313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle\n\nkobject_init_and_add() takes reference even when it fails.\nAccording to the doc of kobject_init_and_add()\n\n If this function returns an error, kobject_put() must be called to\n properly clean up the memory associated with the object.\n\nFix this issue by calling kobject_put().(CVE-2022-49370)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: check attribute length for bearer name\n\nsyzbot reported uninit-value:\n=====================================================\nBUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]\nBUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725\n string_nocheck lib/vsprintf.c:644 [inline]\n string+0x4f9/0x6f0 lib/vsprintf.c:725\n vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806\n vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158\n vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256\n vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283\n vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50\n _printk+0x18d/0x1cf kernel/printk/printk.c:2293\n tipc_enable_bearer net/tipc/bearer.c:371 [inline]\n __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033\n tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042\n genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]\n\n- Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.\n- Do not use \u0026apos;illegal name\u0026apos; in printing message.(CVE-2022-49374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: usbip: fix a refcount leak in stub_probe()\n\nusb_get_dev() is called in stub_device_alloc(). When stub_probe() fails\nafter that, usb_put_dev() needs to be called to release the reference.\n\nFix this by moving usb_put_dev() to sdev_free error path handling.\n\nFind this by code review.(CVE-2022-49389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f (\u0026quot;net: allow out-of-order netdev unregistration\u0026quot;)\nand commit e5f80fcf869a (\u0026quot;ipv6: give an IPv6 dev to blackhole_netdev\u0026quot;), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem.(CVE-2022-49390)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nphy: qcom-qmp: fix reset-controller leak on probe errors\n\nMake sure to release the lane reset controller in case of a late probe\nerror (e.g. probe deferral).\n\nNote that due to the reset controller being defined in devicetree in\n\u0026quot;lane\u0026quot; child nodes, devm_reset_control_get_exclusive() cannot be used\ndirectly.(CVE-2022-49396)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntty: fix deadlock caused by calling printk() under tty_port-\u0026gt;lock\n\npty_write() invokes kmalloc() which may invoke a normal printk() to print\nfailure message. This can cause a deadlock in the scenario reported by\nsyz-bot below:\n\n CPU0 CPU1 CPU2\n ---- ---- ----\n lock(console_owner);\n lock(\u0026amp;port_lock_key);\n lock(\u0026amp;port-\u0026gt;lock);\n lock(\u0026amp;port_lock_key);\n lock(\u0026amp;port-\u0026gt;lock);\n lock(console_owner);\n\nAs commit dbdda842fe96 (\u0026quot;printk: Add console owner and waiter logic to\nload balance console writes\u0026quot;) said, such deadlock can be prevented by\nusing printk_deferred() in kmalloc() (which is invoked in the section\nguarded by the port-\u0026gt;lock). But there are too many printk() on the\nkmalloc() path, and kmalloc() can be called from anywhere, so changing\nprintk() to printk_deferred() is too complicated and inelegant.\n\nTherefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so\nthat printk() will not be called, and this deadlock problem can be\navoided.\n\nSyzbot reported the following lockdep error:\n\n======================================================\nWARNING: possible circular locking dependency detected\n5.4.143-00237-g08ccc19a-dirty #10 Not tainted\n------------------------------------------------------\nsyz-executor.4/29420 is trying to acquire lock:\nffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]\nffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023\n\nbut task is already holding lock:\nffff8880119c9158 (\u0026amp;port-\u0026gt;lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #2 (\u0026amp;port-\u0026gt;lock){-.-.}-{2:2}:\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159\n tty_port_tty_get drivers/tty/tty_port.c:288 [inline] \t\t\u0026lt;-- lock(\u0026amp;port-\u0026gt;lock);\n tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47\n serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767\n serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854\n serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] \t\u0026lt;-- lock(\u0026amp;port_lock_key);\n serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870\n serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126\n __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156\n [...]\n\n-\u0026gt; #1 (\u0026amp;port_lock_key){-.-.}-{2:2}:\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159\n serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198\n\t\t\t\t\t\t\t\t\t\t\u0026lt;-- lock(\u0026amp;port_lock_key);\n call_console_drivers kernel/printk/printk.c:1819 [inline]\n console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504\n vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024\t\t\t\u0026lt;-- lock(console_owner);\n vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394\n printk+0xba/0xed kernel/printk/printk.c:2084\n register_console+0x8b3/0xc10 kernel/printk/printk.c:2829\n univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681\n console_init+0x49d/0x6d3 kernel/printk/printk.c:2915\n start_kernel+0x5e9/0x879 init/main.c:713\n secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241\n\n-\u0026gt; #0 (console_owner){....}-{0:0}:\n [...]\n lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734\n console_trylock_spinning kernel/printk/printk.c:1773 \n---truncated---(CVE-2022-49441)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix listen() setting the bar too high for the prealloc rings\n\nAF_RXRPC\u0026apos;s listen() handler lets you set the backlog up to 32 (if you bump\nup the sysctl), but whilst the preallocation circular buffers have 32 slots\nin them, one of them has to be a dead slot because we\u0026apos;re using CIRC_CNT().\n\nThis means that listen(rxrpc_sock, 32) will cause an oops when the socket\nis closed because rxrpc_service_prealloc_one() allocated one too many calls\nand rxrpc_discard_prealloc() won\u0026apos;t then be able to get rid of them because\nit\u0026apos;ll think the ring is empty. rxrpc_release_calls_on_socket() then tries\nto abort them, but oopses because call-\u0026gt;peer isn\u0026apos;t yet set.\n\nFix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match\nthe ring capacity.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000086\n ...\n RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __wake_up_common_lock+0x7a/0x90\n ? rxrpc_notify_socket+0x8e/0x140 [rxrpc]\n ? rxrpc_abort_call+0x4c/0x60 [rxrpc]\n rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc]\n rxrpc_release+0xc9/0x1c0 [rxrpc]\n __sock_release+0x37/0xa0\n sock_close+0x11/0x20\n __fput+0x89/0x240\n task_work_run+0x59/0x90\n do_exit+0x319/0xaa0(CVE-2022-49450)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_scmi: Fix list protocols enumeration in the base protocol\n\nWhile enumerating protocols implemented by the SCMI platform using\nBASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is\ncurrently validated in an improper way since the check employs a sum\nbetween unsigned integers that could overflow and cause the check itself\nto be silently bypassed if the returned value \u0026apos;loop_num_ret\u0026apos; is big\nenough.\n\nFix the validation avoiding the addition.(CVE-2022-49451)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm: msm: fix possible memory leak in mdp5_crtc_cursor_set()\n\ndrm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo\nneeds to be put when msm_gem_get_and_pin_iova fails.(CVE-2022-49467)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt\n\nof_node_get() returns a node with refcount incremented.\nCalling of_node_put() to drop the reference when not needed anymore.(CVE-2022-49481)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/rockchip: vop: fix possible null-ptr-deref in vop_bind()\n\nIt will cause null-ptr-deref in resource_size(), if platform_get_resource()\nreturns NULL, move calling resource_size() after devm_ioremap_resource() that\nwill check \u0026apos;res\u0026apos; to avoid null-ptr-deref.(CVE-2022-49491)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: pmac32-cpufreq: Fix refcount leak bug\n\nIn pmac_cpufreq_init_MacRISC3(), we need to add corresponding\nof_node_put() for the three node pointers whose refcount have\nbeen incremented by of_find_node_by_name().(CVE-2022-49621)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()\n\nIn fsl_mc_bus_remove(), mc-\u0026gt;root_mc_bus_dev-\u0026gt;mc_io is passed to\nfsl_destroy_mc_io(). However, mc-\u0026gt;root_mc_bus_dev is already freed in\nfsl_mc_device_remove(). Then reference to mc-\u0026gt;root_mc_bus_dev-\u0026gt;mc_io\ntriggers KASAN use-after-free. To avoid the use-after-free, keep the\nreference to mc-\u0026gt;root_mc_bus_dev-\u0026gt;mc_io in a local variable and pass to\nfsl_destroy_mc_io().\n\nThis patch needs rework to apply to kernels older than v5.15.(CVE-2022-49711)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init\n\nIf the function sdma_load_context() fails, the sdma_desc will be\nfreed, but the allocated desc-\u0026gt;bd is forgot to be freed.\n\nWe already met the sdma_load_context() failure case and the log as\nbelow:\n[ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready\n...\n\nIn this case, the desc-\u0026gt;bd will not be freed without this change.(CVE-2022-49746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: Fix double increment of client_count in dma_chan_get()\n\nThe first time dma_chan_get() is called for a channel the channel\nclient_count is incorrectly incremented twice for public channels,\nfirst in balance_ref_count(), and again prior to returning. This\nresults in an incorrect client count which will lead to the\nchannel resources not being freed when they should be. A simple\n test of repeated module load and unload of async_tx on a Dell\n Power Edge R7425 also shows this resulting in a kref underflow\n warning.\n\n[ 124.329662] async_tx: api initialized (async)\n[ 129.000627] async_tx: api initialized (async)\n[ 130.047839] ------------[ cut here ]------------\n[ 130.052472] refcount_t: underflow; use-after-free.\n[ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28\nrefcount_warn_saturate+0xba/0x110\n[ 130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr\nintel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm\nmgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si\nsyscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops\nk10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat\nfat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul\nlibahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas\ni40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash\ndm_log dm_mod [last unloaded: async_tx]\n[ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not\ntainted 5.14.0-185.el9.x86_64 #1\n[ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS\n1.18.0 01/17/2022\n[ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110\n[ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d\n26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a\nbd 55 00 \u0026lt;0f\u0026gt; 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff\n48 c7\n[ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286\n[ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000\n[ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0\n[ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff\n[ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970\n[ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000)\nknlGS:0000000000000000\n[ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0\n[ 130.219729] Call Trace:\n[ 130.222192] \u0026lt;TASK\u0026gt;\n[ 130.224305] dma_chan_put+0x10d/0x110\n[ 130.227988] dmaengine_put+0x7a/0xa0\n[ 130.231575] __do_sys_delete_module.constprop.0+0x178/0x280\n[ 130.237157] ? syscall_trace_enter.constprop.0+0x145/0x1d0\n[ 130.242652] do_syscall_64+0x5c/0x90\n[ 130.246240] ? exc_page_fault+0x62/0x150\n[ 130.250178] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 130.255243] RIP: 0033:0x7f6463a3f5ab\n[ 130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48\n83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00\n00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89\n01 48\n[ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX:\n00000000000000b0\n[ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab\n[ 130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8\n[ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000\n[ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8\n[ 130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8\n[ 130.320875] \u0026lt;/TASK\u0026gt;\n[ 130.323081] ---[ end trace eff7156d56b5cf25 ]---\n\ncat /sys/class/dma/dma0chan*/in_use would get the wrong result.\n2\n2\n2\n\nTest-by: Jie Hai \u0026lt;haijie1@huawei.com\u0026gt;(CVE-2022-49753)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nEDAC/highbank: Fix memory leak in highbank_mc_probe()\n\nWhen devres_open_group() fails, it returns -ENOMEM without freeing memory\nallocated by edac_mc_alloc().\n\nCall edac_mc_free() on the error handling path to avoid a memory leak.\n\n [ bp: Massage commit message. ](CVE-2022-49757)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path()\n\nsnd_hda_get_connections() can return a negative error code.\nIt may lead to accessing \u0026apos;conn\u0026apos; array at a negative index.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52988)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: betop: check shape of output reports\n\nbetopff_init() only checks the total sum of the report counts for each\nreport field to be at least 4, but hid_betopff_play() expects 4 report\nfields.\nA device advertising an output report with one field and 4 report counts\nwould pass the check but crash the kernel with a NULL pointer dereference\nin hid_betopff_play().(CVE-2023-53015)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix pointer-leak due to insufficient speculative store bypass mitigation\n\nTo mitigate Spectre v4, 2039f26f3aca (\u0026quot;bpf: Fix leakage due to\ninsufficient speculative store bypass mitigation\u0026quot;) inserts lfence\ninstructions after 1) initializing a stack slot and 2) spilling a\npointer to the stack.\n\nHowever, this does not cover cases where a stack slot is first\ninitialized with a pointer (subject to sanitization) but then\noverwritten with a scalar (not subject to sanitization because\nthe slot was already initialized). In this case, the second write\nmay be subject to speculative store bypass (SSB) creating a\nspeculative pointer-as-scalar type confusion. This allows the\nprogram to subsequently leak the numerical pointer value using,\nfor example, a branch-based cache side channel.\n\nTo fix this, also sanitize scalars if they write a stack slot\nthat previously contained a pointer. Assuming that pointer-spills\nare only generated by LLVM on register-pressure, the performance\nimpact on most real-world BPF programs should be small.\n\nThe following unprivileged BPF bytecode drafts a minimal exploit\nand the mitigation:\n\n [...]\n // r6 = 0 or 1 (skalar, unknown user input)\n // r7 = accessible ptr for side channel\n // r10 = frame pointer (fp), to be leaked\n //\n r9 = r10 # fp alias to encourage ssb\n *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked\n // lfence added here because of pointer spill to stack.\n //\n // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor\n // for no r9-r10 dependency.\n //\n *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr\n // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID,\n // store may be subject to SSB\n //\n // fix: also add an lfence when the slot contained a ptr\n //\n r8 = *(u64 *)(r9 - 8)\n // r8 = architecturally a scalar, speculatively a ptr\n //\n // leak ptr using branch-based cache side channel:\n r8 \u0026amp;= 1 // choose bit to leak\n if r8 == 0 goto SLOW // no mispredict\n // architecturally dead code if input r6 is 0,\n // only executes speculatively iff ptr bit is 1\n r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast)\nSLOW:\n [...]\n\nAfter running this, the program can time the access to *(r7 + 0) to\ndetermine whether the chosen pointer bit was 0 or 1. Repeat this 64\ntimes to recover the whole address on amd64.\n\nIn summary, sanitization can only be skipped if one scalar is\noverwritten with another scalar. Scalar-confusion due to speculative\nstore bypass can not lead to invalid accesses because the pointer\nbounds deducted during verification are enforced using branchless\nlogic. See 979d63d50c0c (\u0026quot;bpf: prevent out of bounds speculation on\npointer arithmetic\u0026quot;) for details.\n\nDo not make the mitigation depend on !env-\u0026gt;allow_{uninit_stack,ptr_leaks}\nbecause speculative leaks are likely unexpected if these were enabled.\nFor example, leaking the address to a protected log file may be acceptable\nwhile disabling the mitigation might unintentionally leak the address\ninto the cached-state of a map that is accessible to unprivileged\nprocesses.(CVE-2023-53024)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Fix double free in error path\n\nIf the uvc_status_init() function fails to allocate the int_urb, it will\nfree the dev-\u0026gt;status pointer but doesn\u0026apos;t reset the pointer to NULL. This\nresults in the kfree() call in uvc_status_cleanup() trying to\ndouble-free the memory. Fix it by resetting the dev-\u0026gt;status pointer to\nNULL after freeing it.\n\nReviewed by: Ricardo Ribalda \u0026lt;ribalda@chromium.org\u0026gt;(CVE-2024-57980)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: don\u0026apos;t allow 1 packet limit\n\nThe current implementation does not work correctly with a limit of\n1. iproute2 actually checks for this and this patch adds the check in\nkernel as well.\n\nThis fixes the following syzkaller reported crash:\n\nUBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6\nindex 65535 is out of range for type \u0026apos;struct sfq_head[128]\u0026apos;\nCPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n __dump_stack lib/dump_stack.c:79 [inline]\n dump_stack+0x125/0x19f lib/dump_stack.c:120\n ubsan_epilogue lib/ubsan.c:148 [inline]\n __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347\n sfq_link net/sched/sch_sfq.c:210 [inline]\n sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238\n sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500\n sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525\n qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026\n tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319\n qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026\n dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296\n netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline]\n dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362\n __dev_close_many+0x214/0x350 net/core/dev.c:1468\n dev_close_many+0x207/0x510 net/core/dev.c:1506\n unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738\n unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695\n unregister_netdevice include/linux/netdevice.h:2893 [inline]\n __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689\n tun_detach drivers/net/tun.c:705 [inline]\n tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640\n __fput+0x203/0x840 fs/file_table.c:280\n task_work_run+0x129/0x1b0 kernel/task_work.c:185\n exit_task_work include/linux/task_work.h:33 [inline]\n do_exit+0x5ce/0x2200 kernel/exit.c:931\n do_group_exit+0x144/0x310 kernel/exit.c:1046\n __do_sys_exit_group kernel/exit.c:1057 [inline]\n __se_sys_exit_group kernel/exit.c:1055 [inline]\n __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055\n do_syscall_64+0x6c/0xd0\n entry_SYSCALL_64_after_hwframe+0x61/0xcb\nRIP: 0033:0x7fe5e7b52479\nCode: Unable to access opcode bytes at RIP 0x7fe5e7b5244f.\nRSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479\nRDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000\nRBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0\nR13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270\n\nThe crash can be also be reproduced with the following (with a tc\nrecompiled to allow for sfq limits of 1):\n\ntc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s\n../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1\nifconfig dummy0 up\nping -I dummy0 -f -c2 -W0.1 8.8.8.8\nsleep 1\n\nScenario that triggers the crash:\n\n* the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1\n\n* TBF dequeues: it peeks from SFQ which moves the packet to the\n gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so\n it schedules itself for later.\n\n* the second packet is sent and TBF tries to queues it to SFQ. qdisc\n qlen is now 2 and because the SFQ limit is 1 the packet is dropped\n by SFQ. At this point qlen is 1, and all of the SFQ slots are empty,\n however q-\u0026gt;tail is not NULL.\n\nAt this point, assuming no more packets are queued, when sch_dequeue\nruns again it will decrement the qlen for the current empty slot\ncausing an underflow and the subsequent out of bounds access.(CVE-2024-57996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npartitions: mac: fix handling of bogus partition table\n\nFix several issues in partition probing:\n\n - The bailout for a bad partoffset must use put_dev_sector(), since the\n preceding read_part_sector() succeeded.\n - If the partition table claims a silly sector size like 0xfff bytes\n (which results in partition table entries straddling sector boundaries),\n bail out instead of accessing out-of-bounds memory.\n - We must not assume that the partition table contains proper NUL\n termination - use strnlen() and strncmp() instead of strlen() and\n strcmp().(CVE-2025-21772)",
"id": "OESA-2025-1408",
"modified": "2026-08-06T11:08:30Z",
"published": "2025-04-11T11:08:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1408"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49059"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49085"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49100"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49313"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49370"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49374"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49390"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49396"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49441"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49450"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49451"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49467"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49481"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49491"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49621"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49711"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49746"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49753"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49757"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52988"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53015"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53024"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57980"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57996"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21772"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49059",
"CVE-2022-49085",
"CVE-2022-49100",
"CVE-2022-49313",
"CVE-2022-49370",
"CVE-2022-49374",
"CVE-2022-49389",
"CVE-2022-49390",
"CVE-2022-49396",
"CVE-2022-49441",
"CVE-2022-49450",
"CVE-2022-49451",
"CVE-2022-49467",
"CVE-2022-49481",
"CVE-2022-49491",
"CVE-2022-49621",
"CVE-2022-49711",
"CVE-2022-49746",
"CVE-2022-49753",
"CVE-2022-49757",
"CVE-2023-52988",
"CVE-2023-53015",
"CVE-2023-53024",
"CVE-2024-57980",
"CVE-2024-57996",
"CVE-2025-21772"
]
}
OESA-2025-2081 (CVE-2022-49377)
Vulnerability from osv_openeuler – Published: 2025-08-29 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx
blk_mq_run_hw_queues() could be run when there isn't queued request and after queue is cleaned up, at that time tagset is freed, because tagset lifetime is covered by driver, and often freed after blk_cleanup_queue() returns.
So don't touch ->tagset for figuring out current default hctx by the mapping built in request queue, so use-after-free on tagset can be avoided. Meantime this way should be fast than retrieving mapping from tagset.(CVE-2022-49377)
In the Linux kernel, the following vulnerability has been resolved:
macsec: fix UAF bug for real_dev
Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following:
================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161
Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748
Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327
After commit faab39f63c1f ("net: allow out-of-order netdev unregistration") and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.(CVE-2022-49390)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: don't skip expired elements during walk
There is an asymmetry between commit/abort and preparation phase if the following conditions are met:
- set is a verdict map ("1.2.3.4 : jump foo")
- timeouts are enabled
In this case, following sequence is problematic:
- element E in set S refers to chain C
- userspace requests removal of set S
- kernel does a set walk to decrement chain->use count for all elements from preparation phase
- kernel does another set walk to remove elements from the commit phase (or another walk to do a chain->use increment for all elements from abort phase)
If E has already expired in 1), it will be ignored during list walk, so its use count won't have been changed.
Then, when set is culled, ->destroy callback will zap the element via nf_tables_set_elem_destroy(), but this function is only safe for elements that have been deactivated earlier from the preparation phase: lack of earlier deactivate removes the element but leaks the chain use count, which results in a WARN splat when the chain gets removed later, plus a leak of the nft_chain structure.
Update pipapo_get() not to skip expired elements, otherwise flush command reports bogus ENOENT errors.(CVE-2023-52924)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm/fault: Fix kfence page fault reporting
copy_from_kernel_nofault() can be called when doing read of /proc/kcore. /proc/kcore can have some unmapped kfence objects which when read via copy_from_kernel_nofault() can cause page faults. Since *_nofault() functions define their own fixup table for handling fault, use that instead of asking kfence to handle such faults.
Hence we search the exception tables for the nip which generated the fault. If there is an entry then we let the fixup table handler handle the page fault by returning an error from within ___do_page_fault().
This can be easily triggered if someone tries to do dd from /proc/kcore. eg. dd if=/proc/kcore of=/dev/null bs=1M
Some example false negatives:
=============================== BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0 Invalid read at 0xc0000000fdff0000: copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec
BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0 Use-after-free read at 0xc0000000fe050000 (in kfence-#2): copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur
The action force umount(umount -f) will attempt to kill all rpc_task even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpc_task to nfs server.
NFS CLIENT
thread1 thread2 open("file") ... nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task / rpc_task1 / rpc_run_task rpc_wait_for_completion_task
umount -f
nfs_umount_begin
rpc_killall_tasks
rpc_signal_task
rpc_task1 been wakeup
and return -512
_nfs4_do_open // while loop ... nfs4_run_open_task / rpc_task2 / rpc_run_task rpc_wait_for_completion_task
While processing an open request, nfsd will first attempt to find or allocate an nfs4_openowner. If it finds an nfs4_openowner that is not marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since two rpc_task can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered.
NFS SERVER
nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads
nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2
nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!!
nfsd4_process_open2
...
write_threads
...
nfsd_destroy_serv
nfsd_shutdown_net
nfs4_state_shutdown_net
nfs4_state_destroy_net
destroy_client
__destroy_client
// won't find oo1!!!
nfsd_shutdown_generic
nfsd_file_cache_shutdown
kmem_cache_destroy
for nfsd_file_slab
and nfsd_file_mark_slab
// bark since nfsd_file1
// and nfsd_file_mark1
// still alive
======================================================================= BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown()
Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dum ---truncated---(CVE-2024-56779)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: state: fix out-of-bounds read during lookup
lookup and resize can run in parallel.
The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array.
rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask;
While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {
This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again).
Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent.
The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side.
xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)
In the Linux kernel, the following vulnerability has been resolved:
rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read
The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int.
Fix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: check the bounds of read/write syscalls
count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.(CVE-2025-21687)
In the Linux kernel, the following vulnerability has been resolved:
atm: Fix NULL pointer dereference
When MPOA_cache_impos_rcvd() receives the msg, it can trigger Null Pointer Dereference Vulnerability if both entry and holding_time are NULL. Because there is only for the situation where entry is NULL and holding_time exists, it can be passed when both entry and holding_time are NULL. If these are NULL, the entry will be passd to eg_cache_put() as parameter and it is referenced by entry->use code in it.
kasan log:
[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I
[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102
[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470
[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80
[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006
[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e
[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030
[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88
[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15
[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068
[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000
[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0
[ 3.326430] Call Trace:
[ 3.326725] <TASK>
[ 3.326927] ? die_addr+0x3c/0xa0
[ 3.327330] ? exc_general_protection+0x161/0x2a0
[ 3.327662] ? asm_exc_general_protection+0x26/0x30
[ 3.328214] ? vprintk_emit+0x15e/0x420
[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470
[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470
[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10
[ 3.329664] ? console_unlock+0x107/0x1d0
[ 3.329946] ? __pfx_console_unlock+0x10/0x10
[ 3.330283] ? do_syscall_64+0xa6/0x1a0
[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f
[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10
[ 3.331395] ? down_trylock+0x52/0x80
[ 3.331703] ? vprintk_emit+0x15e/0x420
[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10
[ 3.332279] ? down_trylock+0x52/0x80
[ 3.332527] ? _printk+0xbf/0x100
[ 3.332762] ? __pfx__printk+0x10/0x10
[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0
[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10
[ 3.333614] msg_from_mpoad+0x1185/0x2750
[ 3.333893] ? __build_skb_around+0x27b/0x3a0
[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10
[ 3.334501] ? __alloc_skb+0x1c0/0x310
[ 3.334809] ? __pfxallocskb+0x10/0x10
[ 3.335283] ? _raw_spin_lock+0xe0/0xe0
[ 3.335632] ? finish_wait+0x8d/0x1e0
[ 3.335975] vcc_sendmsg+0x684/0xba0
[ 3.336250] ? pfx_vcc_sendmsg+0x10/0x10
[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10
[ 3.337056] ? fdget+0x176/0x3e0
[ 3.337348] __sys_sendto+0x4a2/0x510
[ 3.337663] ? __pfxsyssendto+0x10/0x10
[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400
[ 3.338364] ? sock_ioctl+0x1bb/0x5a0
[ 3.338653] ? rseq_handle_notify_resume+0x825/0xd20
[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10
[ 3.339316] ? __pfxrseqhandle_notify_resume+0x10/0x10
[ 3.339727] ? selinux_file_ioctl+0xa4/0x260
[ 3.340166] x64_sys_sendto+0xe0/0x1c0
[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140
[ 3.340898] do_syscall_64+0xa6/0x1a0
[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 3.341533] RIP: 0033:0x44a380
[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00
[
---truncated---(CVE-2025-22018)
In the Linux kernel, the following vulnerability has been resolved:
udp: Fix memory accounting leak.
Matt Dowling reported a weird UDP memory usage issue.
Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops.
We can reproduce the issue with the script below [0]:
-
/proc/net/sockstat reports 0 pages
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 0
-
Run the script till the report reaches 524,288
python3 test.py & sleep 5
cat /proc/net/sockstat | grep UDP:
UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT
-
Kill the socket and confirm the number never drops
pkill python3 && sleep 5
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 524288
-
(necessary since v6.0) Trigger proto_memory_pcpu_drain()
python3 test.py & sleep 1 && pkill python3
-
The number doubles
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 1048577
The application set INT_MAX to SO_RCVBUF, which triggered an integer overflow in udp_rmem_release().
When a socket is close()d, udp_destruct_common() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable.
The total size is then passed to udp_rmem_release() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow.
Then, the released amount is calculated as follows:
1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().
When the issue occurred, the total in udp_destruct_common() was 2147484480 (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().
At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inet_sock_destruct(). However, udp_memory_allocated ends up doubling at 4).
Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated"), memory usage no longer doubles immediately after a socket is close()d because __sk_mem_reduce_allocated() caches the amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double.
This issue makes further memory allocation fail once the socket's sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet drops.
To prevent this issue, let's use unsigned int for the calculation and call sk_forward_alloc_add() only once for the small delta.
Note that first_packet_length() also potentially has the same problem.
[0]: from socket import *
SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1
s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)
c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname())
data = b'a' * 100
while True: c.send(data)(CVE-2025-22058)
In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Allocate vfinfo size for VF GUIDs when supported
Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs") added support for getting VF port and node GUIDs in netlink ifinfo messages, but their size was not taken into consideration in the function that allocates the netlink message, causing the following warning when a netlink message is filled with many VF port and node GUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too long
Kernel warning:
------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfxmutexlock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfxnetlinklookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 _syssendmsg+0x559/0x5a0 ? pfx_sys_sendmsg+0x10/0x10 ? pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 syssendmsg+0xe4/0x150 ? pfx_syssendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? pfx_handle_pte_fault+0x10/0x10 ---truncated---(CVE-2025-22075)
In the Linux kernel, the following vulnerability has been resolved:
isofs: Prevent the use of too small fid
syzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]
The handle_bytes value passed in by the reproducing program is equal to 12. In handle_to_path(), only 12 bytes of memory are allocated for the structure file_handle->f_handle member, which causes an out-of-bounds access when accessing the member parent_block of the structure isofs_fid in isofs, because accessing parent_block requires at least 16 bytes of f_handle. Here, fh_len is used to indirectly confirm that the value of handle_bytes is greater than 3 before accessing parent_block.
[1] BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466 CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600(CVE-2025-37780)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a UAF vulnerability in class handling
This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class handling. The issue occurs due to a time-of-check/time-of-use condition in hfsc_change_class() when working with certain child qdiscs like netem or codel.
The vulnerability works as follows: 1. hfsc_change_class() checks if a class has packets (q.qlen != 0) 2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g., codel, netem) might drop packets and empty the queue 3. The code continues assuming the queue is still non-empty, adding the class to vttree 4. This breaks HFSC scheduler assumptions that only non-empty classes are in vttree 5. Later, when the class is destroyed, this can lead to a Use-After-Free
The fix adds a second queue length check after qdisc_peek_len() to verify the queue wasn't emptied.(CVE-2025-37797)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc
As described in Gerrard's report [1], we have a UAF case when an hfsc class has a netem child qdisc. The crux of the issue is that hfsc is assuming that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted the class in the vttree or eltree (which is not true for the netem duplicate case).
This patch checks the n_active class variable to make sure that the code won't insert the class in the vttree or eltree twice, catering for the reentrant case.
[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37890)
In the Linux kernel, the following vulnerability has been resolved:
sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()
When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the child qdisc's peek() operation before incrementing sch->q.qlen and sch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may trigger an immediate dequeue and potential packet drop. In such cases, qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to inconsistent queue accounting. This can leave an empty HFSC class in the active list, causing further consequences like use-after-free.
This patch fixes the bug by moving the increment of sch->q.qlen and sch->qstats.backlog before the call to the child qdisc's peek() operation. This ensures that queue length and backlog are always accurate when packet drops or dequeues are triggered during the peek.(CVE-2025-38000)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Address reentrant enqueue adding class to eltree twice
Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM.
The patch only checks the cl->cl_nactive field to determine whether
it is the first insertion or not [2], but this field is only
incremented by init_vf [3].
By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the
check and insert the class twice in the eltree.
Under normal conditions, this would lead to an infinite loop in
hfsc_dequeue for the reasons we already explained in this report [5].
However, if TBF is added as root qdisc and it is configured with a
very low rate,
it can be utilized to prevent packets from being dequeued.
This behavior can be exploited to perform subsequent insertions in the
HFSC eltree and cause a UAF."
To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfsc_enqueue whether the class is already in the eltree whenever the HFSC_RSC flag is set.
[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u(CVE-2025-38001)
In the Linux kernel, the following vulnerability has been resolved:
net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done
Syzbot reported a slab-use-after-free with the following call trace:
================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25
Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394
Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue.
I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1
The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited.
tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base;
simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work)
Fix this by holding net reference count before encrypt.(CVE-2025-38052)
A vulnerability was found in Linux Kernel up to 6.16-rc1 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch c337efb20d6d9f9bbb4746f6b119917af5c886dc/b44f791f27b14c9eb6b907fbe51f2ba8bec32085/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72/9c19498bdd7cb9d854bd3c54260f71cf7408495e/b4e9bab6011b9559b7c157b16b91ae46d4d8c533/d1bc80da75c789f2f6830df89d91fb2f7a509943/82448d4dcd8406dec688632a405fdcf7f170ec69/82ffbe7776d0ac084031f114167712269bf3d832 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38115)
Linux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States. There is a security vulnerability in Linux kernel, which originates from improper processing of udp gso segmentation, which may lead to memory corruption.(CVE-2025-38124)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer
The reproduction steps: 1. create a tun interface 2. enable l2 bearer 3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun
tipc: Started in network mode tipc: Node identity 8af312d38a21, cluster identity 4711 tipc: Enabled bearer <eth:syz_tun>, priority 1 Oops: general protection fault KASAN: null-ptr-deref in range CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT Hardware name: QEMU Ubuntu 24.04 PC RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0
the ub was in fact a struct dev.
when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or other media when other thread changes it.
fix this by checking media_id.(CVE-2025-38184)
A vulnerability classified as critical has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc1 (Operating System).CWE is classifying the issue as CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.This is going to have an impact on availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc2 eliminates this vulnerability. Applying the patch bfa4d86e130a09f67607482e988313430e38f6c4/2a3ad42a57b43145839f2f233fb562247658a6d9/e9994e7b9f7bbb882d13c8191731649249150d21/ba9db6f907ac02215e30128770f85fbd7db2fcf9 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20064).(CVE-2025-38192)
In the Linux kernel, the following vulnerability has been resolved:
md/raid1: Fix stack memory use after return in raid1_reshape
In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic.
Example access path:
raid1_reshape() { // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool; }
raid1_read_request() or raid1_write_request() { alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } } }
mempool_free() { if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); } }
Fix: reinit conf->r1bio_pool.wait after assigning newpool.(CVE-2025-38445)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free in tipc_conn_close().
syzbot reported a null-ptr-deref in tipc_conn_close() during netns dismantle. [0]
tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls tipc_conn_close() for each tipc_conn.
The problem is that tipc_conn_close() is called after releasing the IDR lock.
At the same time, there might be tipc_conn_recv_work() running and it could call tipc_conn_close() for the same tipc_conn and release its last ->kref.
Once we release the IDR lock in tipc_topsrv_stop(), there is no guarantee that the tipc_conn is alive.
Let's hold the ref before releasing the lock and put the ref after tipc_conn_close() in tipc_topsrv_stop().
[0]: BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435
CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb(CVE-2025-38464)
A vulnerability was found in Linux Kernel up to 6.16-rc5 (Operating System). It has been classified as problematic.CWE is classifying the issue as CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99, 6.12.39, 6.15.7 or 6.16-rc6 eliminates this vulnerability. Applying the patch 9da025150b7c14a8390fc06aea314c0a4011e82c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98/fd69af06101090eaa60b3d216ae715f9c0a58e5b/76602d8e13864524382b0687dc32cd8f19164d5a/55baecb9eb90238f60a8350660d6762046ebd3bd/4b8e18af7bea92f8b7fb92d40aeae729209db250/cd7ff61bfffd7000143c42bbffb85eeb792466d6/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38465)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Add down_write(trace_event_sem) when adding trace event
When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values.
If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel.
The addition of the event should take the trace_event_sem for write while it adds the new event.
Also add a lockdep_assert_held() on that semaphore in __trace_add_event_dirs() as it iterates the list.(CVE-2025-38539)
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Exit early on perf_mmap() fail
When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak.
Return early on failure to prevent that.(CVE-2025-38565)
A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.100/6.12.40/6.15.8 (Operating System).Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.Upgrading to version 6.6.101, 6.12.41 or 6.15.9 eliminates this vulnerability. Applying the patch 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61/708fd522b86d2a9544c34ec6a86fa3fc23336525/0f67015d72627bad72da3c2084352e0aa134416b/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38670)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"perf-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-279.0.0.181.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"perf-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-279.0.0.181.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: don\u0026apos;t touch -\u0026gt;tagset in blk_mq_get_sq_hctx\n\nblk_mq_run_hw_queues() could be run when there isn\u0026apos;t queued request and\nafter queue is cleaned up, at that time tagset is freed, because tagset\nlifetime is covered by driver, and often freed after blk_cleanup_queue()\nreturns.\n\nSo don\u0026apos;t touch -\u0026gt;tagset for figuring out current default hctx by the mapping\nbuilt in request queue, so use-after-free on tagset can be avoided. Meantime\nthis way should be fast than retrieving mapping from tagset.(CVE-2022-49377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f (\u0026quot;net: allow out-of-order netdev unregistration\u0026quot;)\nand commit e5f80fcf869a (\u0026quot;ipv6: give an IPv6 dev to blackhole_netdev\u0026quot;), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem.(CVE-2022-49390)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: don\u0026apos;t skip expired elements during walk\n\nThere is an asymmetry between commit/abort and preparation phase if the\nfollowing conditions are met:\n\n1. set is a verdict map (\u0026quot;1.2.3.4 : jump foo\u0026quot;)\n2. timeouts are enabled\n\nIn this case, following sequence is problematic:\n\n1. element E in set S refers to chain C\n2. userspace requests removal of set S\n3. kernel does a set walk to decrement chain-\u0026gt;use count for all elements\n from preparation phase\n4. kernel does another set walk to remove elements from the commit phase\n (or another walk to do a chain-\u0026gt;use increment for all elements from\n abort phase)\n\nIf E has already expired in 1), it will be ignored during list walk, so its use count\nwon\u0026apos;t have been changed.\n\nThen, when set is culled, -\u0026gt;destroy callback will zap the element via\nnf_tables_set_elem_destroy(), but this function is only safe for\nelements that have been deactivated earlier from the preparation phase:\nlack of earlier deactivate removes the element but leaks the chain use\ncount, which results in a WARN splat when the chain gets removed later,\nplus a leak of the nft_chain structure.\n\nUpdate pipapo_get() not to skip expired elements, otherwise flush\ncommand reports bogus ENOENT errors.(CVE-2023-52924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm/fault: Fix kfence page fault reporting\n\ncopy_from_kernel_nofault() can be called when doing read of /proc/kcore.\n/proc/kcore can have some unmapped kfence objects which when read via\ncopy_from_kernel_nofault() can cause page faults. Since *_nofault()\nfunctions define their own fixup table for handling fault, use that\ninstead of asking kfence to handle such faults.\n\nHence we search the exception tables for the nip which generated the\nfault. If there is an entry then we let the fixup table handler handle the\npage fault by returning an error from within ___do_page_fault().\n\nThis can be easily triggered if someone tries to do dd from /proc/kcore.\neg. dd if=/proc/kcore of=/dev/null bs=1M\n\nSome example false negatives:\n\n ===============================\n BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0\n Invalid read at 0xc0000000fdff0000:\n copy_from_kernel_nofault+0x9c/0x1a0\n 0xc00000000665f950\n read_kcore_iter+0x57c/0xa04\n proc_reg_read_iter+0xe4/0x16c\n vfs_read+0x320/0x3ec\n ksys_read+0x90/0x154\n system_call_exception+0x120/0x310\n system_call_vectored_common+0x15c/0x2ec\n\n BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0\n Use-after-free read at 0xc0000000fe050000 (in kfence-#2):\n copy_from_kernel_nofault+0x9c/0x1a0\n 0xc00000000665f950\n read_kcore_iter+0x57c/0xa04\n proc_reg_read_iter+0xe4/0x16c\n vfs_read+0x320/0x3ec\n ksys_read+0x90/0x154\n system_call_exception+0x120/0x310\n system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur\n\nThe action force umount(umount -f) will attempt to kill all rpc_task even\numount operation may ultimately fail if some files remain open.\nConsequently, if an action attempts to open a file, it can potentially\nsend two rpc_task to nfs server.\n\n NFS CLIENT\nthread1 thread2\nopen(\u0026quot;file\u0026quot;)\n...\nnfs4_do_open\n _nfs4_do_open\n _nfs4_open_and_get_state\n _nfs4_proc_open\n nfs4_run_open_task\n /* rpc_task1 */\n rpc_run_task\n rpc_wait_for_completion_task\n\n umount -f\n nfs_umount_begin\n rpc_killall_tasks\n rpc_signal_task\n rpc_task1 been wakeup\n and return -512\n _nfs4_do_open // while loop\n ...\n nfs4_run_open_task\n /* rpc_task2 */\n rpc_run_task\n rpc_wait_for_completion_task\n\nWhile processing an open request, nfsd will first attempt to find or\nallocate an nfs4_openowner. If it finds an nfs4_openowner that is not\nmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since\ntwo rpc_task can attempt to open the same file simultaneously from the\nclient to server, and because two instances of nfsd can run\nconcurrently, this situation can lead to lots of memory leak.\nAdditionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be\ntriggered.\n\n NFS SERVER\nnfsd1 nfsd2 echo 0 \u0026gt; /proc/fs/nfsd/threads\n\nnfsd4_open\n nfsd4_process_open1\n find_or_alloc_open_stateowner\n // alloc oo1, stateid1\n nfsd4_open\n nfsd4_process_open1\n find_or_alloc_open_stateowner\n // find oo1, without NFS4_OO_CONFIRMED\n release_openowner\n unhash_openowner_locked\n list_del_init(\u0026amp;oo-\u0026gt;oo_perclient)\n // cannot find this oo\n // from client, LEAK!!!\n alloc_stateowner // alloc oo2\n\n nfsd4_process_open2\n init_open_stateid\n // associate oo1\n // with stateid1, stateid1 LEAK!!!\n nfs4_get_vfs_file\n // alloc nfsd_file1 and nfsd_file_mark1\n // all LEAK!!!\n\n nfsd4_process_open2\n ...\n\n write_threads\n ...\n nfsd_destroy_serv\n nfsd_shutdown_net\n nfs4_state_shutdown_net\n nfs4_state_destroy_net\n destroy_client\n __destroy_client\n // won\u0026apos;t find oo1!!!\n nfsd_shutdown_generic\n nfsd_file_cache_shutdown\n kmem_cache_destroy\n for nfsd_file_slab\n and nfsd_file_mark_slab\n // bark since nfsd_file1\n // and nfsd_file_mark1\n // still alive\n\n=======================================================================\nBUG nfsd_file (Not tainted): Objects remaining in nfsd_file on\n__kmem_cache_shutdown()\n-----------------------------------------------------------------------\n\nSlab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28\nflags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)\nCPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dum\n---truncated---(CVE-2024-56779)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: state: fix out-of-bounds read during lookup\n\nlookup and resize can run in parallel.\n\nThe xfrm_state_hash_generation seqlock ensures a retry, but the hash\nfunctions can observe a hmask value that is too large for the new hlist\narray.\n\nrehash does:\n rcu_assign_pointer(net-\u0026gt;xfrm.state_bydst, ndst) [..]\n net-\u0026gt;xfrm.state_hmask = nhashmask;\n\nWhile state lookup does:\n h = xfrm_dst_hash(net, daddr, saddr, tmpl-\u0026gt;reqid, encap_family);\n hlist_for_each_entry_rcu(x, net-\u0026gt;xfrm.state_bydst + h, bydst) {\n\nThis is only safe in case the update to state_bydst is larger than\nnet-\u0026gt;xfrm.xfrm_state_hmask (or if the lookup function gets\nserialized via state spinlock again).\n\nFix this by prefetching state_hmask and the associated pointers.\nThe xfrm_state_hash_generation seqlock retry will ensure that the pointer\nand the hmask will be consistent.\n\nThe existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,\nadd lockdep assertions to document that they are only safe for insert\nside.\n\nxfrm_state_lookup_byaddr() uses the spinlock rather than RCU.\nAFAICS this is an oversight from back when state lookup was converted to\nRCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/platform: check the bounds of read/write syscalls\n\ncount and offset are passed from user space and not checked, only\noffset is capped to 40 bits, which can be used to read/write out of\nbounds of the device.(CVE-2025-21687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: Fix NULL pointer dereference\n\nWhen MPOA_cache_impos_rcvd() receives the msg, it can trigger\nNull Pointer Dereference Vulnerability if both entry and\nholding_time are NULL. Because there is only for the situation\nwhere entry is NULL and holding_time exists, it can be passed\nwhen both entry and holding_time are NULL. If these are NULL,\nthe entry will be passd to eg_cache_put() as parameter and\nit is referenced by entry-\u0026gt;use code in it.\n\nkasan log:\n\n[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I\n[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102\n[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470\n[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80\n[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006\n[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e\n[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030\n[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88\n[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15\n[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068\n[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000\n[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0\n[ 3.326430] Call Trace:\n[ 3.326725] \u0026lt;TASK\u0026gt;\n[ 3.326927] ? die_addr+0x3c/0xa0\n[ 3.327330] ? exc_general_protection+0x161/0x2a0\n[ 3.327662] ? asm_exc_general_protection+0x26/0x30\n[ 3.328214] ? vprintk_emit+0x15e/0x420\n[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470\n[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470\n[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10\n[ 3.329664] ? console_unlock+0x107/0x1d0\n[ 3.329946] ? __pfx_console_unlock+0x10/0x10\n[ 3.330283] ? do_syscall_64+0xa6/0x1a0\n[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f\n[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10\n[ 3.331395] ? down_trylock+0x52/0x80\n[ 3.331703] ? vprintk_emit+0x15e/0x420\n[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10\n[ 3.332279] ? down_trylock+0x52/0x80\n[ 3.332527] ? _printk+0xbf/0x100\n[ 3.332762] ? __pfx__printk+0x10/0x10\n[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0\n[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10\n[ 3.333614] msg_from_mpoad+0x1185/0x2750\n[ 3.333893] ? __build_skb_around+0x27b/0x3a0\n[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10\n[ 3.334501] ? __alloc_skb+0x1c0/0x310\n[ 3.334809] ? __pfx___alloc_skb+0x10/0x10\n[ 3.335283] ? _raw_spin_lock+0xe0/0xe0\n[ 3.335632] ? finish_wait+0x8d/0x1e0\n[ 3.335975] vcc_sendmsg+0x684/0xba0\n[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10\n[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10\n[ 3.337056] ? fdget+0x176/0x3e0\n[ 3.337348] __sys_sendto+0x4a2/0x510\n[ 3.337663] ? __pfx___sys_sendto+0x10/0x10\n[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400\n[ 3.338364] ? sock_ioctl+0x1bb/0x5a0\n[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20\n[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10\n[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10\n[ 3.339727] ? selinux_file_ioctl+0xa4/0x260\n[ 3.340166] __x64_sys_sendto+0xe0/0x1c0\n[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140\n[ 3.340898] do_syscall_64+0xa6/0x1a0\n[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 3.341533] RIP: 0033:0x44a380\n[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00\n[ \n---truncated---(CVE-2025-22018)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix memory accounting leak.\n\nMatt Dowling reported a weird UDP memory usage issue.\n\nUnder normal operation, the UDP memory usage reported in /proc/net/sockstat\nremains close to zero. However, it occasionally spiked to 524,288 pages\nand never dropped. Moreover, the value doubled when the application was\nterminated. Finally, it caused intermittent packet drops.\n\nWe can reproduce the issue with the script below [0]:\n\n 1. /proc/net/sockstat reports 0 pages\n\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 0\n\n 2. Run the script till the report reaches 524,288\n\n # python3 test.py \u0026amp; sleep 5\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 3 mem 524288 \u0026lt;-- (INT_MAX + 1) \u0026gt;\u0026gt; PAGE_SHIFT\n\n 3. Kill the socket and confirm the number never drops\n\n # pkill python3 \u0026amp;\u0026amp; sleep 5\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 524288\n\n 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()\n\n # python3 test.py \u0026amp; sleep 1 \u0026amp;\u0026amp; pkill python3\n\n 5. The number doubles\n\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 1048577\n\nThe application set INT_MAX to SO_RCVBUF, which triggered an integer\noverflow in udp_rmem_release().\n\nWhen a socket is close()d, udp_destruct_common() purges its receive\nqueue and sums up skb-\u0026gt;truesize in the queue. This total is calculated\nand stored in a local unsigned integer variable.\n\nThe total size is then passed to udp_rmem_release() to adjust memory\naccounting. However, because the function takes a signed integer\nargument, the total size can wrap around, causing an overflow.\n\nThen, the released amount is calculated as follows:\n\n 1) Add size to sk-\u0026gt;sk_forward_alloc.\n 2) Round down sk-\u0026gt;sk_forward_alloc to the nearest lower multiple of\n PAGE_SIZE and assign it to amount.\n 3) Subtract amount from sk-\u0026gt;sk_forward_alloc.\n 4) Pass amount \u0026gt;\u0026gt; PAGE_SHIFT to __sk_mem_reduce_allocated().\n\nWhen the issue occurred, the total in udp_destruct_common() was 2147484480\n(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().\n\nAt 1) sk-\u0026gt;sk_forward_alloc is changed from 3264 to -2147479552, and\n2) sets -2147479552 to amount. 3) reverts the wraparound, so we don\u0026apos;t\nsee a warning in inet_sock_destruct(). However, udp_memory_allocated\nends up doubling at 4).\n\nSince commit 3cd3399dd7a8 (\u0026quot;net: implement per-cpu reserves for\nmemory_allocated\u0026quot;), memory usage no longer doubles immediately after\na socket is close()d because __sk_mem_reduce_allocated() caches the\namount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP\nsocket receives a packet, the subtraction takes effect, causing UDP\nmemory usage to double.\n\nThis issue makes further memory allocation fail once the socket\u0026apos;s\nsk-\u0026gt;sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet\ndrops.\n\nTo prevent this issue, let\u0026apos;s use unsigned int for the calculation and\ncall sk_forward_alloc_add() only once for the small delta.\n\nNote that first_packet_length() also potentially has the same problem.\n\n[0]:\nfrom socket import *\n\nSO_RCVBUFFORCE = 33\nINT_MAX = (2 ** 31) - 1\n\ns = socket(AF_INET, SOCK_DGRAM)\ns.bind((\u0026apos;\u0026apos;, 0))\ns.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)\n\nc = socket(AF_INET, SOCK_DGRAM)\nc.connect(s.getsockname())\n\ndata = b\u0026apos;a\u0026apos; * 100\n\nwhile True:\n c.send(data)(CVE-2025-22058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtnetlink: Allocate vfinfo size for VF GUIDs when supported\n\nCommit 30aad41721e0 (\u0026quot;net/core: Add support for getting VF GUIDs\u0026quot;)\nadded support for getting VF port and node GUIDs in netlink ifinfo\nmessages, but their size was not taken into consideration in the\nfunction that allocates the netlink message, causing the following\nwarning when a netlink message is filled with many VF port and node\nGUIDs:\n # echo 64 \u0026gt; /sys/bus/pci/devices/0000\\:08\\:00.0/sriov_numvfs\n # ip link show dev ib0\n RTNETLINK answers: Message too long\n Cannot send link get request: Message too long\n\nKernel warning:\n\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0\n Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core\n CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:rtnl_getlink+0x586/0x5a0\n Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff \u0026lt;0f\u0026gt; 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00\n RSP: 0018:ffff888113557348 EFLAGS: 00010246\n RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000\n RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8\n RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000\n R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00\n R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff\n FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn+0xa5/0x230\n ? rtnl_getlink+0x586/0x5a0\n ? report_bug+0x22d/0x240\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x14/0x50\n ? asm_exc_invalid_op+0x16/0x20\n ? skb_trim+0x6a/0x80\n ? rtnl_getlink+0x586/0x5a0\n ? __pfx_rtnl_getlink+0x10/0x10\n ? rtnetlink_rcv_msg+0x1e5/0x860\n ? __pfx___mutex_lock+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? __pfx_lock_acquire+0x10/0x10\n ? stack_trace_save+0x90/0xd0\n ? filter_irq_stacks+0x1d/0x70\n ? kasan_save_stack+0x30/0x40\n ? kasan_save_stack+0x20/0x40\n ? kasan_save_track+0x10/0x30\n rtnetlink_rcv_msg+0x21c/0x860\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n ? arch_stack_walk+0x9e/0xf0\n ? rcu_is_watching+0x34/0x60\n ? lock_acquire+0xd5/0x410\n ? rcu_is_watching+0x34/0x60\n netlink_rcv_skb+0xe0/0x210\n ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n ? __pfx_netlink_rcv_skb+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? __pfx___netlink_lookup+0x10/0x10\n ? lock_release+0x62/0x200\n ? netlink_deliver_tap+0xfd/0x290\n ? rcu_is_watching+0x34/0x60\n ? lock_release+0x62/0x200\n ? netlink_deliver_tap+0x95/0x290\n netlink_unicast+0x31f/0x480\n ? __pfx_netlink_unicast+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? lock_acquire+0xd5/0x410\n netlink_sendmsg+0x369/0x660\n ? lock_release+0x62/0x200\n ? __pfx_netlink_sendmsg+0x10/0x10\n ? import_ubuf+0xb9/0xf0\n ? __import_iovec+0x254/0x2b0\n ? lock_release+0x62/0x200\n ? __pfx_netlink_sendmsg+0x10/0x10\n ____sys_sendmsg+0x559/0x5a0\n ? __pfx_____sys_sendmsg+0x10/0x10\n ? __pfx_copy_msghdr_from_user+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? do_read_fault+0x213/0x4a0\n ? rcu_is_watching+0x34/0x60\n ___sys_sendmsg+0xe4/0x150\n ? __pfx____sys_sendmsg+0x10/0x10\n ? do_fault+0x2cc/0x6f0\n ? handle_pte_fault+0x2e3/0x3d0\n ? __pfx_handle_pte_fault+0x10/0x10\n---truncated---(CVE-2025-22075)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisofs: Prevent the use of too small fid\n\nsyzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]\n\nThe handle_bytes value passed in by the reproducing program is equal to 12.\nIn handle_to_path(), only 12 bytes of memory are allocated for the structure\nfile_handle-\u0026gt;f_handle member, which causes an out-of-bounds access when\naccessing the member parent_block of the structure isofs_fid in isofs,\nbecause accessing parent_block requires at least 16 bytes of f_handle.\nHere, fh_len is used to indirectly confirm that the value of handle_bytes\nis greater than 3 before accessing parent_block.\n\n[1]\nBUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183\nRead of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466\nCPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025\nCall trace:\n show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0x198/0x550 mm/kasan/report.c:521\n kasan_report+0xd8/0x138 mm/kasan/report.c:634\n __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380\n isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183\n exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523\n do_handle_to_path+0xa0/0x198 fs/fhandle.c:257\n handle_to_path fs/fhandle.c:385 [inline]\n do_handle_open+0x8cc/0xb8c fs/fhandle.c:403\n __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]\n __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]\n __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n\nAllocated by task 6466:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x40/0x78 mm/kasan/common.c:68\n kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4294 [inline]\n __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306\n kmalloc_noprof include/linux/slab.h:905 [inline]\n handle_to_path fs/fhandle.c:357 [inline]\n do_handle_open+0x5a4/0xb8c fs/fhandle.c:403\n __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]\n __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]\n __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600(CVE-2025-37780)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class handling\n\nThis patch fixes a Use-After-Free vulnerability in the HFSC qdisc class\nhandling. The issue occurs due to a time-of-check/time-of-use condition\nin hfsc_change_class() when working with certain child qdiscs like netem\nor codel.\n\nThe vulnerability works as follows:\n1. hfsc_change_class() checks if a class has packets (q.qlen != 0)\n2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g.,\n codel, netem) might drop packets and empty the queue\n3. The code continues assuming the queue is still non-empty, adding\n the class to vttree\n4. This breaks HFSC scheduler assumptions that only non-empty classes\n are in vttree\n5. Later, when the class is destroyed, this can lead to a Use-After-Free\n\nThe fix adds a second queue length check after qdisc_peek_len() to verify\nthe queue wasn\u0026apos;t emptied.(CVE-2025-37797)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc\n\nAs described in Gerrard\u0026apos;s report [1], we have a UAF case when an hfsc class\nhas a netem child qdisc. The crux of the issue is that hfsc is assuming\nthat checking for cl-\u0026gt;qdisc-\u0026gt;q.qlen == 0 guarantees that it hasn\u0026apos;t inserted\nthe class in the vttree or eltree (which is not true for the netem\nduplicate case).\n\nThis patch checks the n_active class variable to make sure that the code\nwon\u0026apos;t insert the class in the vttree or eltree twice, catering for the\nreentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37890)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()\n\nWhen enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the\nchild qdisc\u0026apos;s peek() operation before incrementing sch-\u0026gt;q.qlen and\nsch-\u0026gt;qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may\ntrigger an immediate dequeue and potential packet drop. In such cases,\nqdisc_tree_reduce_backlog() is called, but the HFSC qdisc\u0026apos;s qlen and backlog\nhave not yet been updated, leading to inconsistent queue accounting. This\ncan leave an empty HFSC class in the active list, causing further\nconsequences like use-after-free.\n\nThis patch fixes the bug by moving the increment of sch-\u0026gt;q.qlen and\nsch-\u0026gt;qstats.backlog before the call to the child qdisc\u0026apos;s peek() operation.\nThis ensures that queue length and backlog are always accurate when packet\ndrops or dequeues are triggered during the peek.(CVE-2025-38000)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Address reentrant enqueue adding class to eltree twice\n\nSavino says:\n \u0026quot;We are writing to report that this recent patch\n (141d34391abbb315d68556b7c67ad97885407547) [1]\n can be bypassed, and a UAF can still occur when HFSC is utilized with\n NETEM.\n\n The patch only checks the cl-\u0026gt;cl_nactive field to determine whether\n it is the first insertion or not [2], but this field is only\n incremented by init_vf [3].\n\n By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the\n check and insert the class twice in the eltree.\n Under normal conditions, this would lead to an infinite loop in\n hfsc_dequeue for the reasons we already explained in this report [5].\n\n However, if TBF is added as root qdisc and it is configured with a\n very low rate,\n it can be utilized to prevent packets from being dequeued.\n This behavior can be exploited to perform subsequent insertions in the\n HFSC eltree and cause a UAF.\u0026quot;\n\nTo fix both the UAF and the infinite loop, with netem as an hfsc child,\ncheck explicitly in hfsc_enqueue whether the class is already in the eltree\nwhenever the HFSC_RSC flag is set.\n\n[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547\n[2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572\n[3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677\n[4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574\n[5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u(CVE-2025-38001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\n\nSyzbot reported a slab-use-after-free with the following call trace:\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840\n Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25\n\n Call Trace:\n kasan_report+0xd9/0x110 mm/kasan/report.c:601\n tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840\n crypto_request_complete include/crypto/algapi.h:266\n aead_request_complete include/crypto/internal/aead.h:85\n cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772\n crypto_request_complete include/crypto/algapi.h:266\n cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181\n process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n\n Allocated by task 8355:\n kzalloc_noprof include/linux/slab.h:778\n tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466\n tipc_init_net+0x2dd/0x430 net/tipc/core.c:72\n ops_init+0xb9/0x650 net/core/net_namespace.c:139\n setup_net+0x435/0xb40 net/core/net_namespace.c:343\n copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508\n create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110\n unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228\n ksys_unshare+0x419/0x970 kernel/fork.c:3323\n __do_sys_unshare kernel/fork.c:3394\n\n Freed by task 63:\n kfree+0x12a/0x3b0 mm/slub.c:4557\n tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539\n tipc_exit_net+0x8c/0x110 net/tipc/core.c:119\n ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173\n cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640\n process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n\nAfter freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done\nmay still visit it in cryptd_queue_worker workqueue.\n\nI reproduce this issue by:\n ip netns add ns1\n ip link add veth1 type veth peer name veth2\n ip link set veth1 netns ns1\n ip netns exec ns1 tipc bearer enable media eth dev veth1\n ip netns exec ns1 tipc node set key this_is_a_master_key master\n ip netns exec ns1 tipc bearer disable media eth dev veth1\n ip netns del ns1\n\nThe key of reproduction is that, simd_aead_encrypt is interrupted, leading\nto crypto_simd_usable() return false. Thus, the cryptd_queue_worker is\ntriggered, and the tipc_crypto tx will be visited.\n\n tipc_disc_timeout\n tipc_bearer_xmit_skb\n tipc_crypto_xmit\n tipc_aead_encrypt\n crypto_aead_encrypt\n // encrypt()\n simd_aead_encrypt\n // crypto_simd_usable() is false\n child = \u0026amp;ctx-\u0026gt;cryptd_tfm-\u0026gt;base;\n\n simd_aead_encrypt\n crypto_aead_encrypt\n // encrypt()\n cryptd_aead_encrypt_enqueue\n cryptd_aead_enqueue\n cryptd_enqueue_request\n // trigger cryptd_queue_worker\n queue_work_on(smp_processor_id(), cryptd_wq, \u0026amp;cpu_queue-\u0026gt;work)\n\nFix this by holding net reference count before encrypt.(CVE-2025-38052)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc1 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch c337efb20d6d9f9bbb4746f6b119917af5c886dc/b44f791f27b14c9eb6b907fbe51f2ba8bec32085/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72/9c19498bdd7cb9d854bd3c54260f71cf7408495e/b4e9bab6011b9559b7c157b16b91ae46d4d8c533/d1bc80da75c789f2f6830df89d91fb2f7a509943/82448d4dcd8406dec688632a405fdcf7f170ec69/82ffbe7776d0ac084031f114167712269bf3d832 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38115)\n\nLinux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States.\n There is a security vulnerability in Linux kernel, which originates from improper processing of udp gso segmentation, which may lead to memory corruption.(CVE-2025-38124)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer\n\nThe reproduction steps:\n1. create a tun interface\n2. enable l2 bearer\n3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun\n\ntipc: Started in network mode\ntipc: Node identity 8af312d38a21, cluster identity 4711\ntipc: Enabled bearer \u0026lt;eth:syz_tun\u0026gt;, priority 1\nOops: general protection fault\nKASAN: null-ptr-deref in range\nCPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT\nHardware name: QEMU Ubuntu 24.04 PC\nRIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0\n\nthe ub was in fact a struct dev.\n\nwhen bid != 0 \u0026amp;\u0026amp; skip_cnt != 0, bearer_list[bid] may be NULL or\nother media when other thread changes it.\n\nfix this by checking media_id.(CVE-2025-38184)\n\nA vulnerability classified as critical has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc1 (Operating System).CWE is classifying the issue as CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.This is going to have an impact on availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc2 eliminates this vulnerability. Applying the patch bfa4d86e130a09f67607482e988313430e38f6c4/2a3ad42a57b43145839f2f233fb562247658a6d9/e9994e7b9f7bbb882d13c8191731649249150d21/ba9db6f907ac02215e30128770f85fbd7db2fcf9 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20064).(CVE-2025-38192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1: Fix stack memory use after return in raid1_reshape\n\nIn the raid1_reshape function, newpool is\nallocated on the stack and assigned to conf-\u0026gt;r1bio_pool.\nThis results in conf-\u0026gt;r1bio_pool.wait.head pointing\nto a stack address.\nAccessing this address later can lead to a kernel panic.\n\nExample access path:\n\nraid1_reshape()\n{\n\t// newpool is on the stack\n\tmempool_t newpool, oldpool;\n\t// initialize newpool.wait.head to stack address\n\tmempool_init(\u0026amp;newpool, ...);\n\tconf-\u0026gt;r1bio_pool = newpool;\n}\n\nraid1_read_request() or raid1_write_request()\n{\n\talloc_r1bio()\n\t{\n\t\tmempool_alloc()\n\t\t{\n\t\t\t// if pool-\u0026gt;alloc fails\n\t\t\tremove_element()\n\t\t\t{\n\t\t\t\t--pool-\u0026gt;curr_nr;\n\t\t\t}\n\t\t}\n\t}\n}\n\nmempool_free()\n{\n\tif (pool-\u0026gt;curr_nr \u0026lt; pool-\u0026gt;min_nr) {\n\t\t// pool-\u0026gt;wait.head is a stack address\n\t\t// wake_up() will try to access this invalid address\n\t\t// which leads to a kernel panic\n\t\treturn;\n\t\twake_up(\u0026amp;pool-\u0026gt;wait);\n\t}\n}\n\nFix:\nreinit conf-\u0026gt;r1bio_pool.wait after assigning newpool.(CVE-2025-38445)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free in tipc_conn_close().\n\nsyzbot reported a null-ptr-deref in tipc_conn_close() during netns\ndismantle. [0]\n\ntipc_topsrv_stop() iterates tipc_net(net)-\u0026gt;topsrv-\u0026gt;conn_idr and calls\ntipc_conn_close() for each tipc_conn.\n\nThe problem is that tipc_conn_close() is called after releasing the\nIDR lock.\n\nAt the same time, there might be tipc_conn_recv_work() running and it\ncould call tipc_conn_close() for the same tipc_conn and release its\nlast -\u0026gt;kref.\n\nOnce we release the IDR lock in tipc_topsrv_stop(), there is no\nguarantee that the tipc_conn is alive.\n\nLet\u0026apos;s hold the ref before releasing the lock and put the ref after\ntipc_conn_close() in tipc_topsrv_stop().\n\n[0]:\nBUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165\nRead of size 8 at addr ffff888099305a08 by task kworker/u4:3/435\n\nCPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: netns cleanup_net\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x1fc/0x2ef lib/dump_stack.c:118\n print_address_description.cold+0x54/0x219 mm/kasan/report.c:256\n kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354\n kasan_report mm/kasan/report.c:412 [inline]\n __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433\n tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165\n tipc_topsrv_stop net/tipc/topsrv.c:701 [inline]\n tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722\n ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153\n cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nAllocated by task 23:\n kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625\n kmalloc include/linux/slab.h:515 [inline]\n kzalloc include/linux/slab.h:709 [inline]\n tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192\n tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nFreed by task 23:\n __cache_free mm/slab.c:3503 [inline]\n kfree+0xcc/0x210 mm/slab.c:3822\n tipc_conn_kref_release net/tipc/topsrv.c:150 [inline]\n kref_put include/linux/kref.h:70 [inline]\n conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nThe buggy address belongs to the object at ffff888099305a00\n which belongs to the cache kmalloc-512 of size 512\nThe buggy address is located 8 bytes inside of\n 512-byte region [ffff888099305a00, ffff888099305c00)\nThe buggy address belongs to the page:\npage:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0\nflags: 0xfff00000000100(slab)\nraw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940\nraw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n\u0026gt;ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ^\n ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb(CVE-2025-38464)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc5 (Operating System). It has been classified as problematic.CWE is classifying the issue as CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99, 6.12.39, 6.15.7 or 6.16-rc6 eliminates this vulnerability. Applying the patch 9da025150b7c14a8390fc06aea314c0a4011e82c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98/fd69af06101090eaa60b3d216ae715f9c0a58e5b/76602d8e13864524382b0687dc32cd8f19164d5a/55baecb9eb90238f60a8350660d6762046ebd3bd/4b8e18af7bea92f8b7fb92d40aeae729209db250/cd7ff61bfffd7000143c42bbffb85eeb792466d6/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38465)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Add down_write(trace_event_sem) when adding trace event\n\nWhen a module is loaded, it adds trace events defined by the module. It\nmay also need to modify the modules trace printk formats to replace enum\nnames with their values.\n\nIf two modules are loaded at the same time, the adding of the event to the\nftrace_events list can corrupt the walking of the list in the code that is\nmodifying the printk format strings and crash the kernel.\n\nThe addition of the event should take the trace_event_sem for write while\nit adds the new event.\n\nAlso add a lockdep_assert_held() on that semaphore in\n__trace_add_event_dirs() as it iterates the list.(CVE-2025-38539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Exit early on perf_mmap() fail\n\nWhen perf_mmap() fails to allocate a buffer, it still invokes the\nevent_mapped() callback of the related event. On X86 this might increase\nthe perf_rdpmc_allowed reference counter. But nothing undoes this as\nperf_mmap_close() is never called in this case, which causes another\nreference count leak.\n\nReturn early on failure to prevent that.(CVE-2025-38565)\n\nA vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.100/6.12.40/6.15.8 (Operating System).Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.Upgrading to version 6.6.101, 6.12.41 or 6.15.9 eliminates this vulnerability. Applying the patch 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61/708fd522b86d2a9544c34ec6a86fa3fc23336525/0f67015d72627bad72da3c2084352e0aa134416b/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38670)",
"id": "OESA-2025-2081",
"modified": "2026-08-06T11:09:09Z",
"published": "2025-08-29T11:09:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49377"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49390"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56779"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58069"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21687"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22018"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22058"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22075"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37780"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37797"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37890"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38115"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38124"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38184"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38445"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38464"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38465"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38539"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38565"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38670"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49377",
"CVE-2022-49390",
"CVE-2023-52924",
"CVE-2024-56678",
"CVE-2024-56779",
"CVE-2024-57982",
"CVE-2024-58069",
"CVE-2025-21687",
"CVE-2025-22018",
"CVE-2025-22058",
"CVE-2025-22075",
"CVE-2025-37780",
"CVE-2025-37797",
"CVE-2025-37890",
"CVE-2025-38000",
"CVE-2025-38001",
"CVE-2025-38052",
"CVE-2025-38115",
"CVE-2025-38124",
"CVE-2025-38184",
"CVE-2025-38192",
"CVE-2025-38445",
"CVE-2025-38464",
"CVE-2025-38465",
"CVE-2025-38539",
"CVE-2025-38565",
"CVE-2025-38670"
]
}
OESA-2025-2082 (CVE-2022-49377)
Vulnerability from osv_openeuler – Published: 2025-08-29 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx
blk_mq_run_hw_queues() could be run when there isn't queued request and after queue is cleaned up, at that time tagset is freed, because tagset lifetime is covered by driver, and often freed after blk_cleanup_queue() returns.
So don't touch ->tagset for figuring out current default hctx by the mapping built in request queue, so use-after-free on tagset can be avoided. Meantime this way should be fast than retrieving mapping from tagset.(CVE-2022-49377)
In the Linux kernel, the following vulnerability has been resolved:
macsec: fix UAF bug for real_dev
Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following:
================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161
Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748
Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327
After commit faab39f63c1f ("net: allow out-of-order netdev unregistration") and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.(CVE-2022-49390)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm/fault: Fix kfence page fault reporting
copy_from_kernel_nofault() can be called when doing read of /proc/kcore. /proc/kcore can have some unmapped kfence objects which when read via copy_from_kernel_nofault() can cause page faults. Since *_nofault() functions define their own fixup table for handling fault, use that instead of asking kfence to handle such faults.
Hence we search the exception tables for the nip which generated the fault. If there is an entry then we let the fixup table handler handle the page fault by returning an error from within ___do_page_fault().
This can be easily triggered if someone tries to do dd from /proc/kcore. eg. dd if=/proc/kcore of=/dev/null bs=1M
Some example false negatives:
=============================== BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0 Invalid read at 0xc0000000fdff0000: copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec
BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0 Use-after-free read at 0xc0000000fe050000 (in kfence-#2): copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur
The action force umount(umount -f) will attempt to kill all rpc_task even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpc_task to nfs server.
NFS CLIENT
thread1 thread2 open("file") ... nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task / rpc_task1 / rpc_run_task rpc_wait_for_completion_task
umount -f
nfs_umount_begin
rpc_killall_tasks
rpc_signal_task
rpc_task1 been wakeup
and return -512
_nfs4_do_open // while loop ... nfs4_run_open_task / rpc_task2 / rpc_run_task rpc_wait_for_completion_task
While processing an open request, nfsd will first attempt to find or allocate an nfs4_openowner. If it finds an nfs4_openowner that is not marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since two rpc_task can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered.
NFS SERVER
nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads
nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2
nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!!
nfsd4_process_open2
...
write_threads
...
nfsd_destroy_serv
nfsd_shutdown_net
nfs4_state_shutdown_net
nfs4_state_destroy_net
destroy_client
__destroy_client
// won't find oo1!!!
nfsd_shutdown_generic
nfsd_file_cache_shutdown
kmem_cache_destroy
for nfsd_file_slab
and nfsd_file_mark_slab
// bark since nfsd_file1
// and nfsd_file_mark1
// still alive
======================================================================= BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown()
Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dum ---truncated---(CVE-2024-56779)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: state: fix out-of-bounds read during lookup
lookup and resize can run in parallel.
The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array.
rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask;
While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {
This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again).
Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent.
The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side.
xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)
In the Linux kernel, the following vulnerability has been resolved:
rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read
The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int.
Fix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: check the bounds of read/write syscalls
count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.(CVE-2025-21687)
In the Linux kernel, the following vulnerability has been resolved:
atm: Fix NULL pointer dereference
When MPOA_cache_impos_rcvd() receives the msg, it can trigger Null Pointer Dereference Vulnerability if both entry and holding_time are NULL. Because there is only for the situation where entry is NULL and holding_time exists, it can be passed when both entry and holding_time are NULL. If these are NULL, the entry will be passd to eg_cache_put() as parameter and it is referenced by entry->use code in it.
kasan log:
[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I
[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102
[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470
[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80
[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006
[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e
[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030
[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88
[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15
[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068
[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000
[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0
[ 3.326430] Call Trace:
[ 3.326725] <TASK>
[ 3.326927] ? die_addr+0x3c/0xa0
[ 3.327330] ? exc_general_protection+0x161/0x2a0
[ 3.327662] ? asm_exc_general_protection+0x26/0x30
[ 3.328214] ? vprintk_emit+0x15e/0x420
[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470
[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470
[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10
[ 3.329664] ? console_unlock+0x107/0x1d0
[ 3.329946] ? __pfx_console_unlock+0x10/0x10
[ 3.330283] ? do_syscall_64+0xa6/0x1a0
[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f
[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10
[ 3.331395] ? down_trylock+0x52/0x80
[ 3.331703] ? vprintk_emit+0x15e/0x420
[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10
[ 3.332279] ? down_trylock+0x52/0x80
[ 3.332527] ? _printk+0xbf/0x100
[ 3.332762] ? __pfx__printk+0x10/0x10
[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0
[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10
[ 3.333614] msg_from_mpoad+0x1185/0x2750
[ 3.333893] ? __build_skb_around+0x27b/0x3a0
[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10
[ 3.334501] ? __alloc_skb+0x1c0/0x310
[ 3.334809] ? __pfxallocskb+0x10/0x10
[ 3.335283] ? _raw_spin_lock+0xe0/0xe0
[ 3.335632] ? finish_wait+0x8d/0x1e0
[ 3.335975] vcc_sendmsg+0x684/0xba0
[ 3.336250] ? pfx_vcc_sendmsg+0x10/0x10
[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10
[ 3.337056] ? fdget+0x176/0x3e0
[ 3.337348] __sys_sendto+0x4a2/0x510
[ 3.337663] ? __pfxsyssendto+0x10/0x10
[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400
[ 3.338364] ? sock_ioctl+0x1bb/0x5a0
[ 3.338653] ? rseq_handle_notify_resume+0x825/0xd20
[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10
[ 3.339316] ? __pfxrseqhandle_notify_resume+0x10/0x10
[ 3.339727] ? selinux_file_ioctl+0xa4/0x260
[ 3.340166] x64_sys_sendto+0xe0/0x1c0
[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140
[ 3.340898] do_syscall_64+0xa6/0x1a0
[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 3.341533] RIP: 0033:0x44a380
[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00
[
---truncated---(CVE-2025-22018)
In the Linux kernel, the following vulnerability has been resolved:
udp: Fix memory accounting leak.
Matt Dowling reported a weird UDP memory usage issue.
Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops.
We can reproduce the issue with the script below [0]:
-
/proc/net/sockstat reports 0 pages
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 0
-
Run the script till the report reaches 524,288
python3 test.py & sleep 5
cat /proc/net/sockstat | grep UDP:
UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT
-
Kill the socket and confirm the number never drops
pkill python3 && sleep 5
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 524288
-
(necessary since v6.0) Trigger proto_memory_pcpu_drain()
python3 test.py & sleep 1 && pkill python3
-
The number doubles
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 1048577
The application set INT_MAX to SO_RCVBUF, which triggered an integer overflow in udp_rmem_release().
When a socket is close()d, udp_destruct_common() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable.
The total size is then passed to udp_rmem_release() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow.
Then, the released amount is calculated as follows:
1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().
When the issue occurred, the total in udp_destruct_common() was 2147484480 (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().
At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inet_sock_destruct(). However, udp_memory_allocated ends up doubling at 4).
Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated"), memory usage no longer doubles immediately after a socket is close()d because __sk_mem_reduce_allocated() caches the amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double.
This issue makes further memory allocation fail once the socket's sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet drops.
To prevent this issue, let's use unsigned int for the calculation and call sk_forward_alloc_add() only once for the small delta.
Note that first_packet_length() also potentially has the same problem.
[0]: from socket import *
SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1
s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)
c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname())
data = b'a' * 100
while True: c.send(data)(CVE-2025-22058)
In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Allocate vfinfo size for VF GUIDs when supported
Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs") added support for getting VF port and node GUIDs in netlink ifinfo messages, but their size was not taken into consideration in the function that allocates the netlink message, causing the following warning when a netlink message is filled with many VF port and node GUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too long
Kernel warning:
------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfxmutexlock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfxnetlinklookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 _syssendmsg+0x559/0x5a0 ? pfx_sys_sendmsg+0x10/0x10 ? pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 syssendmsg+0xe4/0x150 ? pfx_syssendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? pfx_handle_pte_fault+0x10/0x10 ---truncated---(CVE-2025-22075)
In the Linux kernel, the following vulnerability has been resolved:
isofs: Prevent the use of too small fid
syzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]
The handle_bytes value passed in by the reproducing program is equal to 12. In handle_to_path(), only 12 bytes of memory are allocated for the structure file_handle->f_handle member, which causes an out-of-bounds access when accessing the member parent_block of the structure isofs_fid in isofs, because accessing parent_block requires at least 16 bytes of f_handle. Here, fh_len is used to indirectly confirm that the value of handle_bytes is greater than 3 before accessing parent_block.
[1] BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466 CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600(CVE-2025-37780)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a UAF vulnerability in class handling
This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class handling. The issue occurs due to a time-of-check/time-of-use condition in hfsc_change_class() when working with certain child qdiscs like netem or codel.
The vulnerability works as follows: 1. hfsc_change_class() checks if a class has packets (q.qlen != 0) 2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g., codel, netem) might drop packets and empty the queue 3. The code continues assuming the queue is still non-empty, adding the class to vttree 4. This breaks HFSC scheduler assumptions that only non-empty classes are in vttree 5. Later, when the class is destroyed, this can lead to a Use-After-Free
The fix adds a second queue length check after qdisc_peek_len() to verify the queue wasn't emptied.(CVE-2025-37797)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc
As described in Gerrard's report [1], we have a UAF case when an hfsc class has a netem child qdisc. The crux of the issue is that hfsc is assuming that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted the class in the vttree or eltree (which is not true for the netem duplicate case).
This patch checks the n_active class variable to make sure that the code won't insert the class in the vttree or eltree twice, catering for the reentrant case.
[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37890)
In the Linux kernel, the following vulnerability has been resolved:
sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()
When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the child qdisc's peek() operation before incrementing sch->q.qlen and sch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may trigger an immediate dequeue and potential packet drop. In such cases, qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to inconsistent queue accounting. This can leave an empty HFSC class in the active list, causing further consequences like use-after-free.
This patch fixes the bug by moving the increment of sch->q.qlen and sch->qstats.backlog before the call to the child qdisc's peek() operation. This ensures that queue length and backlog are always accurate when packet drops or dequeues are triggered during the peek.(CVE-2025-38000)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Address reentrant enqueue adding class to eltree twice
Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM.
The patch only checks the cl->cl_nactive field to determine whether
it is the first insertion or not [2], but this field is only
incremented by init_vf [3].
By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the
check and insert the class twice in the eltree.
Under normal conditions, this would lead to an infinite loop in
hfsc_dequeue for the reasons we already explained in this report [5].
However, if TBF is added as root qdisc and it is configured with a
very low rate,
it can be utilized to prevent packets from being dequeued.
This behavior can be exploited to perform subsequent insertions in the
HFSC eltree and cause a UAF."
To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfsc_enqueue whether the class is already in the eltree whenever the HFSC_RSC flag is set.
[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u(CVE-2025-38001)
In the Linux kernel, the following vulnerability has been resolved:
net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done
Syzbot reported a slab-use-after-free with the following call trace:
================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25
Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394
Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue.
I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1
The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited.
tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base;
simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work)
Fix this by holding net reference count before encrypt.(CVE-2025-38052)
A vulnerability was found in Linux Kernel up to 6.16-rc1 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch c337efb20d6d9f9bbb4746f6b119917af5c886dc/b44f791f27b14c9eb6b907fbe51f2ba8bec32085/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72/9c19498bdd7cb9d854bd3c54260f71cf7408495e/b4e9bab6011b9559b7c157b16b91ae46d4d8c533/d1bc80da75c789f2f6830df89d91fb2f7a509943/82448d4dcd8406dec688632a405fdcf7f170ec69/82ffbe7776d0ac084031f114167712269bf3d832 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38115)
Linux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States. There is a security vulnerability in Linux kernel, which originates from improper processing of udp gso segmentation, which may lead to memory corruption.(CVE-2025-38124)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer
The reproduction steps: 1. create a tun interface 2. enable l2 bearer 3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun
tipc: Started in network mode tipc: Node identity 8af312d38a21, cluster identity 4711 tipc: Enabled bearer <eth:syz_tun>, priority 1 Oops: general protection fault KASAN: null-ptr-deref in range CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT Hardware name: QEMU Ubuntu 24.04 PC RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0
the ub was in fact a struct dev.
when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or other media when other thread changes it.
fix this by checking media_id.(CVE-2025-38184)
A vulnerability classified as critical has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc1 (Operating System).CWE is classifying the issue as CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.This is going to have an impact on availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc2 eliminates this vulnerability. Applying the patch bfa4d86e130a09f67607482e988313430e38f6c4/2a3ad42a57b43145839f2f233fb562247658a6d9/e9994e7b9f7bbb882d13c8191731649249150d21/ba9db6f907ac02215e30128770f85fbd7db2fcf9 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20064).(CVE-2025-38192)
In the Linux kernel, the following vulnerability has been resolved:
md/raid1: Fix stack memory use after return in raid1_reshape
In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic.
Example access path:
raid1_reshape() { // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool; }
raid1_read_request() or raid1_write_request() { alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } } }
mempool_free() { if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); } }
Fix: reinit conf->r1bio_pool.wait after assigning newpool.(CVE-2025-38445)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free in tipc_conn_close().
syzbot reported a null-ptr-deref in tipc_conn_close() during netns dismantle. [0]
tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls tipc_conn_close() for each tipc_conn.
The problem is that tipc_conn_close() is called after releasing the IDR lock.
At the same time, there might be tipc_conn_recv_work() running and it could call tipc_conn_close() for the same tipc_conn and release its last ->kref.
Once we release the IDR lock in tipc_topsrv_stop(), there is no guarantee that the tipc_conn is alive.
Let's hold the ref before releasing the lock and put the ref after tipc_conn_close() in tipc_topsrv_stop().
[0]: BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435
CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb(CVE-2025-38464)
A vulnerability was found in Linux Kernel up to 6.16-rc5 (Operating System). It has been classified as problematic.CWE is classifying the issue as CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99, 6.12.39, 6.15.7 or 6.16-rc6 eliminates this vulnerability. Applying the patch 9da025150b7c14a8390fc06aea314c0a4011e82c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98/fd69af06101090eaa60b3d216ae715f9c0a58e5b/76602d8e13864524382b0687dc32cd8f19164d5a/55baecb9eb90238f60a8350660d6762046ebd3bd/4b8e18af7bea92f8b7fb92d40aeae729209db250/cd7ff61bfffd7000143c42bbffb85eeb792466d6/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38465)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Add down_write(trace_event_sem) when adding trace event
When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values.
If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel.
The addition of the event should take the trace_event_sem for write while it adds the new event.
Also add a lockdep_assert_held() on that semaphore in __trace_add_event_dirs() as it iterates the list.(CVE-2025-38539)
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Exit early on perf_mmap() fail
When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak.
Return early on failure to prevent that.(CVE-2025-38565)
A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.100/6.12.40/6.15.8 (Operating System).Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.Upgrading to version 6.6.101, 6.12.41 or 6.15.9 eliminates this vulnerability. Applying the patch 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61/708fd522b86d2a9544c34ec6a86fa3fc23336525/0f67015d72627bad72da3c2084352e0aa134416b/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38670)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"perf-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-279.0.0.182.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"perf-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-279.0.0.182.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: don\u0026apos;t touch -\u0026gt;tagset in blk_mq_get_sq_hctx\n\nblk_mq_run_hw_queues() could be run when there isn\u0026apos;t queued request and\nafter queue is cleaned up, at that time tagset is freed, because tagset\nlifetime is covered by driver, and often freed after blk_cleanup_queue()\nreturns.\n\nSo don\u0026apos;t touch -\u0026gt;tagset for figuring out current default hctx by the mapping\nbuilt in request queue, so use-after-free on tagset can be avoided. Meantime\nthis way should be fast than retrieving mapping from tagset.(CVE-2022-49377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f (\u0026quot;net: allow out-of-order netdev unregistration\u0026quot;)\nand commit e5f80fcf869a (\u0026quot;ipv6: give an IPv6 dev to blackhole_netdev\u0026quot;), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem.(CVE-2022-49390)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm/fault: Fix kfence page fault reporting\n\ncopy_from_kernel_nofault() can be called when doing read of /proc/kcore.\n/proc/kcore can have some unmapped kfence objects which when read via\ncopy_from_kernel_nofault() can cause page faults. Since *_nofault()\nfunctions define their own fixup table for handling fault, use that\ninstead of asking kfence to handle such faults.\n\nHence we search the exception tables for the nip which generated the\nfault. If there is an entry then we let the fixup table handler handle the\npage fault by returning an error from within ___do_page_fault().\n\nThis can be easily triggered if someone tries to do dd from /proc/kcore.\neg. dd if=/proc/kcore of=/dev/null bs=1M\n\nSome example false negatives:\n\n ===============================\n BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0\n Invalid read at 0xc0000000fdff0000:\n copy_from_kernel_nofault+0x9c/0x1a0\n 0xc00000000665f950\n read_kcore_iter+0x57c/0xa04\n proc_reg_read_iter+0xe4/0x16c\n vfs_read+0x320/0x3ec\n ksys_read+0x90/0x154\n system_call_exception+0x120/0x310\n system_call_vectored_common+0x15c/0x2ec\n\n BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0\n Use-after-free read at 0xc0000000fe050000 (in kfence-#2):\n copy_from_kernel_nofault+0x9c/0x1a0\n 0xc00000000665f950\n read_kcore_iter+0x57c/0xa04\n proc_reg_read_iter+0xe4/0x16c\n vfs_read+0x320/0x3ec\n ksys_read+0x90/0x154\n system_call_exception+0x120/0x310\n system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur\n\nThe action force umount(umount -f) will attempt to kill all rpc_task even\numount operation may ultimately fail if some files remain open.\nConsequently, if an action attempts to open a file, it can potentially\nsend two rpc_task to nfs server.\n\n NFS CLIENT\nthread1 thread2\nopen(\u0026quot;file\u0026quot;)\n...\nnfs4_do_open\n _nfs4_do_open\n _nfs4_open_and_get_state\n _nfs4_proc_open\n nfs4_run_open_task\n /* rpc_task1 */\n rpc_run_task\n rpc_wait_for_completion_task\n\n umount -f\n nfs_umount_begin\n rpc_killall_tasks\n rpc_signal_task\n rpc_task1 been wakeup\n and return -512\n _nfs4_do_open // while loop\n ...\n nfs4_run_open_task\n /* rpc_task2 */\n rpc_run_task\n rpc_wait_for_completion_task\n\nWhile processing an open request, nfsd will first attempt to find or\nallocate an nfs4_openowner. If it finds an nfs4_openowner that is not\nmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since\ntwo rpc_task can attempt to open the same file simultaneously from the\nclient to server, and because two instances of nfsd can run\nconcurrently, this situation can lead to lots of memory leak.\nAdditionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be\ntriggered.\n\n NFS SERVER\nnfsd1 nfsd2 echo 0 \u0026gt; /proc/fs/nfsd/threads\n\nnfsd4_open\n nfsd4_process_open1\n find_or_alloc_open_stateowner\n // alloc oo1, stateid1\n nfsd4_open\n nfsd4_process_open1\n find_or_alloc_open_stateowner\n // find oo1, without NFS4_OO_CONFIRMED\n release_openowner\n unhash_openowner_locked\n list_del_init(\u0026amp;oo-\u0026gt;oo_perclient)\n // cannot find this oo\n // from client, LEAK!!!\n alloc_stateowner // alloc oo2\n\n nfsd4_process_open2\n init_open_stateid\n // associate oo1\n // with stateid1, stateid1 LEAK!!!\n nfs4_get_vfs_file\n // alloc nfsd_file1 and nfsd_file_mark1\n // all LEAK!!!\n\n nfsd4_process_open2\n ...\n\n write_threads\n ...\n nfsd_destroy_serv\n nfsd_shutdown_net\n nfs4_state_shutdown_net\n nfs4_state_destroy_net\n destroy_client\n __destroy_client\n // won\u0026apos;t find oo1!!!\n nfsd_shutdown_generic\n nfsd_file_cache_shutdown\n kmem_cache_destroy\n for nfsd_file_slab\n and nfsd_file_mark_slab\n // bark since nfsd_file1\n // and nfsd_file_mark1\n // still alive\n\n=======================================================================\nBUG nfsd_file (Not tainted): Objects remaining in nfsd_file on\n__kmem_cache_shutdown()\n-----------------------------------------------------------------------\n\nSlab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28\nflags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)\nCPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dum\n---truncated---(CVE-2024-56779)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: state: fix out-of-bounds read during lookup\n\nlookup and resize can run in parallel.\n\nThe xfrm_state_hash_generation seqlock ensures a retry, but the hash\nfunctions can observe a hmask value that is too large for the new hlist\narray.\n\nrehash does:\n rcu_assign_pointer(net-\u0026gt;xfrm.state_bydst, ndst) [..]\n net-\u0026gt;xfrm.state_hmask = nhashmask;\n\nWhile state lookup does:\n h = xfrm_dst_hash(net, daddr, saddr, tmpl-\u0026gt;reqid, encap_family);\n hlist_for_each_entry_rcu(x, net-\u0026gt;xfrm.state_bydst + h, bydst) {\n\nThis is only safe in case the update to state_bydst is larger than\nnet-\u0026gt;xfrm.xfrm_state_hmask (or if the lookup function gets\nserialized via state spinlock again).\n\nFix this by prefetching state_hmask and the associated pointers.\nThe xfrm_state_hash_generation seqlock retry will ensure that the pointer\nand the hmask will be consistent.\n\nThe existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,\nadd lockdep assertions to document that they are only safe for insert\nside.\n\nxfrm_state_lookup_byaddr() uses the spinlock rather than RCU.\nAFAICS this is an oversight from back when state lookup was converted to\nRCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/platform: check the bounds of read/write syscalls\n\ncount and offset are passed from user space and not checked, only\noffset is capped to 40 bits, which can be used to read/write out of\nbounds of the device.(CVE-2025-21687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: Fix NULL pointer dereference\n\nWhen MPOA_cache_impos_rcvd() receives the msg, it can trigger\nNull Pointer Dereference Vulnerability if both entry and\nholding_time are NULL. Because there is only for the situation\nwhere entry is NULL and holding_time exists, it can be passed\nwhen both entry and holding_time are NULL. If these are NULL,\nthe entry will be passd to eg_cache_put() as parameter and\nit is referenced by entry-\u0026gt;use code in it.\n\nkasan log:\n\n[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I\n[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102\n[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470\n[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80\n[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006\n[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e\n[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030\n[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88\n[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15\n[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068\n[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000\n[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0\n[ 3.326430] Call Trace:\n[ 3.326725] \u0026lt;TASK\u0026gt;\n[ 3.326927] ? die_addr+0x3c/0xa0\n[ 3.327330] ? exc_general_protection+0x161/0x2a0\n[ 3.327662] ? asm_exc_general_protection+0x26/0x30\n[ 3.328214] ? vprintk_emit+0x15e/0x420\n[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470\n[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470\n[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10\n[ 3.329664] ? console_unlock+0x107/0x1d0\n[ 3.329946] ? __pfx_console_unlock+0x10/0x10\n[ 3.330283] ? do_syscall_64+0xa6/0x1a0\n[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f\n[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10\n[ 3.331395] ? down_trylock+0x52/0x80\n[ 3.331703] ? vprintk_emit+0x15e/0x420\n[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10\n[ 3.332279] ? down_trylock+0x52/0x80\n[ 3.332527] ? _printk+0xbf/0x100\n[ 3.332762] ? __pfx__printk+0x10/0x10\n[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0\n[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10\n[ 3.333614] msg_from_mpoad+0x1185/0x2750\n[ 3.333893] ? __build_skb_around+0x27b/0x3a0\n[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10\n[ 3.334501] ? __alloc_skb+0x1c0/0x310\n[ 3.334809] ? __pfx___alloc_skb+0x10/0x10\n[ 3.335283] ? _raw_spin_lock+0xe0/0xe0\n[ 3.335632] ? finish_wait+0x8d/0x1e0\n[ 3.335975] vcc_sendmsg+0x684/0xba0\n[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10\n[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10\n[ 3.337056] ? fdget+0x176/0x3e0\n[ 3.337348] __sys_sendto+0x4a2/0x510\n[ 3.337663] ? __pfx___sys_sendto+0x10/0x10\n[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400\n[ 3.338364] ? sock_ioctl+0x1bb/0x5a0\n[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20\n[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10\n[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10\n[ 3.339727] ? selinux_file_ioctl+0xa4/0x260\n[ 3.340166] __x64_sys_sendto+0xe0/0x1c0\n[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140\n[ 3.340898] do_syscall_64+0xa6/0x1a0\n[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 3.341533] RIP: 0033:0x44a380\n[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00\n[ \n---truncated---(CVE-2025-22018)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix memory accounting leak.\n\nMatt Dowling reported a weird UDP memory usage issue.\n\nUnder normal operation, the UDP memory usage reported in /proc/net/sockstat\nremains close to zero. However, it occasionally spiked to 524,288 pages\nand never dropped. Moreover, the value doubled when the application was\nterminated. Finally, it caused intermittent packet drops.\n\nWe can reproduce the issue with the script below [0]:\n\n 1. /proc/net/sockstat reports 0 pages\n\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 0\n\n 2. Run the script till the report reaches 524,288\n\n # python3 test.py \u0026amp; sleep 5\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 3 mem 524288 \u0026lt;-- (INT_MAX + 1) \u0026gt;\u0026gt; PAGE_SHIFT\n\n 3. Kill the socket and confirm the number never drops\n\n # pkill python3 \u0026amp;\u0026amp; sleep 5\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 524288\n\n 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()\n\n # python3 test.py \u0026amp; sleep 1 \u0026amp;\u0026amp; pkill python3\n\n 5. The number doubles\n\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 1048577\n\nThe application set INT_MAX to SO_RCVBUF, which triggered an integer\noverflow in udp_rmem_release().\n\nWhen a socket is close()d, udp_destruct_common() purges its receive\nqueue and sums up skb-\u0026gt;truesize in the queue. This total is calculated\nand stored in a local unsigned integer variable.\n\nThe total size is then passed to udp_rmem_release() to adjust memory\naccounting. However, because the function takes a signed integer\nargument, the total size can wrap around, causing an overflow.\n\nThen, the released amount is calculated as follows:\n\n 1) Add size to sk-\u0026gt;sk_forward_alloc.\n 2) Round down sk-\u0026gt;sk_forward_alloc to the nearest lower multiple of\n PAGE_SIZE and assign it to amount.\n 3) Subtract amount from sk-\u0026gt;sk_forward_alloc.\n 4) Pass amount \u0026gt;\u0026gt; PAGE_SHIFT to __sk_mem_reduce_allocated().\n\nWhen the issue occurred, the total in udp_destruct_common() was 2147484480\n(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().\n\nAt 1) sk-\u0026gt;sk_forward_alloc is changed from 3264 to -2147479552, and\n2) sets -2147479552 to amount. 3) reverts the wraparound, so we don\u0026apos;t\nsee a warning in inet_sock_destruct(). However, udp_memory_allocated\nends up doubling at 4).\n\nSince commit 3cd3399dd7a8 (\u0026quot;net: implement per-cpu reserves for\nmemory_allocated\u0026quot;), memory usage no longer doubles immediately after\na socket is close()d because __sk_mem_reduce_allocated() caches the\namount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP\nsocket receives a packet, the subtraction takes effect, causing UDP\nmemory usage to double.\n\nThis issue makes further memory allocation fail once the socket\u0026apos;s\nsk-\u0026gt;sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet\ndrops.\n\nTo prevent this issue, let\u0026apos;s use unsigned int for the calculation and\ncall sk_forward_alloc_add() only once for the small delta.\n\nNote that first_packet_length() also potentially has the same problem.\n\n[0]:\nfrom socket import *\n\nSO_RCVBUFFORCE = 33\nINT_MAX = (2 ** 31) - 1\n\ns = socket(AF_INET, SOCK_DGRAM)\ns.bind((\u0026apos;\u0026apos;, 0))\ns.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)\n\nc = socket(AF_INET, SOCK_DGRAM)\nc.connect(s.getsockname())\n\ndata = b\u0026apos;a\u0026apos; * 100\n\nwhile True:\n c.send(data)(CVE-2025-22058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtnetlink: Allocate vfinfo size for VF GUIDs when supported\n\nCommit 30aad41721e0 (\u0026quot;net/core: Add support for getting VF GUIDs\u0026quot;)\nadded support for getting VF port and node GUIDs in netlink ifinfo\nmessages, but their size was not taken into consideration in the\nfunction that allocates the netlink message, causing the following\nwarning when a netlink message is filled with many VF port and node\nGUIDs:\n # echo 64 \u0026gt; /sys/bus/pci/devices/0000\\:08\\:00.0/sriov_numvfs\n # ip link show dev ib0\n RTNETLINK answers: Message too long\n Cannot send link get request: Message too long\n\nKernel warning:\n\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0\n Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core\n CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:rtnl_getlink+0x586/0x5a0\n Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff \u0026lt;0f\u0026gt; 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00\n RSP: 0018:ffff888113557348 EFLAGS: 00010246\n RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000\n RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8\n RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000\n R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00\n R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff\n FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn+0xa5/0x230\n ? rtnl_getlink+0x586/0x5a0\n ? report_bug+0x22d/0x240\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x14/0x50\n ? asm_exc_invalid_op+0x16/0x20\n ? skb_trim+0x6a/0x80\n ? rtnl_getlink+0x586/0x5a0\n ? __pfx_rtnl_getlink+0x10/0x10\n ? rtnetlink_rcv_msg+0x1e5/0x860\n ? __pfx___mutex_lock+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? __pfx_lock_acquire+0x10/0x10\n ? stack_trace_save+0x90/0xd0\n ? filter_irq_stacks+0x1d/0x70\n ? kasan_save_stack+0x30/0x40\n ? kasan_save_stack+0x20/0x40\n ? kasan_save_track+0x10/0x30\n rtnetlink_rcv_msg+0x21c/0x860\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n ? arch_stack_walk+0x9e/0xf0\n ? rcu_is_watching+0x34/0x60\n ? lock_acquire+0xd5/0x410\n ? rcu_is_watching+0x34/0x60\n netlink_rcv_skb+0xe0/0x210\n ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n ? __pfx_netlink_rcv_skb+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? __pfx___netlink_lookup+0x10/0x10\n ? lock_release+0x62/0x200\n ? netlink_deliver_tap+0xfd/0x290\n ? rcu_is_watching+0x34/0x60\n ? lock_release+0x62/0x200\n ? netlink_deliver_tap+0x95/0x290\n netlink_unicast+0x31f/0x480\n ? __pfx_netlink_unicast+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? lock_acquire+0xd5/0x410\n netlink_sendmsg+0x369/0x660\n ? lock_release+0x62/0x200\n ? __pfx_netlink_sendmsg+0x10/0x10\n ? import_ubuf+0xb9/0xf0\n ? __import_iovec+0x254/0x2b0\n ? lock_release+0x62/0x200\n ? __pfx_netlink_sendmsg+0x10/0x10\n ____sys_sendmsg+0x559/0x5a0\n ? __pfx_____sys_sendmsg+0x10/0x10\n ? __pfx_copy_msghdr_from_user+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? do_read_fault+0x213/0x4a0\n ? rcu_is_watching+0x34/0x60\n ___sys_sendmsg+0xe4/0x150\n ? __pfx____sys_sendmsg+0x10/0x10\n ? do_fault+0x2cc/0x6f0\n ? handle_pte_fault+0x2e3/0x3d0\n ? __pfx_handle_pte_fault+0x10/0x10\n---truncated---(CVE-2025-22075)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisofs: Prevent the use of too small fid\n\nsyzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]\n\nThe handle_bytes value passed in by the reproducing program is equal to 12.\nIn handle_to_path(), only 12 bytes of memory are allocated for the structure\nfile_handle-\u0026gt;f_handle member, which causes an out-of-bounds access when\naccessing the member parent_block of the structure isofs_fid in isofs,\nbecause accessing parent_block requires at least 16 bytes of f_handle.\nHere, fh_len is used to indirectly confirm that the value of handle_bytes\nis greater than 3 before accessing parent_block.\n\n[1]\nBUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183\nRead of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466\nCPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025\nCall trace:\n show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0x198/0x550 mm/kasan/report.c:521\n kasan_report+0xd8/0x138 mm/kasan/report.c:634\n __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380\n isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183\n exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523\n do_handle_to_path+0xa0/0x198 fs/fhandle.c:257\n handle_to_path fs/fhandle.c:385 [inline]\n do_handle_open+0x8cc/0xb8c fs/fhandle.c:403\n __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]\n __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]\n __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n\nAllocated by task 6466:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x40/0x78 mm/kasan/common.c:68\n kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4294 [inline]\n __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306\n kmalloc_noprof include/linux/slab.h:905 [inline]\n handle_to_path fs/fhandle.c:357 [inline]\n do_handle_open+0x5a4/0xb8c fs/fhandle.c:403\n __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]\n __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]\n __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600(CVE-2025-37780)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class handling\n\nThis patch fixes a Use-After-Free vulnerability in the HFSC qdisc class\nhandling. The issue occurs due to a time-of-check/time-of-use condition\nin hfsc_change_class() when working with certain child qdiscs like netem\nor codel.\n\nThe vulnerability works as follows:\n1. hfsc_change_class() checks if a class has packets (q.qlen != 0)\n2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g.,\n codel, netem) might drop packets and empty the queue\n3. The code continues assuming the queue is still non-empty, adding\n the class to vttree\n4. This breaks HFSC scheduler assumptions that only non-empty classes\n are in vttree\n5. Later, when the class is destroyed, this can lead to a Use-After-Free\n\nThe fix adds a second queue length check after qdisc_peek_len() to verify\nthe queue wasn\u0026apos;t emptied.(CVE-2025-37797)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc\n\nAs described in Gerrard\u0026apos;s report [1], we have a UAF case when an hfsc class\nhas a netem child qdisc. The crux of the issue is that hfsc is assuming\nthat checking for cl-\u0026gt;qdisc-\u0026gt;q.qlen == 0 guarantees that it hasn\u0026apos;t inserted\nthe class in the vttree or eltree (which is not true for the netem\nduplicate case).\n\nThis patch checks the n_active class variable to make sure that the code\nwon\u0026apos;t insert the class in the vttree or eltree twice, catering for the\nreentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37890)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()\n\nWhen enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the\nchild qdisc\u0026apos;s peek() operation before incrementing sch-\u0026gt;q.qlen and\nsch-\u0026gt;qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may\ntrigger an immediate dequeue and potential packet drop. In such cases,\nqdisc_tree_reduce_backlog() is called, but the HFSC qdisc\u0026apos;s qlen and backlog\nhave not yet been updated, leading to inconsistent queue accounting. This\ncan leave an empty HFSC class in the active list, causing further\nconsequences like use-after-free.\n\nThis patch fixes the bug by moving the increment of sch-\u0026gt;q.qlen and\nsch-\u0026gt;qstats.backlog before the call to the child qdisc\u0026apos;s peek() operation.\nThis ensures that queue length and backlog are always accurate when packet\ndrops or dequeues are triggered during the peek.(CVE-2025-38000)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Address reentrant enqueue adding class to eltree twice\n\nSavino says:\n \u0026quot;We are writing to report that this recent patch\n (141d34391abbb315d68556b7c67ad97885407547) [1]\n can be bypassed, and a UAF can still occur when HFSC is utilized with\n NETEM.\n\n The patch only checks the cl-\u0026gt;cl_nactive field to determine whether\n it is the first insertion or not [2], but this field is only\n incremented by init_vf [3].\n\n By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the\n check and insert the class twice in the eltree.\n Under normal conditions, this would lead to an infinite loop in\n hfsc_dequeue for the reasons we already explained in this report [5].\n\n However, if TBF is added as root qdisc and it is configured with a\n very low rate,\n it can be utilized to prevent packets from being dequeued.\n This behavior can be exploited to perform subsequent insertions in the\n HFSC eltree and cause a UAF.\u0026quot;\n\nTo fix both the UAF and the infinite loop, with netem as an hfsc child,\ncheck explicitly in hfsc_enqueue whether the class is already in the eltree\nwhenever the HFSC_RSC flag is set.\n\n[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547\n[2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572\n[3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677\n[4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574\n[5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u(CVE-2025-38001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\n\nSyzbot reported a slab-use-after-free with the following call trace:\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840\n Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25\n\n Call Trace:\n kasan_report+0xd9/0x110 mm/kasan/report.c:601\n tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840\n crypto_request_complete include/crypto/algapi.h:266\n aead_request_complete include/crypto/internal/aead.h:85\n cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772\n crypto_request_complete include/crypto/algapi.h:266\n cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181\n process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n\n Allocated by task 8355:\n kzalloc_noprof include/linux/slab.h:778\n tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466\n tipc_init_net+0x2dd/0x430 net/tipc/core.c:72\n ops_init+0xb9/0x650 net/core/net_namespace.c:139\n setup_net+0x435/0xb40 net/core/net_namespace.c:343\n copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508\n create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110\n unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228\n ksys_unshare+0x419/0x970 kernel/fork.c:3323\n __do_sys_unshare kernel/fork.c:3394\n\n Freed by task 63:\n kfree+0x12a/0x3b0 mm/slub.c:4557\n tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539\n tipc_exit_net+0x8c/0x110 net/tipc/core.c:119\n ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173\n cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640\n process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n\nAfter freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done\nmay still visit it in cryptd_queue_worker workqueue.\n\nI reproduce this issue by:\n ip netns add ns1\n ip link add veth1 type veth peer name veth2\n ip link set veth1 netns ns1\n ip netns exec ns1 tipc bearer enable media eth dev veth1\n ip netns exec ns1 tipc node set key this_is_a_master_key master\n ip netns exec ns1 tipc bearer disable media eth dev veth1\n ip netns del ns1\n\nThe key of reproduction is that, simd_aead_encrypt is interrupted, leading\nto crypto_simd_usable() return false. Thus, the cryptd_queue_worker is\ntriggered, and the tipc_crypto tx will be visited.\n\n tipc_disc_timeout\n tipc_bearer_xmit_skb\n tipc_crypto_xmit\n tipc_aead_encrypt\n crypto_aead_encrypt\n // encrypt()\n simd_aead_encrypt\n // crypto_simd_usable() is false\n child = \u0026amp;ctx-\u0026gt;cryptd_tfm-\u0026gt;base;\n\n simd_aead_encrypt\n crypto_aead_encrypt\n // encrypt()\n cryptd_aead_encrypt_enqueue\n cryptd_aead_enqueue\n cryptd_enqueue_request\n // trigger cryptd_queue_worker\n queue_work_on(smp_processor_id(), cryptd_wq, \u0026amp;cpu_queue-\u0026gt;work)\n\nFix this by holding net reference count before encrypt.(CVE-2025-38052)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc1 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch c337efb20d6d9f9bbb4746f6b119917af5c886dc/b44f791f27b14c9eb6b907fbe51f2ba8bec32085/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72/9c19498bdd7cb9d854bd3c54260f71cf7408495e/b4e9bab6011b9559b7c157b16b91ae46d4d8c533/d1bc80da75c789f2f6830df89d91fb2f7a509943/82448d4dcd8406dec688632a405fdcf7f170ec69/82ffbe7776d0ac084031f114167712269bf3d832 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38115)\n\nLinux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States.\n There is a security vulnerability in Linux kernel, which originates from improper processing of udp gso segmentation, which may lead to memory corruption.(CVE-2025-38124)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer\n\nThe reproduction steps:\n1. create a tun interface\n2. enable l2 bearer\n3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun\n\ntipc: Started in network mode\ntipc: Node identity 8af312d38a21, cluster identity 4711\ntipc: Enabled bearer \u0026lt;eth:syz_tun\u0026gt;, priority 1\nOops: general protection fault\nKASAN: null-ptr-deref in range\nCPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT\nHardware name: QEMU Ubuntu 24.04 PC\nRIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0\n\nthe ub was in fact a struct dev.\n\nwhen bid != 0 \u0026amp;\u0026amp; skip_cnt != 0, bearer_list[bid] may be NULL or\nother media when other thread changes it.\n\nfix this by checking media_id.(CVE-2025-38184)\n\nA vulnerability classified as critical has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc1 (Operating System).CWE is classifying the issue as CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.This is going to have an impact on availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc2 eliminates this vulnerability. Applying the patch bfa4d86e130a09f67607482e988313430e38f6c4/2a3ad42a57b43145839f2f233fb562247658a6d9/e9994e7b9f7bbb882d13c8191731649249150d21/ba9db6f907ac02215e30128770f85fbd7db2fcf9 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20064).(CVE-2025-38192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1: Fix stack memory use after return in raid1_reshape\n\nIn the raid1_reshape function, newpool is\nallocated on the stack and assigned to conf-\u0026gt;r1bio_pool.\nThis results in conf-\u0026gt;r1bio_pool.wait.head pointing\nto a stack address.\nAccessing this address later can lead to a kernel panic.\n\nExample access path:\n\nraid1_reshape()\n{\n\t// newpool is on the stack\n\tmempool_t newpool, oldpool;\n\t// initialize newpool.wait.head to stack address\n\tmempool_init(\u0026amp;newpool, ...);\n\tconf-\u0026gt;r1bio_pool = newpool;\n}\n\nraid1_read_request() or raid1_write_request()\n{\n\talloc_r1bio()\n\t{\n\t\tmempool_alloc()\n\t\t{\n\t\t\t// if pool-\u0026gt;alloc fails\n\t\t\tremove_element()\n\t\t\t{\n\t\t\t\t--pool-\u0026gt;curr_nr;\n\t\t\t}\n\t\t}\n\t}\n}\n\nmempool_free()\n{\n\tif (pool-\u0026gt;curr_nr \u0026lt; pool-\u0026gt;min_nr) {\n\t\t// pool-\u0026gt;wait.head is a stack address\n\t\t// wake_up() will try to access this invalid address\n\t\t// which leads to a kernel panic\n\t\treturn;\n\t\twake_up(\u0026amp;pool-\u0026gt;wait);\n\t}\n}\n\nFix:\nreinit conf-\u0026gt;r1bio_pool.wait after assigning newpool.(CVE-2025-38445)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free in tipc_conn_close().\n\nsyzbot reported a null-ptr-deref in tipc_conn_close() during netns\ndismantle. [0]\n\ntipc_topsrv_stop() iterates tipc_net(net)-\u0026gt;topsrv-\u0026gt;conn_idr and calls\ntipc_conn_close() for each tipc_conn.\n\nThe problem is that tipc_conn_close() is called after releasing the\nIDR lock.\n\nAt the same time, there might be tipc_conn_recv_work() running and it\ncould call tipc_conn_close() for the same tipc_conn and release its\nlast -\u0026gt;kref.\n\nOnce we release the IDR lock in tipc_topsrv_stop(), there is no\nguarantee that the tipc_conn is alive.\n\nLet\u0026apos;s hold the ref before releasing the lock and put the ref after\ntipc_conn_close() in tipc_topsrv_stop().\n\n[0]:\nBUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165\nRead of size 8 at addr ffff888099305a08 by task kworker/u4:3/435\n\nCPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: netns cleanup_net\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x1fc/0x2ef lib/dump_stack.c:118\n print_address_description.cold+0x54/0x219 mm/kasan/report.c:256\n kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354\n kasan_report mm/kasan/report.c:412 [inline]\n __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433\n tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165\n tipc_topsrv_stop net/tipc/topsrv.c:701 [inline]\n tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722\n ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153\n cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nAllocated by task 23:\n kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625\n kmalloc include/linux/slab.h:515 [inline]\n kzalloc include/linux/slab.h:709 [inline]\n tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192\n tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nFreed by task 23:\n __cache_free mm/slab.c:3503 [inline]\n kfree+0xcc/0x210 mm/slab.c:3822\n tipc_conn_kref_release net/tipc/topsrv.c:150 [inline]\n kref_put include/linux/kref.h:70 [inline]\n conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nThe buggy address belongs to the object at ffff888099305a00\n which belongs to the cache kmalloc-512 of size 512\nThe buggy address is located 8 bytes inside of\n 512-byte region [ffff888099305a00, ffff888099305c00)\nThe buggy address belongs to the page:\npage:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0\nflags: 0xfff00000000100(slab)\nraw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940\nraw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n\u0026gt;ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ^\n ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb(CVE-2025-38464)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc5 (Operating System). It has been classified as problematic.CWE is classifying the issue as CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99, 6.12.39, 6.15.7 or 6.16-rc6 eliminates this vulnerability. Applying the patch 9da025150b7c14a8390fc06aea314c0a4011e82c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98/fd69af06101090eaa60b3d216ae715f9c0a58e5b/76602d8e13864524382b0687dc32cd8f19164d5a/55baecb9eb90238f60a8350660d6762046ebd3bd/4b8e18af7bea92f8b7fb92d40aeae729209db250/cd7ff61bfffd7000143c42bbffb85eeb792466d6/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38465)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Add down_write(trace_event_sem) when adding trace event\n\nWhen a module is loaded, it adds trace events defined by the module. It\nmay also need to modify the modules trace printk formats to replace enum\nnames with their values.\n\nIf two modules are loaded at the same time, the adding of the event to the\nftrace_events list can corrupt the walking of the list in the code that is\nmodifying the printk format strings and crash the kernel.\n\nThe addition of the event should take the trace_event_sem for write while\nit adds the new event.\n\nAlso add a lockdep_assert_held() on that semaphore in\n__trace_add_event_dirs() as it iterates the list.(CVE-2025-38539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Exit early on perf_mmap() fail\n\nWhen perf_mmap() fails to allocate a buffer, it still invokes the\nevent_mapped() callback of the related event. On X86 this might increase\nthe perf_rdpmc_allowed reference counter. But nothing undoes this as\nperf_mmap_close() is never called in this case, which causes another\nreference count leak.\n\nReturn early on failure to prevent that.(CVE-2025-38565)\n\nA vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.100/6.12.40/6.15.8 (Operating System).Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.Upgrading to version 6.6.101, 6.12.41 or 6.15.9 eliminates this vulnerability. Applying the patch 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61/708fd522b86d2a9544c34ec6a86fa3fc23336525/0f67015d72627bad72da3c2084352e0aa134416b/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38670)",
"id": "OESA-2025-2082",
"modified": "2026-08-06T11:09:09Z",
"published": "2025-08-29T11:09:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49377"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49390"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56779"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58069"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21687"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22018"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22058"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22075"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37780"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37797"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37890"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38115"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38124"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38184"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38445"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38464"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38465"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38539"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38565"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38670"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49377",
"CVE-2022-49390",
"CVE-2024-56678",
"CVE-2024-56779",
"CVE-2024-57982",
"CVE-2024-58069",
"CVE-2025-21687",
"CVE-2025-22018",
"CVE-2025-22058",
"CVE-2025-22075",
"CVE-2025-37780",
"CVE-2025-37797",
"CVE-2025-37890",
"CVE-2025-38000",
"CVE-2025-38001",
"CVE-2025-38052",
"CVE-2025-38115",
"CVE-2025-38124",
"CVE-2025-38184",
"CVE-2025-38192",
"CVE-2025-38445",
"CVE-2025-38464",
"CVE-2025-38465",
"CVE-2025-38539",
"CVE-2025-38565",
"CVE-2025-38670"
]
}
SUSE-SU-2025:01600-1
Vulnerability from csaf_suse - Published: 2025-05-20 11:49 - Updated: 2026-09-20 17:19Sightings
| 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 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.