admin/nvd-json-data-feeds
1
0
Fork 0
mirror of https://github.com/fkie-cad/nvd-json-data-feeds.git synced 2025-07-09 16:05:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

Auto-Update: 2025-07-06T02:00:10.922955+00:00

Browse Source
This commit is contained in:
cad-safe-bot 2025-07-06 02:03:49 +00:00
parent 1dd4dcb0e7
commit 15d2fc0b19
1952 changed files with 21133 additions and 4954 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

783
CVE-2009/CVE-2009-24xx/CVE-2009-2466.json
View File

File diff suppressed because it is too large Load Diff

488
CVE-2010/CVE-2010-12xx/CVE-2010-1233.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2010-1233",
"sourceIdentifier": "cve@mitre.org",
"published": "2010-04-01T22:30:00.657",
"lastModified": "2025-04-11T00:51:21.963",
"vulnStatus": "Deferred",
"lastModified": "2025-06-25T16:55:51.240",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [
{
@ -49,7 +49,7 @@
"description": [
{
"lang": "en",
"value": "CWE-189"
"value": "CWE-190"
}
]
}
@ -62,430 +62,10 @@
"negate": false,
"cpeMatch": [
{
"vulnerable": false,
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:*",
"versionEndIncluding": "4.1.249.1035",
"matchCriteriaId": "DED9A20C-F0D6-4979-B778-3D728E345CAF"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:0.2.149.27:*:*:*:*:*:*:*",
"matchCriteriaId": "D55D5075-D233-42D6-B1D6-77B7599650EB"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:0.2.149.29:*:*:*:*:*:*:*",
"matchCriteriaId": "5B8FF77A-7802-4963-B532-3F16C7BB012C"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:0.2.149.30:*:*:*:*:*:*:*",
"matchCriteriaId": "D73576CF-76EE-42A3-9955-D7991384B8C1"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:0.2.152.1:*:*:*:*:*:*:*",
"matchCriteriaId": "DD4A2AB1-6F90-4D0B-A673-C6310514CE63"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:0.2.153.1:*:*:*:*:*:*:*",
"matchCriteriaId": "66A4FEB5-11D8-4FFC-972D-A3B991176040"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:0.3.154.0:*:*:*:*:*:*:*",
"matchCriteriaId": "A6313614-FC3C-488C-B80B-191797319A56"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:0.3.154.3:*:*:*:*:*:*:*",
"matchCriteriaId": "9CDF3DAB-73C4-48E8-9B0B-DADABF217555"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:0.4.154.18:*:*:*:*:*:*:*",
"matchCriteriaId": "7B2FAE50-4CA3-46F6-B533-C599011A9ED5"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:0.4.154.22:*:*:*:*:*:*:*",
"matchCriteriaId": "B0D94F22-37B6-4938-966A-E1830D83FBC3"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:0.4.154.31:*:*:*:*:*:*:*",
"matchCriteriaId": "D8B7164E-7A4F-4959-9E6D-EF614EDD4C3C"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:0.4.154.33:*:*:*:*:*:*:*",
"matchCriteriaId": "0C0F9D75-B10D-468F-84D8-61B6A1230556"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:1.0.154.36:*:*:*:*:*:*:*",
"matchCriteriaId": "5D2CAE29-3F1E-4374-B82C-B60B7BB4AEAE"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:1.0.154.39:*:*:*:*:*:*:*",
"matchCriteriaId": "173D539E-045E-4429-80C9-5749BECC6CD5"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:1.0.154.42:*:*:*:*:*:*:*",
"matchCriteriaId": "D2052352-FECC-4990-B0F4-A715694AD816"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:1.0.154.43:*:*:*:*:*:*:*",
"matchCriteriaId": "BCBC80CB-4AB8-4EDF-9940-D2D7124D7549"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:1.0.154.46:*:*:*:*:*:*:*",
"matchCriteriaId": "E37938BB-8368-46D6-A8E4-F99F5CB9B82E"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:1.0.154.48:*:*:*:*:*:*:*",
"matchCriteriaId": "6659833E-E309-4797-84D4-A782237714A9"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:1.0.154.52:*:*:*:*:*:*:*",
"matchCriteriaId": "FE4C0D93-0308-48D4-A953-9398B88E2868"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:1.0.154.53:*:*:*:*:*:*:*",
"matchCriteriaId": "FE5094C4-1338-4189-B5FD-C9AFFF091D6B"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:1.0.154.59:*:*:*:*:*:*:*",
"matchCriteriaId": "51A8C3D2-82E6-453E-90B7-BA5C5D2CDF54"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:1.0.154.65:*:*:*:*:*:*:*",
"matchCriteriaId": "67C0798F-CC7F-4069-810E-B81F8BB77CCD"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.156.1:*:*:*:*:*:*:*",
"matchCriteriaId": "A2F95770-F36F-43C0-986F-5C819648271E"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.157.0:*:*:*:*:*:*:*",
"matchCriteriaId": "ECCE1FD3-8D27-4304-97F9-6F9689F2498D"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.157.2:*:*:*:*:*:*:*",
"matchCriteriaId": "0F6CA696-49AA-4445-B978-96C1D8CE58DF"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.158.0:*:*:*:*:*:*:*",
"matchCriteriaId": "D9CFA3BF-6C07-448B-8C83-AD4C524A6577"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.159.0:*:*:*:*:*:*:*",
"matchCriteriaId": "E8497F93-D88A-4FFA-B988-7210608530A8"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.169.0:*:*:*:*:*:*:*",
"matchCriteriaId": "49FB50A3-FFDA-4BB9-A2C1-DA6DACC2DAAB"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.169.1:*:*:*:*:*:*:*",
"matchCriteriaId": "59F93BC8-FE87-4CEC-B28A-4B0B5A468EDE"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.170.0:*:*:*:*:*:*:*",
"matchCriteriaId": "02D459C7-2555-42FA-9C68-619E410D7CBA"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.172:*:*:*:*:*:*:*",
"matchCriteriaId": "E5CDF938-2998-403F-B343-29B620E05D44"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.172.2:*:*:*:*:*:*:*",
"matchCriteriaId": "64F89EA6-B411-4887-90A1-FF3A054424F6"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.172.8:*:*:*:*:*:*:*",
"matchCriteriaId": "10D2BA3B-1C69-470C-9C40-001FAE82DDB4"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.172.27:*:*:*:*:*:*:*",
"matchCriteriaId": "3583995C-CD74-401F-905D-65B73CFC4595"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.172.28:*:*:*:*:*:*:*",
"matchCriteriaId": "A0A621B1-3186-4CE2-8BCC-916027CC74CF"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.172.30:*:*:*:*:*:*:*",
"matchCriteriaId": "B4A9B50D-5B0F-41C9-8FAF-B78CD21A0554"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.172.31:*:*:*:*:*:*:*",
"matchCriteriaId": "4F5223F1-85CD-4DF9-9665-BDF7B554A784"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.172.33:*:*:*:*:*:*:*",
"matchCriteriaId": "8DD7AFBA-A9A2-4EE9-B652-78D25EFBB690"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.172.37:*:*:*:*:*:*:*",
"matchCriteriaId": "6B9D6ED9-D5C5-4CA9-84EA-8007F48CF597"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:2.0.172.38:*:*:*:*:*:*:*",
"matchCriteriaId": "0E7F7897-ECD1-499E-81CD-E224241B6607"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:3.0.182.2:*:*:*:*:*:*:*",
"matchCriteriaId": "C7422307-271F-4953-9CA4-C50238D27BAE"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:3.0.190.2:*:*:*:*:*:*:*",
"matchCriteriaId": "9DCC3490-5B06-4992-8E31-CA46E18607B7"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:3.0.193.2:beta:*:*:*:*:*:*",
"matchCriteriaId": "C2F85551-EDB5-4790-8095-EFFA7DEC7F98"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:3.0.195.21:*:*:*:*:*:*:*",
"matchCriteriaId": "6FEBB1A8-295B-4AF7-996D-F7E415B91ECB"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:3.0.195.24:*:*:*:*:*:*:*",
"matchCriteriaId": "50995718-0F70-44CA-863B-4AFB4C7AF3CD"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:3.0.195.32:*:*:*:*:*:*:*",
"matchCriteriaId": "31D2B04D-ECEB-4B9B-9DC7-FE17C13DD72A"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:3.0.195.33:*:*:*:*:*:*:*",
"matchCriteriaId": "F7460B03-A658-4507-8D9E-E0234940BD71"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:4.0.244.0:*:*:*:*:*:*:*",
"matchCriteriaId": "764825B3-75C2-4FF1-93B6-C6E696C05058"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:4.0.249.0:*:*:*:*:*:*:*",
"matchCriteriaId": "8CD2980F-A2B4-4EEE-90ED-5CFF4C29AA99"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:4.0.249.78:*:*:*:*:*:*:*",
"matchCriteriaId": "BDE39270-209E-45B8-B574-AF508EAB9474"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:4.0.249.78:beta:*:*:*:*:*:*",
"matchCriteriaId": "2F56327D-C34E-476F-873A-F83E75913FE4"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:google:chrome:4.0.249.89:*:*:*:*:*:*:*",
"matchCriteriaId": "3840D6BD-B496-459B-8C3C-E44B20E769AF"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1:beta:*:*:*:*:*:*",
"matchCriteriaId": "063DAA53-81C5-47D1-9E3F-AFBB299176EA"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.0:*:*:*:*:*:*:*",
"matchCriteriaId": "E11634AF-F6A8-4BFB-AEBD-108B604685E6"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1001:*:*:*:*:*:*:*",
"matchCriteriaId": "FCC8EAD9-A771-488F-AF77-CD1DE9B4711D"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1004:*:*:*:*:*:*:*",
"matchCriteriaId": "623C878C-3922-48DE-B59E-FB7031DB48D3"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1006:*:*:*:*:*:*:*",
"matchCriteriaId": "E6946EE5-2892-4353-B5D8-AA2E22F249D8"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1007:*:*:*:*:*:*:*",
"matchCriteriaId": "6AD148D0-B4A8-4941-8567-43A7D0625D60"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1008:*:*:*:*:*:*:*",
"matchCriteriaId": "FD6F3ABA-C313-43D1-8B4F-94956079A7EB"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1009:*:*:*:*:*:*:*",
"matchCriteriaId": "A66FEFF4-B2DF-4F0C-83A3-20D5FD731176"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1010:*:*:*:*:*:*:*",
"matchCriteriaId": "63F5DE2D-94F6-4AD0-A1EE-50B3FF3F6838"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1011:*:*:*:*:*:*:*",
"matchCriteriaId": "07C5E8DE-CE20-44DE-BBA7-C78B0F633F2B"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1012:*:*:*:*:*:*:*",
"matchCriteriaId": "FEAC3DE1-6CBB-41B5-A1E2-758066212B24"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1013:*:*:*:*:*:*:*",
"matchCriteriaId": "30139360-B0CD-40EA-8BF1-1CA378FE4592"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1014:*:*:*:*:*:*:*",
"matchCriteriaId": "6E96DFCC-658F-4A59-ACB4-5ABC5ADB9EFC"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1015:*:*:*:*:*:*:*",
"matchCriteriaId": "A41983FB-84DC-4225-9A4D-006817B27440"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1016:*:*:*:*:*:*:*",
"matchCriteriaId": "87D8F8AB-8AA5-4CF6-9F16-D334D4C7919C"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1017:*:*:*:*:*:*:*",
"matchCriteriaId": "E11C83A9-A7D7-4C6A-9787-2206F24A9216"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1018:*:*:*:*:*:*:*",
"matchCriteriaId": "6D252FB8-0D05-4F30-B488-F12BC3889CDC"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1019:*:*:*:*:*:*:*",
"matchCriteriaId": "8275B3A8-6F86-4EA4-97EC-5A0F341D7F53"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1020:*:*:*:*:*:*:*",
"matchCriteriaId": "2166ED0B-D470-41B6-8405-0C1C7BF55C79"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1021:*:*:*:*:*:*:*",
"matchCriteriaId": "2A20B815-5A5C-49C4-BD6F-2219F0921188"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1022:*:*:*:*:*:*:*",
"matchCriteriaId": "4C20763A-985D-49EA-B2CE-87484BACEC43"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1023:*:*:*:*:*:*:*",
"matchCriteriaId": "01591BD1-5860-4B94-B874-31DB0649AB95"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1024:*:*:*:*:*:*:*",
"matchCriteriaId": "2E1630C3-8D5B-4356-96BD-A09CE19DEF29"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1025:*:*:*:*:*:*:*",
"matchCriteriaId": "ECD4B7B4-6980-4843-AC27-9A7AD960C283"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1026:*:*:*:*:*:*:*",
"matchCriteriaId": "CB3C8BD4-C9BF-449C-A3D2-F65A02CCBC63"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1027:*:*:*:*:*:*:*",
"matchCriteriaId": "B9BAF28C-0FF7-4814-A7B5-E6CD128831A9"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1028:*:*:*:*:*:*:*",
"matchCriteriaId": "948460B6-B929-4818-9475-FF45BB7B1406"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1029:*:*:*:*:*:*:*",
"matchCriteriaId": "244F512F-8199-49F6-8E6A-87ED2EADB749"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1030:*:*:*:*:*:*:*",
"matchCriteriaId": "870EBE96-613E-4F6D-98DE-E61B0A09F97D"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1031:*:*:*:*:*:*:*",
"matchCriteriaId": "BA1A130D-6DDA-417B-A833-09B63367DFD7"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1032:*:*:*:*:*:*:*",
"matchCriteriaId": "1863C21A-438B-45DE-B6C0-5AA875FDC96D"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1033:*:*:*:*:*:*:*",
"matchCriteriaId": "A85CDC6D-0CAB-4E3C-8350-43B883869C5D"
},
{
"vulnerable": false,
"criteria": "cpe:2.3:a:google:chrome:4.1.249.1034:*:*:*:*:*:*:*",
"matchCriteriaId": "6E473A91-F955-41A3-A94F-5B24908DE629"
"versionEndExcluding": "4.1.249.1036",
"matchCriteriaId": "300EAF6A-9668-4AD0-BF20-BC0F72969B1C"
}
]
}
@ -497,55 +77,87 @@
"url": "http://code.google.com/p/chromium/issues/detail?id=35724",
"source": "cve@mitre.org",
"tags": [
"Exploit"
"Exploit",
"Permissions Required"
]
},
{
"url": "http://googlechromereleases.blogspot.com/2010/03/stable-channel-update.html",
"source": "cve@mitre.org"
"source": "cve@mitre.org",
"tags": [
"Vendor Advisory"
]
},
{
"url": "http://lists.opensuse.org/opensuse-security-announce/2011-01/msg00006.html",
"source": "cve@mitre.org"
"source": "cve@mitre.org",
"tags": [
"Broken Link"
]
},
{
"url": "http://secunia.com/advisories/43068",
"source": "cve@mitre.org"
"source": "cve@mitre.org",
"tags": [
"Broken Link"
]
},
{
"url": "http://www.vupen.com/english/advisories/2011/0212",
"source": "cve@mitre.org"
"source": "cve@mitre.org",
"tags": [
"Broken Link"
]
},
{
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A14023",
"source": "cve@mitre.org"
"source": "cve@mitre.org",
"tags": [
"Broken Link"
]
},
{
"url": "http://code.google.com/p/chromium/issues/detail?id=35724",
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Exploit"
"Exploit",
"Permissions Required"
]
},
{
"url": "http://googlechromereleases.blogspot.com/2010/03/stable-channel-update.html",
"source": "af854a3a-2127-422b-91ae-364da2661108"
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Vendor Advisory"
]
},
{
"url": "http://lists.opensuse.org/opensuse-security-announce/2011-01/msg00006.html",
"source": "af854a3a-2127-422b-91ae-364da2661108"
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Broken Link"
]
},
{
"url": "http://secunia.com/advisories/43068",
"source": "af854a3a-2127-422b-91ae-364da2661108"
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Broken Link"
]
},
{
"url": "http://www.vupen.com/english/advisories/2011/0212",
"source": "af854a3a-2127-422b-91ae-364da2661108"
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Broken Link"
]
},
{
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A14023",
"source": "af854a3a-2127-422b-91ae-364da2661108"
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Broken Link"
]
}
]
}

2
CVE-2014/CVE-2014-62xx/CVE-2014-6274.json
View File

@ -12,7 +12,7 @@
},
{
"lang": "es",
"value": "Git-annex ten\u00eda un error en los servidores remotos S3 y Glacier: si se configuraba embedcreds=yes y el servidor remoto usaba encrypted=pubkey o encrypted=hybrid, las credenciales de AWS integradas se almacenaban en el repositorio Git en texto plano (en la pr\u00e1ctica), no cifradas como deb\u00edan. Este problema afecta a Git-annex desde la versi\u00f3n 3.20121126 hasta la versi\u00f3n 5.20140919."
"value": "git-annex ten\u00eda un error en los servidores remotos S3 y Glacier: si se configuraba embedcreds=yes y el servidor remoto usaba encrypted=pubkey o encrypted=hybrid, las credenciales de AWS integradas se almacenaban en el repositorio git en texto plano (en la pr\u00e1ctica), no cifradas como deb\u00edan. Este problema afecta a git-annex desde la versi\u00f3n 3.20121126 hasta la versi\u00f3n 5.20140919.\n"
}
],
"metrics": {

49
CVE-2019/CVE-2019-165xx/CVE-2019-16536.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2019-16536",
"sourceIdentifier": "browser-security@yandex-team.ru",
"published": "2025-05-21T08:15:26.233",
"lastModified": "2025-05-21T20:24:58.133",
"vulnStatus": "Awaiting Analysis",
"lastModified": "2025-06-25T14:33:42.690",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [
{
@ -59,6 +59,28 @@
"providerUrgency": "NOT_DEFINED"
}
}
],
"cvssMetricV31": [
{
"source": "nvd@nist.gov",
"type": "Primary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 2.8,
"impactScore": 5.9
}
]
},
"weaknesses": [
@ -73,10 +95,31 @@
]
}
],
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:a:clickhouse:clickhouse:*:*:*:*:*:*:*:*",
"versionEndExcluding": "19.14.3.3",
"matchCriteriaId": "A535E755-6FEF-4851-987A-827717769D2D"
}
]
}
]
}
],
"references": [
{
"url": "https://clickhouse.com/docs/whats-new/security-changelog",
"source": "browser-security@yandex-team.ru"
"source": "browser-security@yandex-team.ru",
"tags": [
"Release Notes"
]
}
]
}

2
CVE-2019/CVE-2019-166xx/CVE-2019-16639.json
View File

@ -3,7 +3,7 @@
"sourceIdentifier": "cve@mitre.org",
"published": "2024-07-16T17:15:10.430",
"lastModified": "2024-11-21T04:30:51.677",
"vulnStatus": "Awaiting Analysis",
"vulnStatus": "Undergoing Analysis",
"cveTags": [],
"descriptions": [
{

2
CVE-2019/CVE-2019-166xx/CVE-2019-16640.json
View File

@ -3,7 +3,7 @@
"sourceIdentifier": "cve@mitre.org",
"published": "2024-07-16T17:15:10.513",
"lastModified": "2024-11-21T04:30:51.883",
"vulnStatus": "Awaiting Analysis",
"vulnStatus": "Undergoing Analysis",
"cveTags": [],
"descriptions": [
{

2
CVE-2019/CVE-2019-166xx/CVE-2019-16641.json
View File

@ -3,7 +3,7 @@
"sourceIdentifier": "cve@mitre.org",
"published": "2024-07-16T17:15:10.600",
"lastModified": "2024-11-21T04:30:52.080",
"vulnStatus": "Awaiting Analysis",
"vulnStatus": "Undergoing Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2020/CVE-2020-257xx/CVE-2020-25720.json
View File

@ -19,7 +19,7 @@
"cvssMetricV31": [
{
"source": "secalert@redhat.com",
"type": "Primary",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
@ -42,7 +42,7 @@
"weaknesses": [
{
"source": "secalert@redhat.com",
"type": "Primary",
"type": "Secondary",
"description": [
{
"lang": "en",

36
CVE-2020/CVE-2020-367xx/CVE-2020-36771.json
View File

@ -2,7 +2,7 @@
"id": "CVE-2020-36771",
"sourceIdentifier": "secalert@redhat.com",
"published": "2024-01-22T14:15:07.530",
"lastModified": "2024-11-21T05:30:16.320",
"lastModified": "2025-06-20T19:15:20.827",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
@ -36,13 +36,33 @@
},
"exploitabilityScore": 1.8,
"impactScore": 5.9
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"attackVector": "LOCAL",
"attackComplexity": "LOW",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9
}
]
},
"weaknesses": [
{
"source": "secalert@redhat.com",
"type": "Secondary",
"type": "Primary",
"description": [
{
"lang": "en",
@ -52,13 +72,23 @@
},
{
"source": "nvd@nist.gov",
"type": "Primary",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-200"
}
]
}
],
"configurations": [

276
CVE-2021/CVE-2021-14xx/CVE-2021-1470.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2021-1470",
"sourceIdentifier": "psirt@cisco.com",
"published": "2024-11-15T17:15:07.977",
"lastModified": "2024-11-18T17:11:56.587",
"vulnStatus": "Undergoing Analysis",
"lastModified": "2025-06-24T14:35:38.113",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [
{
@ -61,18 +61,284 @@
]
}
],
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:17.2.4:*:*:*:*:*:*:*",
"matchCriteriaId": "A0D5F32C-BFC1-49CC-BE96-920FCBE567B0"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:17.2.5:*:*:*:*:*:*:*",
"matchCriteriaId": "F621202C-3851-4D7E-BFA2-DABB08E73DB6"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:17.2.6:*:*:*:*:*:*:*",
"matchCriteriaId": "38132BE5-528B-472E-9249-B226C0DE1C80"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:17.2.7:*:*:*:*:*:*:*",
"matchCriteriaId": "37C817B2-DDB9-4CAF-96C9-776482A8597D"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:17.2.8:*:*:*:*:*:*:*",
"matchCriteriaId": "AC5D29FD-0917-4C1F-AE75-2D63F5C9C58D"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:17.2.9:*:*:*:*:*:*:*",
"matchCriteriaId": "1E3090C4-15E6-4746-B0D2-27665AB91B08"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:17.2.10:*:*:*:*:*:*:*",
"matchCriteriaId": "04E924CC-3161-436D-93F0-066F76172F55"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.2.0:*:*:*:*:*:*:*",
"matchCriteriaId": "7ED059CD-AD0A-4748-8390-8CDCF4C4D1CC"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.3.0:*:*:*:*:*:*:*",
"matchCriteriaId": "6990E97D-30E9-42A9-AE6A-CC597DF75B0B"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.3.1:*:*:*:*:*:*:*",
"matchCriteriaId": "15B60BA4-EA02-4D0D-82C3-1B08016EF5AE"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.3.1.1:*:*:*:*:*:*:*",
"matchCriteriaId": "E9DC51F7-72D4-4593-8DDE-8AA3955BB826"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.3.3:*:*:*:*:*:*:*",
"matchCriteriaId": "B047A011-1C27-4D86-99C1-BFCDC7F04A9B"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.3.3.1:*:*:*:*:*:*:*",
"matchCriteriaId": "DADEA8FB-3298-4534-B65E-81060E3DB45A"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.3.4:*:*:*:*:*:*:*",
"matchCriteriaId": "F4C6DF1F-4995-4486-8F90-9EFD6417ABA6"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.3.5:*:*:*:*:*:*:*",
"matchCriteriaId": "6D249954-93E0-4124-B9BA-84B9F34D7CB1"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.3.6:*:*:*:*:*:*:*",
"matchCriteriaId": "5B24396C-3732-4CF8-B01A-62C77D20E7FC"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.3.6.1:*:*:*:*:*:*:*",
"matchCriteriaId": "B7F20EBE-DFDF-4996-93D1-28EE776BC777"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.3.7:*:*:*:*:*:*:*",
"matchCriteriaId": "3DF09CAB-CA1B-428E-9A0B-AADACE9201A0"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.3.8:*:*:*:*:*:*:*",
"matchCriteriaId": "D99ED480-C206-48DD-9DF3-FC60D91B98A3"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.4.0:*:*:*:*:*:*:*",
"matchCriteriaId": "4DC515B6-27A3-4723-9792-2BA42EF63E44"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.4.0.1:*:*:*:*:*:*:*",
"matchCriteriaId": "DEC0BBDA-FAE5-4AF7-81C8-83041A58E8E7"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.4.1:*:*:*:*:*:*:*",
"matchCriteriaId": "7A066E28-31B0-46C7-ABB8-F5D1F3A303C9"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.4.3:*:*:*:*:*:*:*",
"matchCriteriaId": "C8F536CC-29D6-401E-92C5-964FDBDCCE65"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.4.4:*:*:*:*:*:*:*",
"matchCriteriaId": "9139593A-9414-488D-AA3A-5560C643587D"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.4.5:*:*:*:*:*:*:*",
"matchCriteriaId": "07BFB47E-F456-4782-98D7-68D02500FDD3"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.4.6:*:*:*:*:*:*:*",
"matchCriteriaId": "57F0D358-54BE-4A47-8B76-D23B5CCC4BE2"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.4.302:*:*:*:*:*:*:*",
"matchCriteriaId": "33BEBE47-AF47-4994-871D-5969270EE5AD"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.4.303:*:*:*:*:*:*:*",
"matchCriteriaId": "A27094E7-E6F3-47CA-A90A-86FEA2F1BE33"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:18.4.501_es:*:*:*:*:*:*:*",
"matchCriteriaId": "9B8958D8-389F-4FB6-8F29-621608FB2B32"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.0.0:*:*:*:*:*:*:*",
"matchCriteriaId": "37B66141-99E6-4D7D-8D11-18E9B34B002D"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.0.1a:*:*:*:*:*:*:*",
"matchCriteriaId": "40177056-0438-4BFF-ABD3-2328FE585800"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.1.0:*:*:*:*:*:*:*",
"matchCriteriaId": "6D6D47A0-43A2-4F9F-830B-B2FB79E779A5"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.2.0:*:*:*:*:*:*:*",
"matchCriteriaId": "87E7B932-950A-4573-832F-8477FABA5929"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.2.1:*:*:*:*:*:*:*",
"matchCriteriaId": "A1711A70-5931-4C1F-B522-46AD2E5D7C51"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.2.2:*:*:*:*:*:*:*",
"matchCriteriaId": "FE41B8AE-8F1E-4116-BDDC-65B913AD448E"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.2.3:*:*:*:*:*:*:*",
"matchCriteriaId": "7EC80219-C760-4CA8-B360-7B6545F502C2"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.2.31:*:*:*:*:*:*:*",
"matchCriteriaId": "F9E425CF-5773-4C17-B284-588DDCE8DE43"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.2.32:*:*:*:*:*:*:*",
"matchCriteriaId": "D89DEB9F-1F0A-4190-A9A7-2DE3949E5034"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.2.097:*:*:*:*:*:*:*",
"matchCriteriaId": "34886EDF-1C10-4F57-A82D-FF1AF668E2C1"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.2.098:*:*:*:*:*:*:*",
"matchCriteriaId": "B8EE5ECA-5D13-4C29-9396-95FFBEC4236A"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.2.099:*:*:*:*:*:*:*",
"matchCriteriaId": "1D7B3B10-6936-4352-9EE7-561BB1918769"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.2.929:*:*:*:*:*:*:*",
"matchCriteriaId": "1EB69F8B-67CB-4296-893A-7A35B155EBEA"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:19.3.0:*:*:*:*:*:*:*",
"matchCriteriaId": "491BD04C-85BE-4766-9965-59744D2639CE"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:20.1.1:*:*:*:*:*:*:*",
"matchCriteriaId": "545F75A3-451C-4993-98AE-51C23EF49927"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:20.1.1.1:*:*:*:*:*:*:*",
"matchCriteriaId": "1BB0DD6B-6C4D-4FF4-97AB-815A4566320F"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:20.1.2:*:*:*:*:*:*:*",
"matchCriteriaId": "5D144CB1-0AD1-4C8A-A709-52C26965675F"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:20.1.2_937:*:*:*:*:*:*:*",
"matchCriteriaId": "7D25B8C8-93E0-4ADF-B398-2071432B7012"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:20.1.12:*:*:*:*:*:*:*",
"matchCriteriaId": "482DC851-7E33-4487-8219-6675091FD7C7"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:catalyst_sd-wan_manager:20.3.1:*:*:*:*:*:*:*",
"matchCriteriaId": "BAFBFE36-6913-4122-A537-F2AA1562FE69"
}
]
}
]
}
],
"references": [
{
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdw-sqlinj-HDJUeEAX",
"source": "psirt@cisco.com"
"source": "psirt@cisco.com",
"tags": [
"Vendor Advisory"
]
},
{
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-vman-auth-bypass-Z3Zze5XC",
"source": "psirt@cisco.com"
"source": "psirt@cisco.com",
"tags": [
"Not Applicable"
]
},
{
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-vmanage-cql-inject-c7z9QqyB",
"source": "psirt@cisco.com"
"source": "psirt@cisco.com",
"tags": [
"Not Applicable"
]
}
]
}

32
CVE-2021/CVE-2021-313xx/CVE-2021-31314.json
View File

@ -2,7 +2,7 @@
"id": "CVE-2021-31314",
"sourceIdentifier": "cve@mitre.org",
"published": "2024-01-20T01:15:07.770",
"lastModified": "2024-11-21T06:05:24.550",
"lastModified": "2025-06-20T19:15:21.077",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
@ -36,6 +36,26 @@
},
"exploitabilityScore": 3.9,
"impactScore": 5.9
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"baseScore": 9.8,
"baseSeverity": "CRITICAL",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 3.9,
"impactScore": 5.9
}
]
},
@ -49,6 +69,16 @@
"value": "CWE-434"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-434"
}
]
}
],
"configurations": [

2
CVE-2021/CVE-2021-322xx/CVE-2021-32292.json
View File

@ -2,7 +2,7 @@
"id": "CVE-2021-32292",
"sourceIdentifier": "cve@mitre.org",
"published": "2023-08-22T19:16:20.350",
"lastModified": "2025-04-02T10:41:06.000",
"lastModified": "2025-06-25T16:55:47.280",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [

32
CVE-2021/CVE-2021-421xx/CVE-2021-42141.json
View File

@ -2,7 +2,7 @@
"id": "CVE-2021-42141",
"sourceIdentifier": "cve@mitre.org",
"published": "2024-01-22T23:15:08.120",
"lastModified": "2024-11-21T06:27:20.747",
"lastModified": "2025-06-20T19:15:21.277",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
@ -36,6 +36,26 @@
},
"exploitabilityScore": 3.9,
"impactScore": 5.9
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6
}
]
},
@ -49,6 +69,16 @@
"value": "CWE-755"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-755"
}
]
}
],
"configurations": [

32
CVE-2021/CVE-2021-421xx/CVE-2021-42143.json
View File

@ -2,7 +2,7 @@
"id": "CVE-2021-42143",
"sourceIdentifier": "cve@mitre.org",
"published": "2024-01-24T18:15:08.080",
"lastModified": "2024-11-21T06:27:21.117",
"lastModified": "2025-06-20T20:15:21.900",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
@ -36,6 +36,26 @@
},
"exploitabilityScore": 3.9,
"impactScore": 5.2
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"baseScore": 9.1,
"baseSeverity": "CRITICAL",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 3.9,
"impactScore": 5.2
}
]
},
@ -49,6 +69,16 @@
"value": "CWE-835"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-835"
}
]
}
],
"configurations": [

32
CVE-2021/CVE-2021-421xx/CVE-2021-42144.json
View File

@ -2,7 +2,7 @@
"id": "CVE-2021-42144",
"sourceIdentifier": "cve@mitre.org",
"published": "2024-01-24T18:15:08.150",
"lastModified": "2024-11-21T06:27:21.267",
"lastModified": "2025-06-20T20:15:22.800",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
@ -36,6 +36,26 @@
},
"exploitabilityScore": 3.9,
"impactScore": 5.9
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"availabilityImpact": "NONE"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6
}
]
},
@ -49,6 +69,16 @@
"value": "CWE-125"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-125"
}
]
}
],
"configurations": [

32
CVE-2021/CVE-2021-421xx/CVE-2021-42145.json
View File

@ -2,7 +2,7 @@
"id": "CVE-2021-42145",
"sourceIdentifier": "cve@mitre.org",
"published": "2024-01-24T19:15:08.420",
"lastModified": "2024-11-21T06:27:21.413",
"lastModified": "2025-06-20T20:15:22.943",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
@ -36,6 +36,26 @@
},
"exploitabilityScore": 3.9,
"impactScore": 3.6
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6
}
]
},
@ -49,6 +69,16 @@
"value": "CWE-755"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-755"
}
]
}
],
"configurations": [

32
CVE-2021/CVE-2021-421xx/CVE-2021-42146.json
View File

@ -2,7 +2,7 @@
"id": "CVE-2021-42146",
"sourceIdentifier": "cve@mitre.org",
"published": "2024-01-24T19:15:08.483",
"lastModified": "2024-11-21T06:27:21.553",
"lastModified": "2025-06-20T20:15:23.110",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
@ -36,6 +36,26 @@
},
"exploitabilityScore": 3.9,
"impactScore": 3.6
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "NONE",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"availabilityImpact": "NONE"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6
}
]
},
@ -49,6 +69,16 @@
"value": "CWE-755"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-303"
}
]
}
],
"configurations": [

8
CVE-2021/CVE-2021-436xx/CVE-2021-43635.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2021-43635",
"sourceIdentifier": "cve@mitre.org",
"published": "2022-02-04T18:15:07.287",
"lastModified": "2024-11-21T06:29:32.877",
"vulnStatus": "Undergoing Analysis",
"lastModified": "2025-06-20T20:06:20.077",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [
{
@ -85,9 +85,9 @@
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:a:codex_project:codex:*:*:*:*:*:*:*:*",
"criteria": "cpe:2.3:a:codexnotes:codex:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.4.0",
"matchCriteriaId": "A43C505F-D811-4731-880F-45CDDAC636AF"
"matchCriteriaId": "42AD3568-29D4-42CF-8511-21128C0B9281"
}
]
}

2
CVE-2021/CVE-2021-44xx/CVE-2021-4457.json
View File

@ -3,7 +3,7 @@
"sourceIdentifier": "contact@wpscan.com",
"published": "2025-06-25T15:15:21.100",
"lastModified": "2025-07-01T19:15:24.787",
"vulnStatus": "Awaiting Analysis",
"vulnStatus": "Undergoing Analysis",
"cveTags": [],
"descriptions": [
{

4
CVE-2021/CVE-2021-476xx/CVE-2021-47688.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In WhiteBeam 0.2.0 through 0.2.1 before 0.2.2, a user with local access to a server can bypass the allow-list functionality because a file can be truncated in the OpenFileDescriptor action before the VerifyCanWrite action is performed."
},
{
"lang": "es",
"value": "En WhiteBeam 0.2.0 a 0.2.1 antes de 0.2.2, un usuario con acceso local a un servidor puede omitir la funcionalidad de lista blanca porque un archivo se puede truncar en la acci\u00f3n OpenFileDescriptor antes de que se realice la acci\u00f3n VerifyCanWrite."
}
],
"metrics": {

566
CVE-2022/CVE-2022-206xx/CVE-2022-20685.json
View File

@ -2,8 +2,8 @@
"id": "CVE-2022-20685",
"sourceIdentifier": "psirt@cisco.com",
"published": "2024-11-15T16:15:21.910",
"lastModified": "2025-01-27T18:15:29.790",
"vulnStatus": "Undergoing Analysis",
"lastModified": "2025-06-24T14:47:25.657",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [
{
@ -81,14 +81,572 @@
]
}
],
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.0.0:*:*:*:*:*:*:*",
"matchCriteriaId": "3297323C-B263-45EA-90CE-2B8415C9E498"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.0.1:*:*:*:*:*:*:*",
"matchCriteriaId": "797AD8A4-083B-4A9E-A49D-65EE828E1637"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.0.2:*:*:*:*:*:*:*",
"matchCriteriaId": "4EB16212-A9DC-4C8C-B220-9619C65436EB"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.0.3:*:*:*:*:*:*:*",
"matchCriteriaId": "9C64043F-1F0D-47F7-AEEE-309B239891DB"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.0.4:*:*:*:*:*:*:*",
"matchCriteriaId": "7605B088-A708-40D3-806B-D7E460AE53DD"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.0.5:*:*:*:*:*:*:*",
"matchCriteriaId": "E1F7F871-C211-4DC6-8020-1075405BAE17"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.0.6:*:*:*:*:*:*:*",
"matchCriteriaId": "30E42800-B7C9-4006-8B7A-5A9A5F5EB234"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.1.0:*:*:*:*:*:*:*",
"matchCriteriaId": "EE33F541-232E-4432-AB41-EC0500A85E6D"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.1.1:*:*:*:*:*:*:*",
"matchCriteriaId": "8D5B5FDC-79B2-447E-816F-1F630508A889"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.1.2:*:*:*:*:*:*:*",
"matchCriteriaId": "B806EAC6-E1B2-40FB-9B2F-6AFB4A16AF89"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.2.0:*:*:*:*:*:*:*",
"matchCriteriaId": "D7BAC55C-C114-4E64-BC9E-9000B8C016CB"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.2.1:*:*:*:*:*:*:*",
"matchCriteriaId": "925E6B9B-F7F1-4ED8-8431-282A1061B527"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.2.2:*:*:*:*:*:*:*",
"matchCriteriaId": "A10EDC3E-0EF6-47DD-834D-51C5BBCC13EC"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.2.3:*:*:*:*:*:*:*",
"matchCriteriaId": "BB5F799E-6696-4391-9B58-06715FA4086A"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:3.2.4:*:*:*:*:*:*:*",
"matchCriteriaId": "EE31D26B-CD47-4853-B1C3-2E50B0882AFF"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:4.0.0:*:*:*:*:*:*:*",
"matchCriteriaId": "2758714C-4E9A-4442-9AD1-82D8E43995C9"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:cyber_vision:4.0.1:*:*:*:*:*:*:*",
"matchCriteriaId": "0F63C0E4-99A9-4D4F-BCF9-EF5F5455C04C"
}
]
}
]
},
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3:*:*:*:*:*:*:*",
"matchCriteriaId": "1D726F07-06F1-4B0A-B010-E607E0C2A280"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.1:*:*:*:*:*:*:*",
"matchCriteriaId": "0FAD2427-82A3-4E64-ADB5-FA4F40B568F9"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.2:*:*:*:*:*:*:*",
"matchCriteriaId": "08D5A647-AC21-40AC-8B3C-EE5D3EDA038A"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.3:*:*:*:*:*:*:*",
"matchCriteriaId": "0BAE999A-5244-46CF-8C12-D68E789BDEE1"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.4:*:*:*:*:*:*:*",
"matchCriteriaId": "D6468D3D-C5A7-4FAE-B4B9-AD862CD11055"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.5:*:*:*:*:*:*:*",
"matchCriteriaId": "D6E4808D-592E-46A6-A83A-A46227D817B8"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.6:*:*:*:*:*:*:*",
"matchCriteriaId": "1AB45136-ACCD-4230-8975-0EBB30D5B375"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.7:*:*:*:*:*:*:*",
"matchCriteriaId": "B2C39AC1-1B96-4253-9FC8-4CC26D6261F4"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.8:*:*:*:*:*:*:*",
"matchCriteriaId": "DE9102C8-F211-4E50-967F-FD51C7FC904F"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.9:*:*:*:*:*:*:*",
"matchCriteriaId": "B4933642-89E5-4909-AD3C-862CD3B77790"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.10:*:*:*:*:*:*:*",
"matchCriteriaId": "A9A6C776-79B3-47ED-B013-100B8F08E1C4"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.11:*:*:*:*:*:*:*",
"matchCriteriaId": "E504F28A-44CE-4B3E-9330-6A98728E3AEC"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.12:*:*:*:*:*:*:*",
"matchCriteriaId": "FEA0DD43-D206-4C1C-8B17-DA47F96B3BAC"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.13:*:*:*:*:*:*:*",
"matchCriteriaId": "1983172D-4F52-479F-BF14-A84B92D36864"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.14:*:*:*:*:*:*:*",
"matchCriteriaId": "4122D982-A57A-4249-A8DC-CE9FC6C98803"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.15:*:*:*:*:*:*:*",
"matchCriteriaId": "96464380-F665-4266-B0AD-693E078C9F82"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.16:*:*:*:*:*:*:*",
"matchCriteriaId": "4C230B8A-570D-4F58-83E1-AFA50B813EA4"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.17:*:*:*:*:*:*:*",
"matchCriteriaId": "FD3F39CB-C4C2-4B13-94F0-9E44322314BD"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.2.3.18:*:*:*:*:*:*:*",
"matchCriteriaId": "59A71873-0EB2-418F-AE33-8474A1010FA5"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0:*:*:*:*:*:*:*",
"matchCriteriaId": "B2DF0B07-8C2A-4341-8AFF-DE7E5E5B3A43"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0.1:*:*:*:*:*:*:*",
"matchCriteriaId": "6E6BD0EE-649E-4ED6-A09C-8364335DEF52"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0.2:*:*:*:*:*:*:*",
"matchCriteriaId": "1AE11554-FE3C-4C8B-8986-5D88E4967342"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0.3:*:*:*:*:*:*:*",
"matchCriteriaId": "E1C11983-22A8-4859-A240-571A7815FF54"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0.4:*:*:*:*:*:*:*",
"matchCriteriaId": "24CD0B0A-2B91-45DD-9522-8D1D3850CC9B"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0.5:*:*:*:*:*:*:*",
"matchCriteriaId": "B7026F0E-72A7-4CDF-BADC-E34FE6FADC51"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0.6:*:*:*:*:*:*:*",
"matchCriteriaId": "63B85369-FBAE-456C-BC99-5418B043688A"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0.7:*:*:*:*:*:*:*",
"matchCriteriaId": "86434346-D5F0-49BA-803E-244C3266E361"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0.8:*:*:*:*:*:*:*",
"matchCriteriaId": "D2FA7B3C-002D-4755-B323-CA24B770A5B9"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0.9:*:*:*:*:*:*:*",
"matchCriteriaId": "F1CB7EBC-F3D5-4855-A8D8-BA5AB21FD719"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0.10:*:*:*:*:*:*:*",
"matchCriteriaId": "F2A5530C-DF29-421B-9712-3454C1769446"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0.11:*:*:*:*:*:*:*",
"matchCriteriaId": "41170977-FEEA-4B51-BF98-8493096CD691"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.4.0.12:*:*:*:*:*:*:*",
"matchCriteriaId": "B05791F9-0B31-4C4C-A9BA-9268CAA45FB2"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.6.0:*:*:*:*:*:*:*",
"matchCriteriaId": "DCD69468-8067-4A5D-B2B0-EC510D889AA0"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.6.0.1:*:*:*:*:*:*:*",
"matchCriteriaId": "20AE4051-FA3B-4F0B-BD3D-083A14269FF6"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.6.1:*:*:*:*:*:*:*",
"matchCriteriaId": "46A42D07-FF3E-41B4-BA39-3A5BDA4E0E61"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.6.3:*:*:*:*:*:*:*",
"matchCriteriaId": "3985EA37-2B77-45F2-ABA5-5CCC7B35CA2E"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.6.4:*:*:*:*:*:*:*",
"matchCriteriaId": "67FB5ABE-3C40-4C58-B91F-0621C2180FAC"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.6.5:*:*:*:*:*:*:*",
"matchCriteriaId": "53909FD6-EC74-4D2F-99DA-26E70400B53F"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.7.0:*:*:*:*:*:*:*",
"matchCriteriaId": "85F22403-B4EE-4303-9C94-915D3E0AC944"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.7.0.1:*:*:*:*:*:*:*",
"matchCriteriaId": "828E3DE1-B62E-4FEC-AAD3-EB0E452C9CBC"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.7.0.2:*:*:*:*:*:*:*",
"matchCriteriaId": "596EC5DD-D7F4-44C8-B4B5-E2DC142FC486"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:6.7.0.3:*:*:*:*:*:*:*",
"matchCriteriaId": "C356E0E6-5B87-40CF-996E-6FFEDFD82A31"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:7.0.0:*:*:*:*:*:*:*",
"matchCriteriaId": "BBCA75A6-0A3E-4393-8884-9F3CE190641E"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:a:cisco:firepower_threat_defense:7.0.0.1:*:*:*:*:*:*:*",
"matchCriteriaId": "3F3C12D3-7662-46C5-9E88-D1BE6CF605E0"
}
]
}
]
},
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:3.17.0s:*:*:*:*:*:*:*",
"matchCriteriaId": "CE3E6C71-2A80-45CE-8113-38AE35749E6C"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:3.17.1s:*:*:*:*:*:*:*",
"matchCriteriaId": "9D6BEE46-D928-4214-A2C9-88AC63DFE2FF"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:16.6.1:*:*:*:*:*:*:*",
"matchCriteriaId": "12C50D98-0CAE-4E61-BFFC-8E91A97BED35"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:16.6.5:*:*:*:*:*:*:*",
"matchCriteriaId": "162956CE-1B24-41C6-A7C5-BCA214587CD0"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:16.6.6:*:*:*:*:*:*:*",
"matchCriteriaId": "146D7432-4357-409A-8E6D-C9D04CF43ADC"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:16.6.7a:*:*:*:*:*:*:*",
"matchCriteriaId": "540DBCF6-3733-4E0C-94C9-58B98D13E35D"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:16.6.9:*:*:*:*:*:*:*",
"matchCriteriaId": "68BB8A38-693D-4768-A917-81FF9E898AEF"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:16.6.10:*:*:*:*:*:*:*",
"matchCriteriaId": "90BCC057-5064-4FE5-B2C8-2EB14A59D763"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:16.12.1a:*:*:*:*:*:*:*",
"matchCriteriaId": "0D7C20FF-6587-4E62-9318-03B4C61AC70C"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:16.12.2:*:*:*:*:*:*:*",
"matchCriteriaId": "FA0536C6-5F9E-48A7-A004-F0F5FE9C83E7"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:16.12.3:*:*:*:*:*:*:*",
"matchCriteriaId": "11FF3577-FC7E-4CAE-8B06-CAFAB97D7D7D"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:16.12.4:*:*:*:*:*:*:*",
"matchCriteriaId": "9F8DC147-FB97-4364-9520-6E69C282424F"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:16.12.5:*:*:*:*:*:*:*",
"matchCriteriaId": "88D51165-6AF2-4E61-83DC-D04EC90ED435"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:16.12.6:*:*:*:*:*:*:*",
"matchCriteriaId": "CC483F1B-D09E-486A-99FF-D7C0872C5CA2"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.1.1:*:*:*:*:*:*:*",
"matchCriteriaId": "AFA2C618-C2DA-4194-869D-1F0198A361B4"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.2.1r:*:*:*:*:*:*:*",
"matchCriteriaId": "2FEB2A57-CF8F-4E87-939A-5B3EF7E5E0A9"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.3.1a:*:*:*:*:*:*:*",
"matchCriteriaId": "7BA9E488-2A54-4226-B413-89D141362350"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.3.2:*:*:*:*:*:*:*",
"matchCriteriaId": "359EDE5C-4017-487A-B3D3-F22A42165E89"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.3.3:*:*:*:*:*:*:*",
"matchCriteriaId": "D024AF06-DCB5-44B4-A985-07EDC093DBB0"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.3.4:*:*:*:*:*:*:*",
"matchCriteriaId": "373F1DDC-E1A7-496F-A86D-3724266D3143"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.3.4a:*:*:*:*:*:*:*",
"matchCriteriaId": "A28594C9-139A-4EE4-81D9-C7E96A1DD886"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.4.1a:*:*:*:*:*:*:*",
"matchCriteriaId": "018F06B0-1486-4822-B2EA-4449652919EC"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.4.1b:*:*:*:*:*:*:*",
"matchCriteriaId": "ADEC96FA-5B14-43AD-B83A-AA630941DD5F"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.4.2:*:*:*:*:*:*:*",
"matchCriteriaId": "6D3B1688-5301-4799-9AAC-DC7ED4497AAE"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.5.1:*:*:*:*:*:*:*",
"matchCriteriaId": "8B5FDEDF-B870-4204-BADC-92805F431BAC"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.5.1a:*:*:*:*:*:*:*",
"matchCriteriaId": "B0A61788-FA7B-4506-90DF-17ED5053C3A0"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.6.1a:*:*:*:*:*:*:*",
"matchCriteriaId": "245ED9C3-4B16-4CC1-BC78-B4AED938C0B6"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:17.7.1a:*:*:*:*:*:*:*",
"matchCriteriaId": "D39700C2-E83C-4ECE-9640-CEFBDD18DC4C"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:denali-16.3.3:*:*:*:*:*:*:*",
"matchCriteriaId": "2CC7F6B1-FD0C-4D68-9DA2-B34096899C0C"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:denali-16.3.4:*:*:*:*:*:*:*",
"matchCriteriaId": "39C52FF5-F2A8-41DD-A584-FD16CE143329"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:denali-16.3.5:*:*:*:*:*:*:*",
"matchCriteriaId": "A629FCAF-0F3C-43C9-8BDB-68D9EE675A43"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:denali-16.3.7:*:*:*:*:*:*:*",
"matchCriteriaId": "0E8F55F7-9FF4-4A97-925C-F828701BA18E"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:denali-16.3.9:*:*:*:*:*:*:*",
"matchCriteriaId": "ACE7D048-0D0B-4E48-8E57-192B02F5CD1D"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:everest-16.6.2:*:*:*:*:*:*:*",
"matchCriteriaId": "2E7B2DC4-3971-4D60-B9F9-282332E6CBEE"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:everest-16.6.3:*:*:*:*:*:*:*",
"matchCriteriaId": "8B88058B-F68D-4901-8BB0-30E8BE9A98B1"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:everest-16.6.4:*:*:*:*:*:*:*",
"matchCriteriaId": "7271541D-6563-4DE7-9085-E6CB66583C2D"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:fuji-16.9.2:*:*:*:*:*:*:*",
"matchCriteriaId": "C956E85E-B778-43E3-ABBE-4C373FF474A5"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:fuji-16.9.3:*:*:*:*:*:*:*",
"matchCriteriaId": "A31CEA23-B824-4D43-9FED-16071985C822"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:fuji-16.9.4:*:*:*:*:*:*:*",
"matchCriteriaId": "E59FDC96-71AC-4FC7-BA0A-1EAC301362D0"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:fuji-16.9.5:*:*:*:*:*:*:*",
"matchCriteriaId": "DADBCC11-AF7D-41EA-B88F-F4B72F90B258"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:fuji-16.9.6:*:*:*:*:*:*:*",
"matchCriteriaId": "32867BBF-E973-4B9E-895A-4E75C5F7F35F"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:fuji-16.9.7:*:*:*:*:*:*:*",
"matchCriteriaId": "9B13ACF4-20B5-4DC8-BDDA-144AFA1DFD55"
},
{
"vulnerable": true,
"criteria": "cpe:2.3:o:cisco:unified_threat_defense_snort_intrusion_prevention_system_engine:fuji-16.9.8:*:*:*:*:*:*:*",
"matchCriteriaId": "6D94B404-B1F4-42D4-ACF6-4F84F2B34F80"
}
]
}
]
}
],
"references": [
{
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sna-xss-NXOxDhRQ",
"source": "psirt@cisco.com"
"source": "psirt@cisco.com",
"tags": [
"Not Applicable"
]
},
{
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort-dos-9D3hJLuj",
"source": "psirt@cisco.com"
"source": "psirt@cisco.com",
"tags": [
"Vendor Advisory"
]
}
]
}

6
CVE-2022/CVE-2022-432xx/CVE-2022-43216.json
View File

@ -2,7 +2,7 @@
"id": "CVE-2022-43216",
"sourceIdentifier": "cve@mitre.org",
"published": "2024-04-08T12:15:08.017",
"lastModified": "2025-06-18T18:34:07.987",
"lastModified": "2025-06-20T18:56:22.150",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [
@ -60,9 +60,9 @@
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:a:abrhil:lista_de_asistenci:*:*:*:*:*:*:*:*",
"criteria": "cpe:2.3:a:abrhil:lista_de_asistencia:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.6.2",
"matchCriteriaId": "C87E0702-92E1-4AE1-A140-663508A414EC"
"matchCriteriaId": "C4444846-0287-48F8-9061-2833B3597D05"
}
]
}

6
CVE-2022/CVE-2022-481xx/CVE-2022-48174.json
View File

@ -2,7 +2,7 @@
"id": "CVE-2022-48174",
"sourceIdentifier": "cve@mitre.org",
"published": "2023-08-22T19:16:31.080",
"lastModified": "2025-02-05T18:02:49.267",
"lastModified": "2025-06-25T14:24:41.033",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [
@ -57,8 +57,8 @@
{
"vulnerable": true,
"criteria": "cpe:2.3:a:busybox:busybox:*:*:*:*:*:*:*:*",
"versionEndIncluding": "1.35.0",
"matchCriteriaId": "50324EB3-E070-4585-A2F4-DE7C0D1932B3"
"versionEndIncluding": "1.36.1",
"matchCriteriaId": "82CC192B-C581-4846-AB6D-107055763145"
}
]
}

4
CVE-2022/CVE-2022-499xx/CVE-2022-49934.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Fix UAF in ieee80211_scan_rx()\n\nieee80211_scan_rx() tries to access scan_req->flags after a\nnull check, but a UAF is observed when the scan is completed\nand __ieee80211_scan_completed() executes, which then calls\ncfg80211_scan_done() leading to the freeing of scan_req.\n\nSince scan_req is rcu_dereference()'d, prevent the racing in\n__ieee80211_scan_completed() by ensuring that from mac80211's\nPOV it is no longer accessed from an RCU read critical section\nbefore we call cfg80211_scan_done()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: Se ha corregido el UAF en ieee80211_scan_rx(). ieee80211_scan_rx() intenta acceder a scan_req->flags tras una comprobaci\u00f3n nula, pero se observa un UAF al finalizar el escaneo y se ejecuta __ieee80211_scan_completed(), que a su vez llama a cfg80211_scan_done(), lo que libera scan_req. Dado que scan_req est\u00e1 desreferenciado mediante rcu_dereference(), se debe evitar la aceleraci\u00f3n en __ieee80211_scan_completed() asegur\u00e1ndose de que, desde el punto de vista de mac80211, ya no se acceda a \u00e9l desde una secci\u00f3n cr\u00edtica de lectura de RCU antes de llamar a cfg80211_scan_done()."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49935.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf/dma-resv: check if the new fence is really later\n\nPreviously when we added a fence to a dma_resv object we always\nassumed the the newer than all the existing fences.\n\nWith Jason's work to add an UAPI to explicit export/import that's not\nnecessary the case any more. So without this check we would allow\nuserspace to force the kernel into an use after free error.\n\nSince the change is very small and defensive it's probably a good\nidea to backport this to stable kernels as well just in case others\nare using the dma_resv object in the same way."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf/dma-resv: comprobar si la nueva valla es realmente posterior. Anteriormente, al a\u00f1adir una valla a un objeto dma_resv, siempre supon\u00edamos que era m\u00e1s reciente que todas las vallas existentes. Gracias al trabajo de Jason para a\u00f1adir una UAPI a la exportaci\u00f3n/importaci\u00f3n expl\u00edcita, esto ya no es necesario. Por lo tanto, sin esta comprobaci\u00f3n, permitir\u00edamos que el espacio de usuario forzara al kernel a un error de Use-After-Free. Dado que el cambio es muy peque\u00f1o y defensivo, probablemente sea buena idea retroportarlo tambi\u00e9n a los kernels estables, por si acaso otros utilizan el objeto dma_resv de la misma manera."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49936.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: core: Prevent nested device-reset calls\n\nAutomatic kernel fuzzing revealed a recursive locking violation in\nusb-storage:\n\n============================================\nWARNING: possible recursive locking detected\n5.18.0 #3 Not tainted\n--------------------------------------------\nkworker/1:3/1205 is trying to acquire lock:\nffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:\nusb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230\n\nbut task is already holding lock:\nffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at:\nusb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230\n\n...\n\nstack backtrace:\nCPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.13.0-1ubuntu1.1 04/01/2014\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n<TASK>\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\nprint_deadlock_bug kernel/locking/lockdep.c:2988 [inline]\ncheck_deadlock kernel/locking/lockdep.c:3031 [inline]\nvalidate_chain kernel/locking/lockdep.c:3816 [inline]\n__lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053\nlock_acquire kernel/locking/lockdep.c:5665 [inline]\nlock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630\n__mutex_lock_common kernel/locking/mutex.c:603 [inline]\n__mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747\nusb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230\nusb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109\nr871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622\nusb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458\ndevice_remove drivers/base/dd.c:545 [inline]\ndevice_remove+0x11f/0x170 drivers/base/dd.c:537\n__device_release_driver drivers/base/dd.c:1222 [inline]\ndevice_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248\nusb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627\nusb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118\nusb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114\n\nThis turned out not to be an error in usb-storage but rather a nested\ndevice reset attempt. That is, as the rtl8712 driver was being\nunbound from a composite device in preparation for an unrelated USB\nreset (that driver does not have pre_reset or post_reset callbacks),\nits ->remove routine called usb_reset_device() -- thus nesting one\nreset call within another.\n\nPerforming a reset as part of disconnect processing is a questionable\npractice at best. However, the bug report points out that the USB\ncore does not have any protection against nested resets. Adding a\nreset_in_progress flag and testing it will prevent such errors in the\nfuture."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: n\u00facleo: evitar llamadas de reinicio de dispositivo anidadas. El fuzzing autom\u00e1tico del kernel revel\u00f3 una violaci\u00f3n de bloqueo recursivo en usb-storage: ============================================== ADVERTENCIA: posible bloqueo recursivo detectado 5.18.0 #3 No contaminado -------------------------------------------- kworker/1:3/1205 est\u00e1 intentando adquirir el bloqueo: ffff888018638db8 (&amp;us_interface_key[i]){+.+.}-{3:3}, en: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 pero la tarea ya est\u00e1 manteniendo el bloqueo: ffff888018638db8 (&amp;us_interface_key[i]){+.+.}-{3:3}, en: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 ... seguimiento de pila: CPU: 1 PID: 1205 Comm: kworker/1:3 No contaminado 5.18.0 #3 Nombre de hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Cola de trabajo: usb_hub_wq hub_event Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2988 [inline] check_deadlock kernel/locking/lockdep.c:3031 [inline] validate_chain kernel/locking/lockdep.c:3816 [inline] __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053 lock_acquire kernel/locking/lockdep.c:5665 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630 __mutex_lock_common kernel/locking/mutex.c:603 [inline] __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747 usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109 r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622 usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458 device_remove drivers/base/dd.c:545 [inline] device_remove+0x11f/0x170 drivers/base/dd.c:537 __device_release_driver drivers/base/dd.c:1222 [inline] device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248 usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627 usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118 usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114 Result\u00f3 que esto no era un error en usb-storage sino m\u00e1s bien un intento de reinicio de dispositivo anidado. Es decir, como el controlador rtl8712 se estaba desvinculando de un dispositivo compuesto en preparaci\u00f3n para un reinicio USB no relacionado (ese controlador no tiene devoluciones de llamada pre_reset o post_reset), su rutina -&gt;remove llam\u00f3 a usb_reset_device() - anidando as\u00ed una llamada de reinicio dentro de otra. Realizar un reinicio como parte del procesamiento de desconexi\u00f3n es una pr\u00e1ctica cuestionable en el mejor de los casos. Sin embargo, el informe de errores se\u00f1ala que el n\u00facleo USB no tiene ninguna protecci\u00f3n contra reinicios anidados. Agregar un indicador reset_in_progress y probarlo evitar\u00e1 tales errores en el futuro. "
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49937.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mceusb: Use new usb_control_msg_*() routines\n\nAutomatic kernel fuzzing led to a WARN about invalid pipe direction in\nthe mceusb driver:\n\n------------[ cut here ]------------\nusb 6-1: BOGUS control dir, pipe 80000380 doesn't match bRequestType 40\nWARNING: CPU: 0 PID: 2465 at drivers/usb/core/urb.c:410\nusb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410\nModules linked in:\nCPU: 0 PID: 2465 Comm: kworker/0:2 Not tainted 5.19.0-rc4-00208-g69cb6c6556ad #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.13.0-1ubuntu1.1 04/01/2014\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410\nCode: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8\n44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 <0f> 0b\ne9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 ff 41\nRSP: 0018:ffffc900032becf0 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000\nRDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90\nRBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 0000000000000000\nR10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000\nR13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500\nFS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0\nCall Trace:\n<TASK>\nusb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58\nusb_internal_control_msg drivers/usb/core/message.c:102 [inline]\nusb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153\nmceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline]\nmceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807\n\nThe reason for the warning is clear enough; the driver sends an\nunusual read request on endpoint 0 but does not set the USB_DIR_IN bit\nin the bRequestType field.\n\nMore importantly, the whole situation can be avoided and the driver\nsimplified by converting it over to the relatively new\nusb_control_msg_recv() and usb_control_msg_send() routines. That's\nwhat this fix does."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: mceusb: Utilizar nuevas rutinas usb_control_msg_*() El fuzzing autom\u00e1tico del kernel provoc\u00f3 una ADVERTENCIA sobre una direcci\u00f3n de tuber\u00eda no v\u00e1lida en el controlador mceusb: ------------[ cortar aqu\u00ed ]------------ usb 6-1: directorio de control FALSO, la tuber\u00eda 80000380 no coincide con bRequestType 40 ADVERTENCIA: CPU: 0 PID: 2465 en drivers/usb/core/urb.c:410 usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410 M\u00f3dulos vinculados: CPU: 0 PID: 2465 Comm: kworker/0:2 No contaminado 5.19.0-rc4-00208-g69cb6c6556ad #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Cola de trabajo: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0x1326/0x1820 drivers/usb/core/urb.c:410 C\u00f3digo: 7c 24 40 e8 ac 23 91 fd 48 8b 7c 24 40 e8 b2 70 1b ff 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 a0 30 a9 86 e8 48 07 11 02 &lt;0f&gt; 0b e9 1c f0 ff ff e8 7e 23 91 fd 0f b6 1d 63 22 83 05 31 y siguientes 41 RSP: 0018:ffffc900032becf0 EFLAGS: 00010282 RAX: 000000000000000 RBX: ffff8881100f3058 RCX: 0000000000000000 RDX: ffffc90004961000 RSI: ffff888114c6d580 RDI: fffff52000657d90 RBP: ffff888105ad90f0 R08: ffffffff812c3638 R09: 000000000000000 R10: 0000000000000005 R11: ffffed1023504ef1 R12: ffff888105ad9000 R13: 0000000000000040 R14: 0000000080000380 R15: ffff88810ba96500 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe810bda58 CR3: 000000010b720000 CR4: 0000000000350ef0 Seguimiento de llamadas: usb_start_wait_urb+0x101/0x4c0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 mceusb_gen1_init drivers/media/rc/mceusb.c:1431 [inline] mceusb_dev_probe+0x258e/0x33f0 drivers/media/rc/mceusb.c:1807 El motivo de la advertencia es bastante claro; el controlador env\u00eda una solicitud de lectura inusual en el endpoint 0 pero no establece el bit USB_DIR_IN en el campo bRequestType. M\u00e1s importante a\u00fan, se puede evitar toda la situaci\u00f3n y simplificar el controlador al convertirlo a las relativamente nuevas rutinas usb_control_msg_recv() y usb_control_msg_send(). Esto es lo que hace esta correcci\u00f3n."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49938.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix small mempool leak in SMB2_negotiate()\n\nIn some cases of failure (dialect mismatches) in SMB2_negotiate(), after\nthe request is sent, the checks would return -EIO when they should be\nrather setting rc = -EIO and jumping to neg_exit to free the response\nbuffer from mempool."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: corrige una peque\u00f1a p\u00e9rdida de mempool en SMB2_negotiate() En algunos casos de falla (desajustes de dialecto) en SMB2_negotiate(), despu\u00e9s de enviar la solicitud, las verificaciones devolver\u00edan -EIO cuando deber\u00edan establecer rc = -EIO y saltar a neg_exit para liberar el b\u00fafer de respuesta de mempool."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49939.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix UAF of ref->proc caused by race condition\n\nA transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the\nreference for a node. In this case, the target proc normally releases\nthe failed reference upon close as expected. However, if the target is\ndying in parallel the call will race with binder_deferred_release(), so\nthe target could have released all of its references by now leaving the\ncleanup of the new failed reference unhandled.\n\nThe transaction then ends and the target proc gets released making the\nref->proc now a dangling pointer. Later on, ref->node is closed and we\nattempt to take spin_lock(&ref->proc->inner_lock), which leads to the\nuse-after-free bug reported below. Let's fix this by cleaning up the\nfailed reference on the spot instead of relying on the target to do so.\n\n ==================================================================\n BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150\n Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590\n\n CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10\n Hardware name: linux,dummy-virt (DT)\n Workqueue: events binder_deferred_func\n Call trace:\n dump_backtrace.part.0+0x1d0/0x1e0\n show_stack+0x18/0x70\n dump_stack_lvl+0x68/0x84\n print_report+0x2e4/0x61c\n kasan_report+0xa4/0x110\n kasan_check_range+0xfc/0x1a4\n __kasan_check_write+0x3c/0x50\n _raw_spin_lock+0xa8/0x150\n binder_deferred_func+0x5e0/0x9b0\n process_one_work+0x38c/0x5f0\n worker_thread+0x9c/0x694\n kthread+0x188/0x190\n ret_from_fork+0x10/0x20"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: arreglo UAF de ref-&gt;proc causado por condici\u00f3n de ejecuci\u00f3n Una transacci\u00f3n de tipo BINDER_TYPE_WEAK_HANDLE puede fallar al incrementar la referencia para un nodo. En este caso, el proc objetivo normalmente libera la referencia fallida al cerrar como se espera. Sin embargo, si el objetivo est\u00e1 muriendo en paralelo la llamada competir\u00e1 con binder_deferred_release(), por lo que el objetivo podr\u00eda haber liberado todas sus referencias por ahora dejando la limpieza de la nueva referencia fallida sin manejar. La transacci\u00f3n entonces termina y el proc objetivo se libera haciendo que ref-&gt;proc ahora sea un puntero colgante. M\u00e1s tarde, ref-&gt;node se cierra e intentamos tomar spin_lock(&amp;ref-&gt;proc-&gt;inner_lock), lo que lleva al error de Use-After-Free reportado a continuaci\u00f3n. Vamos a arreglar esto limpiando la referencia fallida en el acto en lugar de depender de que el objetivo lo haga. ====================================================================== ERROR: KASAN: Use-After-Free en _raw_spin_lock+0xa8/0x150 Escritura de tama\u00f1o 4 en la direcci\u00f3n ffff5ca207094238 por la tarea kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 No contaminado 5.19.0-rc8 #10 Nombre del hardware: linux,dummy-virt (DT) Cola de trabajo: eventos binder_deferred_func Rastreo de llamadas: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20 "
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49940.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: n_gsm: add sanity check for gsm->receive in gsm_receive_buf()\n\nA null pointer dereference can happen when attempting to access the\n\"gsm->receive()\" function in gsmld_receive_buf(). Currently, the code\nassumes that gsm->recieve is only called after MUX activation.\nSince the gsmld_receive_buf() function can be accessed without the need to\ninitialize the MUX, the gsm->receive() function will not be set and a\nNULL pointer dereference will occur.\n\nFix this by avoiding the call to \"gsm->receive()\" in case the function is\nnot initialized by adding a sanity check.\n\nCall Trace:\n <TASK>\n gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861\n tiocsti drivers/tty/tty_io.c:2293 [inline]\n tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:870 [inline]\n __se_sys_ioctl fs/ioctl.c:856 [inline]\n __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: n_gsm: a\u00f1adir comprobaci\u00f3n de validez para gsm-&gt;receive en gsm_receive_buf(). Se puede producir una desreferencia de puntero nulo al intentar acceder a la funci\u00f3n \"gsm-&gt;receive()\" en gsmld_receive_buf(). Actualmente, el c\u00f3digo asume que gsm-&gt;recieve solo se llama despu\u00e9s de la activaci\u00f3n del MUX. Dado que se puede acceder a la funci\u00f3n gsmld_receive_buf() sin necesidad de inicializar el MUX, esta funci\u00f3n no se activar\u00e1 y se producir\u00e1 una desreferencia de puntero nulo. Para solucionar esto, se debe evitar la llamada a \"gsm-&gt;receive()\" si la funci\u00f3n no se inicializa mediante una comprobaci\u00f3n de validez. Rastreo de llamadas: gsmld_receive_buf+0x1c2/0x2f0 drivers/tty/n_gsm.c:2861 tiocsti drivers/tty/tty_io.c:2293 [en l\u00ednea] tty_ioctl+0xa75/0x15d0 drivers/tty/tty_io.c:2692 vfs_ioctl fs/ioctl.c:51 [en l\u00ednea] __do_sys_ioctl fs/ioctl.c:870 [en l\u00ednea] __se_sys_ioctl fs/ioctl.c:856 [en l\u00ednea] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [en l\u00ednea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49942.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Don't finalize CSA in IBSS mode if state is disconnected\n\nWhen we are not connected to a channel, sending channel \"switch\"\nannouncement doesn't make any sense.\n\nThe BSS list is empty in that case. This causes the for loop in\ncfg80211_get_bss() to be bypassed, so the function returns NULL\n(check line 1424 of net/wireless/scan.c), causing the WARN_ON()\nin ieee80211_ibss_csa_beacon() to get triggered (check line 500\nof net/mac80211/ibss.c), which was consequently reported on the\nsyzkaller dashboard.\n\nThus, check if we have an existing connection before generating\nthe CSA beacon in ieee80211_ibss_finish_csa()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: No finalizar la CSA en modo IBSS si el estado es desconectado. Cuando no estamos conectados a un canal, enviar el anuncio de cambio de canal no tiene sentido. En ese caso, la lista BSS est\u00e1 vac\u00eda. Esto provoca que se omita el bucle for en cfg80211_get_bss(), por lo que la funci\u00f3n devuelve NULL (consulte la l\u00ednea 1424 de net/wireless/scan.c), lo que provoca la activaci\u00f3n de WARN_ON() en ieee80211_ibss_csa_beacon() (consulte la l\u00ednea 500 de net/mac80211/ibss.c), lo que se inform\u00f3 en el panel de control de syzkaller. Por lo tanto, se debe comprobar si existe una conexi\u00f3n antes de generar la baliza CSA en ieee80211_ibss_finish_csa()."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49943.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: Fix obscure lockdep violation for udc_mutex\n\nA recent commit expanding the scope of the udc_lock mutex in the\ngadget core managed to cause an obscure and slightly bizarre lockdep\nviolation. In abbreviated form:\n\n======================================================\nWARNING: possible circular locking dependency detected\n5.19.0-rc7+ #12510 Not tainted\n------------------------------------------------------\nudevadm/312 is trying to acquire lock:\nffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0\n\nbut task is already holding lock:\nffff000002277548 (kn->active#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-> #3 (kn->active#4){++++}-{0:0}:\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 lock_acquire+0x68/0x84\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 __kernfs_remove+0x268/0x380\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 kernfs_remove_by_name_ns+0x58/0xac\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 sysfs_remove_file_ns+0x18/0x24\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 device_del+0x15c/0x440\n\n-> #2 (device_links_lock){+.+.}-{3:3}:\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 lock_acquire+0x68/0x84\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 __mutex_lock+0x9c/0x430\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 mutex_lock_nested+0x38/0x64\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 device_link_remove+0x3c/0xa0\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 _regulator_put.part.0+0x168/0x190\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 regulator_put+0x3c/0x54\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 devm_regulator_release+0x14/0x20\n\n-> #1 (regulator_list_mutex){+.+.}-{3:3}:\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 lock_acquire+0x68/0x84\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 __mutex_lock+0x9c/0x430\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 mutex_lock_nested+0x38/0x64\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 regulator_lock_dependent+0x54/0x284\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 regulator_enable+0x34/0x80\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 phy_power_on+0x24/0x130\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 __dwc2_lowlevel_hw_enable+0x100/0x130\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 dwc2_lowlevel_hw_enable+0x18/0x40\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 dwc2_hsotg_udc_start+0x6c/0x2f0\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 gadget_bind_driver+0x124/0x1f4\n\n-> #0 (udc_lock){+.+.}-{3:3}:\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 __lock_acquire+0x1298/0x20cc\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 lock_acquire.part.0+0xe0/0x230\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 lock_acquire+0x68/0x84\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 __mutex_lock+0x9c/0x430\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 mutex_lock_nested+0x38/0x64\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 usb_udc_uevent+0x54/0xe0\n\nEvidently this was caused by the scope of udc_mutex being too large.\nThe mutex is only meant to protect udc->driver along with a few other\nthings. As far as I can tell, there's no reason for the mutex to be\nheld while the gadget core calls a gadget driver's ->bind or ->unbind\nroutine, or while a UDC is being started or stopped. (This accounts\nfor link #1 in the chain above, where the mutex is held while the\ndwc2_hsotg_udc is started as part of driver probing.)\n\nGadget drivers' ->disconnect callbacks are problematic. Even though\nusb_gadget_disconnect() will now acquire the udc_mutex, there's a\nwindow in usb_gadget_bind_driver() between the times when the mutex is\nreleased and the ->bind callback is invoked. If a disconnect occurred\nduring that window, we could call the driver's ->disconnect routine\nbefore its ->bind routine. To prevent this from happening, it will be\nnecessary to prevent a UDC from connecting while it has no gadget\ndriver. This should be done already but it doesn't seem to be;\ncurrently usb_gadget_connect() has no check for this. Such a check\nwill have to be added later.\n\nSome degree of mutual exclusion is required in soft_connect_store(),\nwhich can dereference udc->driver at arbitrary times since it is a\nsysfs callback. The solution here is to acquire the gadget's device\nlock rather than the udc_mutex. Since the driver core guarantees that\nthe device lock is always held during driver binding and unbinding,\nthis will make the accesses in soft_connect_store() mutually exclusive\nwith any changes to udc->driver.\n\nLastly, it turns out there is one place which should hold the\nudc_mutex but currently does not: The function_show() routine needs\nprotection while it dereferences udc->driver. The missing lock and\nunlock calls are added."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: gadget: Se corrige una oscura violaci\u00f3n de lockdep para udc_mutex. Una confirmaci\u00f3n reciente que expandi\u00f3 el alcance del mutex udc_lock en el n\u00facleo del gadget logr\u00f3 causar una oscura y ligeramente extra\u00f1a violaci\u00f3n de lockdep. En forma abreviada: ======================================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 5.19.0-rc7+ #12510 No contaminado ------------------------------------------------------ udevadm/312 est\u00e1 intentando adquirir el bloqueo: ffff80000aae1058 (udc_lock){+.+.}-{3:3}, en: usb_udc_uevent+0x54/0xe0 pero la tarea ya tiene el bloqueo: ffff000002277548 (kn-&gt;active#4){++++}-{0:0}, en: kernfs_seq_start+0x34/0xe0 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -&gt; #3 (kn-&gt;active#4){++++}-{0:0}: lock_acquire+0x68/0x84 __kernfs_remove+0x268/0x380 kernfs_remove_by_name_ns+0x58/0xac sysfs_remove_file_ns+0x18/0x24 device_del+0x15c/0x440 -&gt; #2 (device_links_lock){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 device_link_remove+0x3c/0xa0 _regulator_put.part.0+0x168/0x190 regulator_put+0x3c/0x54 devm_regulator_release+0x14/0x20 -&gt; #1 (mutex_lista_regulador){+.+.}-{3:3}: adquisici\u00f3n_bloqueo+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 regulator_lock_dependent+0x54/0x284 regulator_enable+0x34/0x80 phy_power_on+0x24/0x130 __dwc2_lowlevel_hw_enable+0x100/0x130 dwc2_lowlevel_hw_enable+0x18/0x40 dwc2_hsotg_udc_start+0x6c/0x2f0 gadget_bind_driver+0x124/0x1f4 -&gt; #0 (udc_lock){+.+.}-{3:3}: __lock_acquire+0x1298/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 usb_udc_uevent+0x54/0xe0 Evidentemente, esto se debi\u00f3 a que el alcance de udc_mutex era demasiado grande. El mutex solo protege udc-&gt;driver, entre otras cosas. Hasta donde s\u00e9, no hay raz\u00f3n para que el mutex se mantenga mientras el n\u00facleo del gadget llama a la rutina -&gt;bind o -&gt;unbind de un controlador de gadget, ni mientras se inicia o detiene un UDC. (Esto explica el enlace n.\u00ba 1 de la cadena anterior, donde el mutex se mantiene mientras se inicia dwc2_hsotg_udc como parte del sondeo del controlador). Las devoluciones de llamada -&gt;disconnect de los controladores de gadget son problem\u00e1ticas. Aunque usb_gadget_disconnect() ahora adquirir\u00e1 el udc_mutex, existe un margen en usb_gadget_bind_driver() entre el momento en que se libera el mutex y se invoca la devolucion de llamada -&gt;bind. Si se produjera una desconexi\u00f3n durante ese margen, podr\u00edamos llamar a la rutina -&gt;disconnect del controlador antes que a su rutina -&gt;bind. Para evitarlo, ser\u00e1 necesario impedir que un UDC se conecte mientras no tenga un controlador de gadget. Esto ya deber\u00eda estar hecho, pero no parece estarlo; actualmente, usb_gadget_connect() no lo comprueba. Esta comprobaci\u00f3n deber\u00e1 a\u00f1adirse m\u00e1s adelante. Se requiere cierto grado de exclusi\u00f3n mutua en soft_connect_store(), que puede desreferenciar udc-&gt;driver en cualquier momento, ya que es una devoluci\u00f3n de llamada de sysfs. La soluci\u00f3n es adquirir el bloqueo del dispositivo del gadget en lugar del udc_mutex. Dado que el n\u00facleo del controlador garantiza que el bloqueo del dispositivo se mantenga siempre durante la vinculaci\u00f3n y desvinculaci\u00f3n del controlador, esto har\u00e1 que los accesos en soft_connect_store() sean mutuamente excluyentes con cualquier cambio en udc-&gt;driver. Por \u00faltimo, resulta que hay un lugar que deber\u00eda contener el udc_mutex, pero actualmente no lo hace: la rutina function_show() necesita protecci\u00f3n mientras desreferencia udc-&gt;driver. Se a\u00f1aden las llamadas de bloqueo y desbloqueo que faltan."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49944.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"usb: typec: ucsi: add a common function ucsi_unregister_connectors()\"\n\nThe recent commit 87d0e2f41b8c (\"usb: typec: ucsi: add a common\nfunction ucsi_unregister_connectors()\") introduced a regression that\ncaused NULL dereference at reading the power supply sysfs. It's a\nstale sysfs entry that should have been removed but remains with NULL\nops. The commit changed the error handling to skip the entries after\na NULL con->wq, and this leaves the power device unreleased.\n\nFor addressing the regression, the straight revert is applied here.\nFurther code improvements can be done from the scratch again."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir \"usb: typec: ucsi: a\u00f1adir una funci\u00f3n com\u00fan ucsi_unregister_connectors()\". La reciente confirmaci\u00f3n 87d0e2f41b8c (\"usb: typec: ucsi: a\u00f1adir una funci\u00f3n com\u00fan ucsi_unregister_connectors()\") introdujo una regresi\u00f3n que provocaba una desreferencia nula al leer el archivo sysfs de la fuente de alimentaci\u00f3n. Se trata de una entrada obsoleta del archivo sysfs que deber\u00eda haberse eliminado, pero que permanece con operaciones nulas. el commit modific\u00f3 la gesti\u00f3n de errores para omitir las entradas despu\u00e9s de un comando con-&gt;wq nulo, lo que deja el dispositivo de alimentaci\u00f3n sin liberar. Para solucionar la regresi\u00f3n, se aplica la reversi\u00f3n directa. Se pueden realizar mejoras de c\u00f3digo desde cero."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49945.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (gpio-fan) Fix array out of bounds access\n\nThe driver does not check if the cooling state passed to\ngpio_fan_set_cur_state() exceeds the maximum cooling state as\nstored in fan_data->num_speeds. Since the cooling state is later\nused as an array index in set_fan_speed(), an array out of bounds\naccess can occur.\nThis can be exploited by setting the state of the thermal cooling device\nto arbitrary values, causing for example a kernel oops when unavailable\nmemory is accessed this way.\n\nExample kernel oops:\n[ 807.987276] Unable to handle kernel paging request at virtual address ffffff80d0588064\n[ 807.987369] Mem abort info:\n[ 807.987398] ESR = 0x96000005\n[ 807.987428] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 807.987477] SET = 0, FnV = 0\n[ 807.987507] EA = 0, S1PTW = 0\n[ 807.987536] FSC = 0x05: level 1 translation fault\n[ 807.987570] Data abort info:\n[ 807.987763] ISV = 0, ISS = 0x00000005\n[ 807.987801] CM = 0, WnR = 0\n[ 807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000\n[ 807.987872] [ffffff80d0588064] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000\n[ 807.987961] Internal error: Oops: 96000005 [#1] PREEMPT SMP\n[ 807.987992] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec brcmfmac vc4 brcmutil cec drm_kms_helper snd_soc_core cfg80211 snd_compress bcm2835_codec(C) snd_pcm_dmaengine syscopyarea bcm2835_isp(C) bcm2835_v4l2(C) sysfillrect v4l2_mem2mem bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops rfkill videobuf2_v4l2 videobuf2_common i2c_bcm2835 snd_bcm2835(C) videodev snd_pcm snd_timer snd mc vc_sm_cma(C) gpio_fan uio_pdrv_genirq uio drm fuse drm_panel_orientation_quirks backlight ip_tables x_tables ipv6\n[ 807.988508] CPU: 0 PID: 1321 Comm: bash Tainted: G C 5.15.56-v8+ #1575\n[ 807.988548] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)\n[ 807.988574] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 807.988608] pc : set_fan_speed.part.5+0x34/0x80 [gpio_fan]\n[ 807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]\n[ 807.988691] sp : ffffffc008cf3bd0\n[ 807.988710] x29: ffffffc008cf3bd0 x28: ffffff80019edac0 x27: 0000000000000000\n[ 807.988762] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800747c920\n[ 807.988787] x23: 000000000000000a x22: ffffff800369f000 x21: 000000001999997c\n[ 807.988854] x20: ffffff800369f2e8 x19: ffffff8002ae8080 x18: 0000000000000000\n[ 807.988877] x17: 0000000000000000 x16: 0000000000000000 x15: 000000559e271b70\n[ 807.988938] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n[ 807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c\n[ 807.989018] x8 : 000000000000000a x7 : 00000000ffffffc9 x6 : 0000000000000009\n[ 807.989040] x5 : 000000000000002a x4 : 0000000000000000 x3 : ffffff800369f2e8\n[ 807.989062] x2 : 000000000000e780 x1 : 0000000000000001 x0 : ffffff80d0588060\n[ 807.989084] Call trace:\n[ 807.989091] set_fan_speed.part.5+0x34/0x80 [gpio_fan]\n[ 807.989113] gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]\n[ 807.989199] cur_state_store+0x84/0xd0\n[ 807.989221] dev_attr_store+0x20/0x38\n[ 807.989262] sysfs_kf_write+0x4c/0x60\n[ 807.989282] kernfs_fop_write_iter+0x130/0x1c0\n[ 807.989298] new_sync_write+0x10c/0x190\n[ 807.989315] vfs_write+0x254/0x378\n[ 807.989362] ksys_write+0x70/0xf8\n[ 807.989379] __arm64_sys_write+0x24/0x30\n[ 807.989424] invoke_syscall+0x4c/0x110\n[ 807.989442] el0_svc_common.constprop.3+0xfc/0x120\n[ 807.989458] do_el0_svc+0x2c/0x90\n[ 807.989473] el0_svc+0x24/0x60\n[ 807.989544] el0t_64_sync_handler+0x90/0xb8\n[ 807.989558] el0t_64_sync+0x1a0/0x1a4\n[ 807.989579] Code: b9403801 f9402800 7100003f 8b35cc00 (b9400416)\n[ 807.989627] ---[ end t\n---truncated---"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (gpio-fan) Correcci\u00f3n de acceso fuera de los l\u00edmites a una matriz. El controlador no comprueba si el estado de refrigeraci\u00f3n transferido a gpio_fan_set_cur_state() supera el estado de refrigeraci\u00f3n m\u00e1ximo almacenado en fan_data-&gt;num_speeds. Dado que el estado de refrigeraci\u00f3n se utiliza posteriormente como \u00edndice de matriz en set_fan_speed(), puede producirse un acceso fuera de los l\u00edmites a una matriz. Esto se puede explotar configurando el estado del dispositivo de refrigeraci\u00f3n t\u00e9rmica con valores arbitrarios, lo que provoca, por ejemplo, un error en el kernel al acceder a memoria no disponible de esta forma. Ejemplo de error de kernel: [807.987276] No se puede manejar la solicitud de paginaci\u00f3n del kernel en la direcci\u00f3n virtual ffffff80d0588064 [807.987369] Informaci\u00f3n de aborto de memoria: [807.987398] ESR = 0x96000005 [807.987428] EC = 0x25: DABT (EL actual), IL = 32 bits [807.987477] SET = 0, FnV = 0 [807.987507] EA = 0, S1PTW = 0 [807.987536] FSC = 0x05: error de traducci\u00f3n de nivel 1 [807.987570] Informaci\u00f3n de aborto de datos: [ 807.987398] ESR = 0x96000005 [ 807.987428] EC = 0x25: DABT (current EL), IL = 32 bits [ 807.987477] SET = 0, FnV = 0 [ 807.987507] EA = 0, S1PTW = 0 [ 807.987536] FSC = 0x05: level 1 translation fault [ 807.987570] Data abort info: [ 807.987763] ISV = 0, ISS = 0x00000005 [ 807.987801] CM = 0, WnR = 0 [ 807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000 [ 807.987872] [ffffff80d0588064] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 807.987961] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 807.987992] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec brcmfmac vc4 brcmutil cec drm_kms_helper snd_soc_core cfg80211 snd_compress bcm2835_codec(C) snd_pcm_dmaengine syscopyarea bcm2835_isp(C) bcm2835_v4l2(C) sysfillrect v4l2_mem2mem bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops rfkill videobuf2_v4l2 videobuf2_common i2c_bcm2835 snd_bcm2835(C) videodev snd_pcm snd_timer snd mc vc_sm_cma(C) gpio_fan uio_pdrv_genirq uio drm fuse drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 807.988508] CPU: 0 PID: 1321 Comm: bash Tainted: G C 5.15.56-v8+ #1575 [ 807.988548] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 807.988574] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 807.988608] pc : set_fan_speed.part.5+0x34/0x80 [gpio_fan] [ 807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan] [ 807.988691] sp : ffffffc008cf3bd0 [ 807.988710] x29: ffffffc008cf3bd0 x28: ffffff80019edac0 x27: 0000000000000000 [ 807.988762] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800747c920 [ 807.988787] x23: 000000000000000a x22: ffffff800369f000 x21: 000000001999997c [ 807.988854] x20: ffffff800369f2e8 x19: ffffff8002ae8080 x18: 0000000000000000 [ 807.988877] x17: 0000000000000000 x16: 0000000000000000 x15: 000000559e271b70 [ 807.988938] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c [ 807.989018] x8 : 000000000000000a x7 : 00000000ffffffc9 x6 : 0000000000000009 [ 807.989040] x5 : 000000000000002a x4 : 0000000000000000 x3 : ffffff800369f2e8 [ 807.989062] x2 : 000000000000e780 x1 : 0000000000000001 x0 : ffffff80d0588060 [ 807.989084] Call trace: [ 807.989091] set_fan_speed.part.5+0x34/0x80 [gpio_fan] [ 807.989113] gpio_fan_set_cur_state+0x34/0x50 [gpio_fan] [ 807.989199] cur_state_store+0x84/0xd0 [ 807.989221] dev_attr_store+0x20/0x38 [ 807.989262] sysfs_kf_write+0x4c/0x60 [ 807.989282] kernfs_fop_write_iter+0x130/0x1c0 [ 807.989298] new_sync_write+0x10c/0x190 [ 807.989315] vfs_write+0x254/0x378 [ 807.989362] ksys_write+0x70/0xf8 [ 807.989379] __arm64_sys_write+0x24/0x30 [ 807.989424] invoke_syscall+0x4c/0x110 [ 807.989442] ---truncado---"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49946.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: bcm: rpi: Prevent out-of-bounds access\n\nThe while loop in raspberrypi_discover_clocks() relies on the assumption\nthat the id of the last clock element is zero. Because this data comes\nfrom the Videocore firmware and it doesn't guarantuee such a behavior\nthis could lead to out-of-bounds access. So fix this by providing\na sentinel element."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: bcm: rpi: Impedir acceso fuera de los l\u00edmites. El bucle while en raspberrypi_discover_clocks() asume que el ID del \u00faltimo elemento de reloj es cero. Dado que estos datos provienen del firmware de Videocore y no garantizan dicho comportamiento, esto podr\u00eda provocar un acceso fuera de los l\u00edmites. Para solucionarlo, se debe proporcionar un elemento centinela."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49947.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix alloc->vma_vm_mm null-ptr dereference\n\nSyzbot reported a couple issues introduced by commit 44e602b4e52f\n(\"binder_alloc: add missing mmap_lock calls when using the VMA\"), in\nwhich we attempt to acquire the mmap_lock when alloc->vma_vm_mm has not\nbeen initialized yet.\n\nThis can happen if a binder_proc receives a transaction without having\npreviously called mmap() to setup the binder_proc->alloc space in [1].\nAlso, a similar issue occurs via binder_alloc_print_pages() when we try\nto dump the debugfs binder stats file in [2].\n\nSample of syzbot's crash report:\n ==================================================================\n KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]\n CPU: 0 PID: 3755 Comm: syz-executor229 Not tainted 6.0.0-rc1-next-20220819-syzkaller #0\n syz-executor229[3755] cmdline: ./syz-executor2294415195\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022\n RIP: 0010:__lock_acquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923\n [...]\n Call Trace:\n <TASK>\n lock_acquire kernel/locking/lockdep.c:5666 [inline]\n lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631\n down_read+0x98/0x450 kernel/locking/rwsem.c:1499\n mmap_read_lock include/linux/mmap_lock.h:117 [inline]\n binder_alloc_new_buf_locked drivers/android/binder_alloc.c:405 [inline]\n binder_alloc_new_buf+0xa5/0x19e0 drivers/android/binder_alloc.c:593\n binder_transaction+0x242e/0x9a80 drivers/android/binder.c:3199\n binder_thread_write+0x664/0x3220 drivers/android/binder.c:3986\n binder_ioctl_write_read drivers/android/binder.c:5036 [inline]\n binder_ioctl+0x3470/0x6d00 drivers/android/binder.c:5323\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:870 [inline]\n __se_sys_ioctl fs/ioctl.c:856 [inline]\n __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n [...]\n ==================================================================\n\nFix these issues by setting up alloc->vma_vm_mm pointer during open()\nand caching directly from current->mm. This guarantees we have a valid\nreference to take the mmap_lock during scenarios described above.\n\n[1] https://syzkaller.appspot.com/bug?extid=f7dc54e5be28950ac459\n[2] https://syzkaller.appspot.com/bug?extid=a75ebe0452711c9e56d9"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: correcci\u00f3n de la desreferencia alloc-&gt;vma_vm_mm null-ptr. Syzbot inform\u00f3 de un par de problemas introducidos por el commit 44e602b4e52f (\"binder_alloc: a\u00f1adir llamadas mmap_lock faltantes al usar la VMA\"), en el que se intenta adquirir mmap_lock cuando alloc-&gt;vma_vm_mm a\u00fan no se ha inicializado. Esto puede ocurrir si un binder_proc recibe una transacci\u00f3n sin haber llamado previamente a mmap() para configurar el espacio binder_proc-&gt;alloc en [1]. Adem\u00e1s, se produce un problema similar mediante binder_alloc_print_pages() al intentar volcar el archivo de estad\u00edsticas de binder debugfs en [2]. Ejemplo de informe de fallos de syzbot: ======================================================================= KASAN: null-ptr-deref en el rango [0x0000000000000128-0x000000000000012f] CPU: 0 PID: 3755 Comm: syz-executor229 No contaminado 6.0.0-rc1-next-20220819-syzkaller #0 syz-executor229[3755] cmdline: ./syz-executor2294415195 Nombre del hardware: Google Google Compute Engine/Google Compute Motor, BIOS Google 22/07/2022 RIP: 0010:__lock_acquire+0xd83/0x56d0 kernel/locking/lockdep.c:4923 [...] Rastreo de llamadas: lock_acquire kernel/locking/lockdep.c:5666 [inline] lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631 down_read+0x98/0x450 kernel/locking/rwsem.c:1499 mmap_read_lock include/linux/mmap_lock.h:117 [inline] binder_alloc_new_buf_locked drivers/android/binder_alloc.c:405 [inline] binder_alloc_new_buf+0xa5/0x19e0 drivers/android/binder_alloc.c:593 binder_transaction+0x242e/0x9a80 drivers/android/binder.c:3199 binder_thread_write+0x664/0x3220 drivers/android/binder.c:3986 binder_ioctl_write_read drivers/android/binder.c:5036 [inline] binder_ioctl+0x3470/0x6d00 drivers/android/binder.c:5323 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] ================================================================== Solucione estos problemas configurando el puntero alloc-&gt;vma_vm_mm durante la operaci\u00f3n open() y almacenando en cach\u00e9 directamente desde current-&gt;mm. Esto garantiza una referencia v\u00e1lida para tomar mmap_lock en los escenarios descritos anteriormente.. [1] https://syzkaller.appspot.com/bug?extid=f7dc54e5be28950ac459 [2] https://syzkaller.appspot.com/bug?extid=a75ebe0452711c9e56d9 "
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49948.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvt: Clear selection before changing the font\n\nWhen changing the console font with ioctl(KDFONTOP) the new font size\ncan be bigger than the previous font. A previous selection may thus now\nbe outside of the new screen size and thus trigger out-of-bounds\naccesses to graphics memory if the selection is removed in\nvc_do_resize().\n\nPrevent such out-of-memory accesses by dropping the selection before the\nvarious con_font_set() console handlers are called."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vt: Borrar la selecci\u00f3n antes de cambiar la fuente. Al cambiar la fuente de la consola con ioctl(KDFONTOP), el nuevo tama\u00f1o de fuente puede ser mayor que el anterior. Por lo tanto, una selecci\u00f3n anterior podr\u00eda quedar fuera del nuevo tama\u00f1o de pantalla y, por lo tanto, provocar accesos fuera de los l\u00edmites a la memoria gr\u00e1fica si se elimina la selecci\u00f3n en vc_do_resize(). Para evitar estos accesos fuera de memoria, elimine la selecci\u00f3n antes de llamar a los controladores de consola con_font_set()."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49949.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware_loader: Fix memory leak in firmware upload\n\nIn the case of firmware-upload, an instance of struct fw_upload is\nallocated in firmware_upload_register(). This data needs to be freed\nin fw_dev_release(). Create a new fw_upload_free() function in\nsysfs_upload.c to handle the firmware-upload specific memory frees\nand incorporate the missing kfree call for the fw_upload structure."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware_loader: Se corrige una fuga de memoria durante la carga de firmware. En la carga de firmware, se asigna una instancia de la estructura fw_upload en firmware_upload_register(). Estos datos deben liberarse en fw_dev_release(). Cree una nueva funci\u00f3n fw_upload_free() en sysfs_upload.c para gestionar las liberaciones de memoria espec\u00edficas de la carga de firmware e incorpore la llamada kfree que falta para la estructura fw_upload."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49950.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: fastrpc: fix memory corruption on open\n\nThe probe session-duplication overflow check incremented the session\ncount also when there were no more available sessions so that memory\nbeyond the fixed-size slab-allocated session array could be corrupted in\nfastrpc_session_alloc() on open()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: corrige corrupci\u00f3n de memoria al abrir La comprobaci\u00f3n de desbordamiento de duplicaci\u00f3n de sesi\u00f3n de la sonda increment\u00f3 el recuento de sesiones tambi\u00e9n cuando no hab\u00eda m\u00e1s sesiones disponibles, de modo que la memoria m\u00e1s all\u00e1 de la matriz de sesiones asignadas en bloques de tama\u00f1o fijo pod\u00eda corromperse en fastrpc_session_alloc() al abrir()."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49951.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware_loader: Fix use-after-free during unregister\n\nIn the following code within firmware_upload_unregister(), the call to\ndevice_unregister() could result in the dev_release function freeing the\nfw_upload_priv structure before it is dereferenced for the call to\nmodule_put(). This bug was found by the kernel test robot using\nCONFIG_KASAN while running the firmware selftests.\n\n device_unregister(&fw_sysfs->dev);\n module_put(fw_upload_priv->module);\n\nThe problem is fixed by copying fw_upload_priv->module to a local variable\nfor use when calling device_unregister()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware_loader: Se corrige el error \"use-after-free\" durante la anulaci\u00f3n del registro. En el siguiente c\u00f3digo, dentro de firmware_upload_unregister(), la llamada a device_unregister() podr\u00eda provocar que la funci\u00f3n dev_release libere la estructura fw_upload_priv antes de que se desreferenciara para la llamada a module_put(). Este error fue detectado por el robot de pruebas del kernel mediante CONFIG_KASAN al ejecutar las autopruebas del firmware. device_unregister(&amp;fw_sysfs-&gt;dev); module_put(fw_upload_priv-&gt;module); El problema se corrige copiando fw_upload_priv-&gt;module a una variable local para su uso al llamar a device_unregister()."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49952.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: fastrpc: fix memory corruption on probe\n\nAdd the missing sanity check on the probed-session count to avoid\ncorrupting memory beyond the fixed-size slab-allocated session array\nwhen there are more than FASTRPC_MAX_SESSIONS sessions defined in the\ndevicetree."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: corregir corrupci\u00f3n de memoria en la sonda Agregue la verificaci\u00f3n de cordura faltante en el recuento de sesiones sondeadas para evitar corromper la memoria m\u00e1s all\u00e1 de la matriz de sesiones asignadas por bloques de tama\u00f1o fijo cuando hay m\u00e1s de FASTRPC_MAX_SESSIONS sesiones definidas en el \u00e1rbol de dispositivos."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49953.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: light: cm3605: Fix an error handling path in cm3605_probe()\n\nThe commit in Fixes also introduced a new error handling path which should\ngoto the existing error handling path.\nOtherwise some resources leak."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: light: cm3605: Se corrige una ruta de gesti\u00f3n de errores en cm3605_probe(). El commit en Fixes (correcciones) tambi\u00e9n introdujo una nueva ruta de gesti\u00f3n de errores que deber\u00eda enlazar con la ruta de gesti\u00f3n de errores existente. De lo contrario, se producir\u00edan fugas de recursos.\n"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49954.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nInput: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag\n\nsyzbot is reporting hung task at __input_unregister_device() [1], for\niforce_close() waiting at wait_event_interruptible() with dev->mutex held\nis blocking input_disconnect_device() from __input_unregister_device().\n\nIt seems that the cause is simply that commit c2b27ef672992a20 (\"Input:\niforce - wait for command completion when closing the device\") forgot to\ncall wake_up() after clear_bit().\n\nFix this problem by introducing a helper that calls clear_bit() followed\nby wake_up_all()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: iforce - reactivar tras borrar el indicador IFORCE_XMIT_RUNNING. syzbot informa que la tarea est\u00e1 bloqueada en __input_unregister_device() [1], ya que iforce_close() espera en wait_event_interruptible() con dev-&gt;mutex retenido, lo que bloquea input_disconnect_device() desde __input_unregister_device(). Parece que la causa es simplemente que el commit c2b27ef672992a20 (\"Entrada: iforce - esperar a que se complete el comando al cerrar el dispositivo\") olvid\u00f3 llamar a wake_up() despu\u00e9s de clear_bit(). Se soluciona este problema mediante un asistente que llame a clear_bit() seguido de wake_up_all()."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49955.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/rtas: Fix RTAS MSR[HV] handling for Cell\n\nThe semi-recent changes to MSR handling when entering RTAS (firmware)\ncause crashes on IBM Cell machines. An example trace:\n\n kernel tried to execute user page (2fff01a8) - exploit attempt? (uid: 0)\n BUG: Unable to handle kernel instruction fetch\n Faulting instruction address: 0x2fff01a8\n Oops: Kernel access of bad area, sig: 11 [#1]\n BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 NUMA Cell\n Modules linked in:\n CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.0.0-rc2-00433-gede0a8d3307a #207\n NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 0000000000000000\n REGS: c0000000015236b0 TRAP: 0400 Tainted: G W (6.0.0-rc2-00433-gede0a8d3307a)\n MSR: 0000000008001002 <ME,RI> CR: 00000000 XER: 20000000\n ...\n NIP 0x2fff01a8\n LR 0x32608\n Call Trace:\n 0xc00000000143c5f8 (unreliable)\n .rtas_call+0x224/0x320\n .rtas_get_boot_time+0x70/0x150\n .read_persistent_clock64+0x114/0x140\n .read_persistent_wall_and_boot_offset+0x24/0x80\n .timekeeping_init+0x40/0x29c\n .start_kernel+0x674/0x8f0\n start_here_common+0x1c/0x50\n\nUnlike PAPR platforms where RTAS is only used in guests, on the IBM Cell\nmachines Linux runs with MSR[HV] set but also uses RTAS, provided by\nSLOF.\n\nFix it by copying the MSR[HV] bit from the MSR value we've just read\nusing mfmsr into the value used for RTAS.\n\nIt seems like we could also fix it using an #ifdef CELL to set MSR[HV],\nbut that doesn't work because it's possible to build a single kernel\nimage that runs on both Cell native and pseries."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/rtas: Correcci\u00f3n del manejo de MSR[HV] de RTAS para Cell. Los cambios recientes en el manejo de MSR al ingresar RTAS (firmware) provocan bloqueos en las m\u00e1quinas IBM Cell. Ejemplo de rastreo: el kernel intent\u00f3 ejecutar la p\u00e1gina de usuario (2fff01a8): \u00bfintento de explotaci\u00f3n? (uid: 0) ERROR: No se puede controlar la obtenci\u00f3n de instrucciones del n\u00facleo Direcci\u00f3n de instrucci\u00f3n err\u00f3nea: 0x2fff01a8 Oops: Acceso del n\u00facleo al \u00e1rea defectuosa, firma: 11 [#1] BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 M\u00f3dulos de celda NUMA vinculados: CPU: 0 PID: 0 Comm: swapper/0 Contaminado: GW 6.0.0-rc2-00433-gede0a8d3307a #207 NIP: 000000002fff01a8 LR: 0000000000032608 CTR: 000000000000000 REGS: c0000000015236b0 TRAP: 0400 Contaminado: GW (6.0.0-rc2-00433-gede0a8d3307a) MSR: 0000000008001002 CR: 00000000 XER: 20000000 ... NIP 0x2fff01a8 LR 0x32608 Rastreo de llamadas: 0xc00000000143c5f8 (no confiable) .rtas_call+0x224/0x320 .rtas_get_boot_time+0x70/0x150 .read_persistent_clock64+0x114/0x140 .read_persistent_wall_and_boot_offset+0x24/0x80 .timekeeping_init+0x40/0x29c A diferencia de las plataformas PAPR, donde RTAS solo se usa en hu\u00e9spedes, en las m\u00e1quinas IBM Cell, Linux se ejecuta con MSR[HV] activado, pero tambi\u00e9n usa RTAS, proporcionado por SLOF. Para solucionarlo, copie el bit MSR[HV] del valor MSR que acabamos de leer con mfmsr al valor usado para RTAS. Parece que tambi\u00e9n podr\u00edamos solucionarlo usando un #ifdef CELL para activar MSR[HV], pero esto no funciona, ya que es posible crear una \u00fanica imagen de kernel que funcione tanto en Cell nativo como en pseries."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49956.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: rtl8712: fix use after free bugs\n\n_Read/Write_MACREG callbacks are NULL so the read/write_macreg_hdl()\nfunctions don't do anything except free the \"pcmd\" pointer. It\nresults in a use after free. Delete them."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: rtl8712: se corrige el error \"use after free\". Las devoluciones de llamada _Read/Write_MACREG son nulas, por lo que las funciones read/write_macreg_hdl() solo liberan el puntero \"pcmd\". Esto genera un error \"use after free\". Elim\u00ednelas."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49957.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nkcm: fix strp_init() order and cleanup\n\nstrp_init() is called just a few lines above this csk->sk_user_data\ncheck, it also initializes strp->work etc., therefore, it is\nunnecessary to call strp_done() to cancel the freshly initialized\nwork.\n\nAnd if sk_user_data is already used by KCM, psock->strp should not be\ntouched, particularly strp->work state, so we need to move strp_init()\nafter the csk->sk_user_data check.\n\nThis also makes a lockdep warning reported by syzbot go away."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kcm: correcci\u00f3n del orden y la limpieza de strp_init(). strp_init() se llama solo unas l\u00edneas por encima de la comprobaci\u00f3n csk-&gt;sk_user_data; tambi\u00e9n inicializa strp-&gt;work, etc., por lo que no es necesario llamar a strp_done() para cancelar el trabajo reci\u00e9n inicializado. Si KCM ya utiliza sk_user_data, no se debe modificar psock-&gt;strp, en particular el estado strp-&gt;work, por lo que es necesario mover strp_init() despu\u00e9s de la comprobaci\u00f3n csk-&gt;sk_user_data. Esto tambi\u00e9n elimina la advertencia de lockdep reportada por syzbot."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49958.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix netdevice reference leaks in attach_default_qdiscs()\n\nIn attach_default_qdiscs(), if a dev has multiple queues and queue 0 fails\nto attach qdisc because there is no memory in attach_one_default_qdisc().\nThen dev->qdisc will be noop_qdisc by default. But the other queues may be\nable to successfully attach to default qdisc.\n\nIn this case, the fallback to noqueue process will be triggered. If the\noriginal attached qdisc is not released and a new one is directly\nattached, this will cause netdevice reference leaks.\n\nThe following is the bug log:\n\nveth0: default qdisc (fq_codel) fail, fallback to noqueue\nunregister_netdevice: waiting for veth0 to become free. Usage count = 32\nleaked reference.\n qdisc_alloc+0x12e/0x210\n qdisc_create_dflt+0x62/0x140\n attach_one_default_qdisc.constprop.41+0x44/0x70\n dev_activate+0x128/0x290\n __dev_open+0x12a/0x190\n __dev_change_flags+0x1a2/0x1f0\n dev_change_flags+0x23/0x60\n do_setlink+0x332/0x1150\n __rtnl_newlink+0x52f/0x8e0\n rtnl_newlink+0x43/0x70\n rtnetlink_rcv_msg+0x140/0x3b0\n netlink_rcv_skb+0x50/0x100\n netlink_unicast+0x1bb/0x290\n netlink_sendmsg+0x37c/0x4e0\n sock_sendmsg+0x5f/0x70\n ____sys_sendmsg+0x208/0x280\n\nFix this bug by clearing any non-noop qdiscs that may have been assigned\nbefore trying to re-attach."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: corrige fugas de referencia de netdevice en attached_default_qdiscs() En attached_default_qdiscs(), si un dev tiene varias colas y la cola 0 no puede adjuntar qdisc porque no hay memoria en attached_one_default_qdisc(). Entonces dev-&gt;qdisc ser\u00e1 noop_qdisc por defecto. Pero las otras colas pueden ser capaces de adjuntar con \u00e9xito a la qdisc predeterminada. En este caso, se activar\u00e1 el proceso de retorno a noqueue. Si la qdisc adjunta original no se libera y se adjunta una nueva directamente, esto causar\u00e1 fugas de referencia de netdevice. El siguiente es el registro de errores: veth0: falla de qdisc predeterminada (fq_codel), retorno a noqueue unregister_netdevice: esperando a que veth0 se libere. Recuento de uso = 32 referencias filtradas. qdisc_alloc+0x12e/0x210 qdisc_create_dflt+0x62/0x140 attach_one_default_qdisc.constprop.41+0x44/0x70 dev_activate+0x128/0x290 __dev_open+0x12a/0x190 __dev_change_flags+0x1a2/0x1f0 dev_change_flags+0x23/0x60 do_setlink+0x332/0x1150 __rtnl_newlink+0x52f/0x8e0 rtnl_newlink+0x43/0x70 rtnetlink_rcv_msg+0x140/0x3b0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1bb/0x290 netlink_sendmsg+0x37c/0x4e0 sock_sendmsg+0x5f/0x70 ____sys_sendmsg+0x208/0x280 Corrija este error borrando cualquier qdisc que no sea noop que pueda haberse asignado antes de intentar volver a conectar."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49959.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: fix memory leak at failed datapath creation\n\novs_dp_cmd_new()->ovs_dp_change()->ovs_dp_set_upcall_portids()\nallocates array via kmalloc.\nIf for some reason new_vport() fails during ovs_dp_cmd_new()\ndp->upcall_portids must be freed.\nAdd missing kfree.\n\nKmemleak example:\nunreferenced object 0xffff88800c382500 (size 64):\n comm \"dump_state\", pid 323, jiffies 4294955418 (age 104.347s)\n hex dump (first 32 bytes):\n 5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff ^.y..z8..!8.....\n 03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00 ............(...\n backtrace:\n [<0000000071bebc9f>] ovs_dp_set_upcall_portids+0x38/0xa0\n [<000000000187d8bd>] ovs_dp_change+0x63/0xe0\n [<000000002397e446>] ovs_dp_cmd_new+0x1f0/0x380\n [<00000000aa06f36e>] genl_family_rcv_msg_doit+0xea/0x150\n [<000000008f583bc4>] genl_rcv_msg+0xdc/0x1e0\n [<00000000fa10e377>] netlink_rcv_skb+0x50/0x100\n [<000000004959cece>] genl_rcv+0x24/0x40\n [<000000004699ac7f>] netlink_unicast+0x23e/0x360\n [<00000000c153573e>] netlink_sendmsg+0x24e/0x4b0\n [<000000006f4aa380>] sock_sendmsg+0x62/0x70\n [<00000000d0068654>] ____sys_sendmsg+0x230/0x270\n [<0000000012dacf7d>] ___sys_sendmsg+0x88/0xd0\n [<0000000011776020>] __sys_sendmsg+0x59/0xa0\n [<000000002e8f2dc1>] do_syscall_64+0x3b/0x90\n [<000000003243e7cb>] entry_SYSCALL_64_after_hwframe+0x63/0xcd"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: openvswitch: se corrige una fuga de memoria al crear una ruta de datos fallida. ovs_dp_cmd_new()-&gt;ovs_dp_change()-&gt;ovs_dp_set_upcall_portids() asigna una matriz mediante kmalloc. Si por alguna raz\u00f3n new_vport() falla durante ovs_dp_cmd_new(), se debe liberar dp-&gt;upcall_portids. Se a\u00f1ade la falta de kfree. Ejemplo de Kmemleak: objeto sin referencia 0xffff88800c382500 (tama\u00f1o 64): comm \"dump_state\", pid 323, jiffies 4294955418 (edad 104.347s) volcado hexadecimal (primeros 32 bytes): 5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff ^.y..z8..!8..... 03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00 ............(... backtrace: [&lt;0000000071bebc9f&gt;] ovs_dp_set_upcall_portids+0x38/0xa0 [&lt;000000000187d8bd&gt;] ovs_dp_change+0x63/0xe0 [&lt;000000002397e446&gt;] ovs_dp_cmd_new+0x1f0/0x380 [&lt;00000000aa06f36e&gt;] genl_family_rcv_msg_doit+0xea/0x150 [&lt;000000008f583bc4&gt;] genl_rcv_msg+0xdc/0x1e0 [&lt;00000000fa10e377&gt;] netlink_rcv_skb+0x50/0x100 [&lt;000000004959cece&gt;] genl_rcv+0x24/0x40 [&lt;000000004699ac7f&gt;] netlink_unicast+0x23e/0x360 [&lt;00000000c153573e&gt;] netlink_sendmsg+0x24e/0x4b0 [&lt;000000006f4aa380&gt;] sock_sendmsg+0x62/0x70 [&lt;00000000d0068654&gt;] ____sys_sendmsg+0x230/0x270 [&lt;0000000012dacf7d&gt;] ___sys_sendmsg+0x88/0xd0 [&lt;0000000011776020&gt;] __sys_sendmsg+0x59/0xa0 [&lt;000000002e8f2dc1&gt;] do_syscall_64+0x3b/0x90 [&lt;000000003243e7cb&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd "
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49960.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: fix null pointer dereference\n\nAsus chromebook CX550 crashes during boot on v5.17-rc1 kernel.\nThe root cause is null pointer defeference of bi_next\nin tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c.\n\nBUG: kernel NULL pointer dereference, address: 000000000000002e\nPGD 0 P4D 0\nOops: 0002 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 1 Comm: swapper/0 Tainted: G U 5.17.0-rc1\nHardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 05/14/2021\nRIP: 0010:tgl_get_bw_info+0x2de/0x510\n...\n[ 2.554467] Call Trace:\n[ 2.554467] <TASK>\n[ 2.554467] intel_bw_init_hw+0x14a/0x434\n[ 2.554467] ? _printk+0x59/0x73\n[ 2.554467] ? _dev_err+0x77/0x91\n[ 2.554467] i915_driver_hw_probe+0x329/0x33e\n[ 2.554467] i915_driver_probe+0x4c8/0x638\n[ 2.554467] i915_pci_probe+0xf8/0x14e\n[ 2.554467] ? _raw_spin_unlock_irqrestore+0x12/0x2c\n[ 2.554467] pci_device_probe+0xaa/0x142\n[ 2.554467] really_probe+0x13f/0x2f4\n[ 2.554467] __driver_probe_device+0x9e/0xd3\n[ 2.554467] driver_probe_device+0x24/0x7c\n[ 2.554467] __driver_attach+0xba/0xcf\n[ 2.554467] ? driver_attach+0x1f/0x1f\n[ 2.554467] bus_for_each_dev+0x8c/0xc0\n[ 2.554467] bus_add_driver+0x11b/0x1f7\n[ 2.554467] driver_register+0x60/0xea\n[ 2.554467] ? mipi_dsi_bus_init+0x16/0x16\n[ 2.554467] i915_init+0x2c/0xb9\n[ 2.554467] ? mipi_dsi_bus_init+0x16/0x16\n[ 2.554467] do_one_initcall+0x12e/0x2b3\n[ 2.554467] do_initcall_level+0xd6/0xf3\n[ 2.554467] do_initcalls+0x4e/0x79\n[ 2.554467] kernel_init_freeable+0xed/0x14d\n[ 2.554467] ? rest_init+0xc1/0xc1\n[ 2.554467] kernel_init+0x1a/0x120\n[ 2.554467] ret_from_fork+0x1f/0x30\n[ 2.554467] </TASK>\n...\nKernel panic - not syncing: Fatal exception\n\n(cherry picked from commit c247cd03898c4c43c3bce6d4014730403bc13032)"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915: se corrige la desreferencia de puntero nulo. La Chromebook Asus CX550 se bloquea durante el arranque en el kernel v5.17-rc1. La causa principal es la desreferencia de puntero nulo de bi_next en tgl_get_bw_info() en drivers/gpu/drm/i915/display/intel_bw.c. ERROR: desreferencia de puntero NULL del kernel, direcci\u00f3n: 000000000000002e PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 1 Comm: swapper/0 Contaminado: GU 5.17.0-rc1 Nombre del hardware: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 14/05/2021 RIP: 0010:tgl_get_bw_info+0x2de/0x510 ... [ 2.554467] Seguimiento de llamadas: [ 2.554467] [ 2.554467] intel_bw_init_hw+0x14a/0x434 [ 2.554467] ? _printk+0x59/0x73 [ 2.554467] ? _dev_err+0x77/0x91 [ 2.554467] i915_driver_hw_probe+0x329/0x33e [ 2.554467] i915_driver_probe+0x4c8/0x638 [ 2.554467] i915_pci_probe+0xf8/0x14e [ 2.554467] ? _raw_spin_unlock_irqrestore+0x12/0x2c [ 2.554467] pci_device_probe+0xaa/0x142 [ 2.554467] really_probe+0x13f/0x2f4 [ 2.554467] __driver_probe_device+0x9e/0xd3 [ 2.554467] driver_probe_device+0x24/0x7c [ 2.554467] __driver_attach+0xba/0xcf [ 2.554467] ? driver_attach+0x1f/0x1f [ 2.554467] bus_for_each_dev+0x8c/0xc0 [ 2.554467] bus_add_driver+0x11b/0x1f7 [ 2.554467] driver_register+0x60/0xea [ 2.554467] ? mipi_dsi_bus_init+0x16/0x16 [ 2.554467] i915_init+0x2c/0xb9 [ 2.554467] ? mipi_dsi_bus_init+0x16/0x16 [ 2.554467] do_one_initcall+0x12e/0x2b3 [ 2.554467] do_initcall_level+0xd6/0xf3 [ 2.554467] do_initcalls+0x4e/0x79 [ 2.554467] kernel_init_freeable+0xed/0x14d [ 2.554467] ? rest_init+0xc1/0xc1 [ 2.554467] kernel_init+0x1a/0x120 [ 2.554467] ret_from_fork+0x1f/0x30 [ 2.554467] ... P\u00e1nico del kernel - no sincroniza: Excepci\u00f3n fatal (seleccionada de el commit c247cd03898c4c43c3bce6d4014730403bc13032)"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49961.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO\n\nPrecision markers need to be propagated whenever we have an ARG_CONST_*\nstyle argument, as the verifier cannot consider imprecise scalars to be\nequivalent for the purposes of states_equal check when such arguments\nrefine the return value (in this case, set mem_size for PTR_TO_MEM). The\nresultant mem_size for the R0 is derived from the constant value, and if\nthe verifier incorrectly prunes states considering them equivalent where\nsuch arguments exist (by seeing that both registers have reg->precise as\nfalse in regsafe), we can end up with invalid programs passing the\nverifier which can do access beyond what should have been the correct\nmem_size in that explored state.\n\nTo show a concrete example of the problem:\n\n0000000000000000 <prog>:\n 0: r2 = *(u32 *)(r1 + 80)\n 1: r1 = *(u32 *)(r1 + 76)\n 2: r3 = r1\n 3: r3 += 4\n 4: if r3 > r2 goto +18 <LBB5_5>\n 5: w2 = 0\n 6: *(u32 *)(r1 + 0) = r2\n 7: r1 = *(u32 *)(r1 + 0)\n 8: r2 = 1\n 9: if w1 == 0 goto +1 <LBB5_3>\n 10: r2 = -1\n\n0000000000000058 <LBB5_3>:\n 11: r1 = 0 ll\n 13: r3 = 0\n 14: call bpf_ringbuf_reserve\n 15: if r0 == 0 goto +7 <LBB5_5>\n 16: r1 = r0\n 17: r1 += 16777215\n 18: w2 = 0\n 19: *(u8 *)(r1 + 0) = r2\n 20: r1 = r0\n 21: r2 = 0\n 22: call bpf_ringbuf_submit\n\n00000000000000b8 <LBB5_5>:\n 23: w0 = 0\n 24: exit\n\nFor the first case, the single line execution's exploration will prune\nthe search at insn 14 for the branch insn 9's second leg as it will be\nverified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will\nalways be 0 so at runtime we don't get error for being greater than\nUINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just\nsees reg->precise as false for both r2 registers in both states, hence\nconsiders them equal for purposes of states_equal.\n\nIf we propagated precise markers using the backtracking support, we\nwould use the precise marking to then ensure that old r2 (UINT_MAX) was\nwithin the new r2 (1) and this would never be true, so the verification\nwould rightfully fail.\n\nThe end result is that the out of bounds access at instruction 19 would\nbe permitted without this fix.\n\nNote that reg->precise is always set to true when user does not have\nCAP_BPF (or when subprog count is greater than 1 (i.e. use of any static\nor global functions)), hence this is only a problem when precision marks\nneed to be explicitly propagated (i.e. privileged users with CAP_BPF).\n\nA simplified test case has been included in the next patch to prevent\nfuture regressions."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Hacer mark_chain_precision para ARG_CONST_ALLOC_SIZE_OR_ZERO Los marcadores de precisi\u00f3n deben propagarse siempre que tengamos un argumento de estilo ARG_CONST_*, ya que el verificador no puede considerar que los escalares imprecisos sean equivalentes para los fines de la comprobaci\u00f3n states_equal cuando dichos argumentos refinan el valor de retorno (en este caso, establecer mem_size para PTR_TO_MEM). El mem_size resultante para el R0 se deriva del valor constante, y si el verificador poda incorrectamente los estados consider\u00e1ndolos equivalentes donde existen dichos argumentos (al ver que ambos registros tienen reg-&gt;precise como falso en regsafe), podemos terminar con programas no v\u00e1lidos que pasan el verificador que pueden hacer acceso m\u00e1s all\u00e1 de lo que deber\u00eda haber sido el mem_size correcto en ese estado explorado. Para mostrar un ejemplo concreto del problema: 0000000000000000 : 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: si r3 &gt; r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: si w1 == 0 goto +1 10: r2 = -1 0000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: llamar a bpf_ringbuf_reserve 15: si r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: llamar a bpf_ringbuf_submit 00000000000000b8 : 23: w0 = 0 24: salir Para el primer caso, la exploraci\u00f3n de la ejecuci\u00f3n de una sola l\u00ednea podar\u00e1 la b\u00fasqueda en insn 14 para la segunda rama de la rama insn 9, ya que se verificar\u00e1 primero utilizando r2 = -1 (UINT_MAX), mientras que como w1 en insn 9 siempre ser\u00e1 0, por lo que en tiempo de ejecuci\u00f3n no obtenemos un error por ser mayor que UINT_MAX/4 de bpf_ringbuf_reserve. El verificador durante regsafe solo ve reg-&gt;precise como falso para ambos registros r2 en ambos estados, por lo tanto, los considera iguales para fines de states_equal. Si propag\u00e1ramos marcadores precisos utilizando el soporte de retroceso, usar\u00edamos el marcado preciso para asegurarnos de que el antiguo r2 (UINT_MAX) estuviera dentro del nuevo r2 (1) y esto nunca ser\u00eda verdadero, por lo que la verificaci\u00f3n fallar\u00eda leg\u00edtimamente. El resultado final es que el acceso fuera de los l\u00edmites en la instrucci\u00f3n 19 se permitir\u00eda sin esta correcci\u00f3n. Tenga en cuenta que reg-&gt;precise siempre se establece en verdadero cuando el usuario no tiene CAP_BPF (o cuando el recuento de subprocesos es mayor que 1 (es decir, uso de cualquier funci\u00f3n est\u00e1tica o global)), por lo tanto, esto solo es un problema cuando las marcas de precisi\u00f3n deben propagarse expl\u00edcitamente (es decir, usuarios privilegiados con CAP_BPF). Se ha incluido un caso de prueba simplificado en el pr\u00f3ximo parche para evitar futuras regresiones."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49962.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxhci: Fix null pointer dereference in remove if xHC has only one roothub\n\nThe remove path in xhci platform driver tries to remove and put both main\nand shared hcds even if only a main hcd exists (one roothub)\n\nThis causes a null pointer dereference in reboot for those controllers.\n\nCheck that the shared_hcd exists before trying to remove it."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xhci: Se corrige la desreferencia de puntero nulo al eliminar si xHC solo tiene un concentrador ra\u00edz. La ruta de eliminaci\u00f3n en el controlador de la plataforma xhci intenta eliminar e instalar los discos duros principal y compartido, incluso si solo existe un disco duro principal (un concentrador ra\u00edz). Esto provoca una desreferencia de puntero nulo al reiniciar esos controladores. Compruebe que el disco duro compartido exista antes de intentar eliminarlo."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49963.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/ttm: fix CCS handling\n\nCrucible + recent Mesa seems to sometimes hit:\n\nGEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER)\n\nAnd it looks like we can also trigger this with gem_lmem_swapping, if we\nmodify the test to use slightly larger object sizes.\n\nLooking closer it looks like we have the following issues in\nmigrate_copy():\n\n - We are using plain integer in various places, which we can easily\n overflow with a large object.\n\n - We pass the entire object size (when the src is lmem) into\n emit_pte() and then try to copy it, which doesn't work, since we\n only have a few fixed sized windows in which to map the pages and\n perform the copy. With an object > 8M we therefore aren't properly\n copying the pages. And then with an object > 64M we trigger the\n GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER).\n\nSo it looks like our copy handling for any object > 8M (which is our\nCHUNK_SZ) is currently broken on DG2.\n\nTestcase: igt@gem_lmem_swapping\n(cherry picked from commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2)"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/ttm: correcci\u00f3n del manejo de CCS Crucible + Mesa reciente parece a veces afectar: GEM_BUG_ON(num_ccs_blks &gt; NUM_CCS_BLKS_PER_XFER) Y parece que tambi\u00e9n podemos activar esto con gem_lmem_swapping, si modificamos la prueba para usar tama\u00f1os de objeto ligeramente mayores. Mirando m\u00e1s de cerca, parece que tenemos los siguientes problemas en migration_copy(): - Estamos usando un entero simple en varios lugares, que podemos desbordar f\u00e1cilmente con un objeto grande. - Pasamos el tama\u00f1o completo del objeto (cuando el src es lmem) a emit_pte() y luego intentamos copiarlo, lo cual no funciona, ya que solo tenemos unas pocas ventanas de tama\u00f1o fijo en las que mapear las p\u00e1ginas y realizar la copia. Con un objeto &gt; 8M, por lo tanto, no estamos copiando correctamente las p\u00e1ginas. Y luego, con un objeto &gt; 64M, activamos GEM_BUG_ON(num_ccs_blks &gt; NUM_CCS_BLKS_PER_XFER). Por lo tanto, parece que nuestra gesti\u00f3n de copias para cualquier objeto &gt; 8M (que es nuestro CHUNK_SZ) est\u00e1 actualmente inactiva en DG2. Caso de prueba: igt@gem_lmem_swapping (seleccionado de el commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2)"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49964.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: cacheinfo: Fix incorrect assignment of signed error value to unsigned fw_level\n\nThough acpi_find_last_cache_level() always returned signed value and the\ndocument states it will return any errors caused by lack of a PPTT table,\nit never returned negative values before.\n\nCommit 0c80f9e165f8 (\"ACPI: PPTT: Leave the table mapped for the runtime usage\")\nhowever changed it by returning -ENOENT if no PPTT was found. The value\nreturned from acpi_find_last_cache_level() is then assigned to unsigned\nfw_level.\n\nIt will result in the number of cache leaves calculated incorrectly as\na huge value which will then cause the following warning from __alloc_pages\nas the order would be great than MAX_ORDER because of incorrect and huge\ncache leaves value.\n\n | WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:5407 __alloc_pages+0x74/0x314\n | Modules linked in:\n | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-10393-g7c2a8d3ac4c0 #73\n | pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n | pc : __alloc_pages+0x74/0x314\n | lr : alloc_pages+0xe8/0x318\n | Call trace:\n | __alloc_pages+0x74/0x314\n | alloc_pages+0xe8/0x318\n | kmalloc_order_trace+0x68/0x1dc\n | __kmalloc+0x240/0x338\n | detect_cache_attributes+0xe0/0x56c\n | update_siblings_masks+0x38/0x284\n | store_cpu_topology+0x78/0x84\n | smp_prepare_cpus+0x48/0x134\n | kernel_init_freeable+0xc4/0x14c\n | kernel_init+0x2c/0x1b4\n | ret_from_fork+0x10/0x20\n\nFix the same by changing fw_level to be signed integer and return the\nerror from init_cache_level() early in case of error."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: cacheinfo: Se corrige la asignaci\u00f3n incorrecta de un valor de error con signo a unsigned fw_level. Aunque acpi_find_last_cache_level() siempre devolv\u00eda un valor con signo y el documento indica que devolver\u00e1 cualquier error causado por la falta de una tabla PPTT, nunca antes devolv\u00eda valores negativos. Sin embargo, el commit 0c80f9e165f8 (\"ACPI: PPTT: Dejar la tabla asignada para el uso en tiempo de ejecuci\u00f3n\") la modific\u00f3 devolviendo -ENOENT si no se encontraba PPTT. El valor devuelto por acpi_find_last_cache_level() se asigna entonces a unsigned fw_level. Esto provocar\u00e1 que el n\u00famero de hojas de cach\u00e9 se calcule incorrectamente como un valor enorme, lo que provocar\u00e1 la siguiente advertencia de __alloc_pages, ya que el orden ser\u00eda mayor que MAX_ORDER debido a un valor incorrecto y enorme de hojas de cach\u00e9. ADVERTENCIA: CPU: 0 PID: 1 en mm/page_alloc.c:5407 __alloc_pages+0x74/0x314 | M\u00f3dulos vinculados: | CPU: 0 PID: 1 Comm: swapper/0 No contaminado 5.19.0-10393-g7c2a8d3ac4c0 #73 | pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __alloc_pages+0x74/0x314 | lr : alloc_pages+0xe8/0x318 | Rastreo de llamadas: | __alloc_pages+0x74/0x314 | alloc_pages+0xe8/0x318 | kmalloc_order_trace+0x68/0x1dc | Corrija el mismo problema cambiando fw_level para que sea un entero con signo y devuelva el error de init_cache_level() de manera temprana en caso de error."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49965.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: add missing ->fini_xxxx interfaces for some SMU13 asics\n\nWithout these, potential memory leak may be induced."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: agregar interfaces -&gt;fini_xxxx faltantes para algunos ASIC SMU13. Sin estas, se puede inducir una posible p\u00e9rdida de memoria."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49966.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid\n\nTo avoid any potential memory leak."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: agregar la interfaz -&gt;fini_microcode faltante para Sienna Cichlid para evitar cualquier posible p\u00e9rdida de memoria."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49967.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix a data-race around bpf_jit_limit.\n\nWhile reading bpf_jit_limit, it can be changed concurrently via sysctl,\nWRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit\nis long, so we need to add a paired READ_ONCE() to avoid load-tearing."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Se corrige una ejecuci\u00f3n de datos en torno a bpf_jit_limit. Al leer bpf_jit_limit, se puede modificar simult\u00e1neamente mediante sysctl, WRITE_ONCE() en __do_proc_doulongvec_minmax(). El tama\u00f1o de bpf_jit_limit es grande, por lo que es necesario a\u00f1adir un par de READ_ONCE() para evitar la fragmentaci\u00f3n de la carga."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49968.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nieee802154/adf7242: defer destroy_workqueue call\n\nThere is a possible race condition (use-after-free) like below\n\n (FREE) | (USE)\n adf7242_remove | adf7242_channel\n cancel_delayed_work_sync |\n destroy_workqueue (1) | adf7242_cmd_rx\n | mod_delayed_work (2)\n |\n\nThe root cause for this race is that the upper layer (ieee802154) is\nunaware of this detaching event and the function adf7242_channel can\nbe called without any checks.\n\nTo fix this, we can add a flag write at the beginning of adf7242_remove\nand add flag check in adf7242_channel. Or we can just defer the\ndestructive operation like other commit 3e0588c291d6 (\"hamradio: defer\nax25 kfree after unregister_netdev\") which let the\nieee802154_unregister_hw() to handle the synchronization. This patch\ntakes the second option.\n\nruns\")"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ieee802154/adf7242: aplazar la llamada a destroy_workqueue Existe una posible condici\u00f3n de ejecuci\u00f3n (use-after-free) como la siguiente (FREE) | (USE) adf7242_remove | adf7242_channel cancel_delayed_work_sync | destroy_workqueue (1) | adf7242_cmd_rx | mod_delayed_work (2) | La causa ra\u00edz de esta ejecuci\u00f3n es que la capa superior (ieee802154) desconoce este evento de desconexi\u00f3n y la funci\u00f3n adf7242_channel se puede llamar sin ninguna comprobaci\u00f3n. Para solucionar esto, podemos a\u00f1adir una escritura de bandera al principio de adf7242_remove y a\u00f1adir la comprobaci\u00f3n de bandera en adf7242_channel. O podemos simplemente aplazar la operaci\u00f3n destructiva como en el commit 3e0588c291d6 (\"hamradio: defer ax25 kfree after unregister_netdev\"), que permite que ieee802154_unregister_hw() gestione la sincronizaci\u00f3n. Este parche utiliza la segunda opci\u00f3n."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49969.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: clear optc underflow before turn off odm clock\n\n[Why]\nAfter ODM clock off, optc underflow bit will be kept there always and clear not work.\nWe need to clear that before clock off.\n\n[How]\nClear that if have when clock off."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: eliminar el subdesbordamiento de OPC antes de desactivar el reloj ODM [Por qu\u00e9] Tras desactivar el reloj ODM, el bit de subdesbordamiento de OPC se mantendr\u00e1 all\u00ed y la eliminaci\u00f3n no funcionar\u00e1. Necesitamos eliminarlo antes de desactivar el reloj. [C\u00f3mo] Eliminarlo si se produce al desactivar el reloj."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49970.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, cgroup: Fix kernel BUG in purge_effective_progs\n\nSyzkaller reported a triggered kernel BUG as follows:\n\n ------------[ cut here ]------------\n kernel BUG at kernel/bpf/cgroup.c:925!\n invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 1 PID: 194 Comm: detach Not tainted 5.19.0-14184-g69dac8e431af #8\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n RIP: 0010:__cgroup_bpf_detach+0x1f2/0x2a0\n Code: 00 e8 92 60 30 00 84 c0 75 d8 4c 89 e0 31 f6 85 f6 74 19 42 f6 84\n 28 48 05 00 00 02 75 0e 48 8b 80 c0 00 00 00 48 85 c0 75 e5 <0f> 0b 48\n 8b 0c5\n RSP: 0018:ffffc9000055bdb0 EFLAGS: 00000246\n RAX: 0000000000000000 RBX: ffff888100ec0800 RCX: ffffc900000f1000\n RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888100ec4578\n RBP: 0000000000000000 R08: ffff888100ec0800 R09: 0000000000000040\n R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100ec4000\n R13: 000000000000000d R14: ffffc90000199000 R15: ffff888100effb00\n FS: 00007f68213d2b80(0000) GS:ffff88813bc80000(0000)\n knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055f74a0e5850 CR3: 0000000102836000 CR4: 00000000000006e0\n Call Trace:\n <TASK>\n cgroup_bpf_prog_detach+0xcc/0x100\n __sys_bpf+0x2273/0x2a00\n __x64_sys_bpf+0x17/0x20\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0033:0x7f68214dbcb9\n Code: 08 44 89 e0 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 48 89 f8 48 89\n f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01\n f0 ff8\n RSP: 002b:00007ffeb487db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141\n RAX: ffffffffffffffda RBX: 000000000000000b RCX: 00007f68214dbcb9\n RDX: 0000000000000090 RSI: 00007ffeb487db70 RDI: 0000000000000009\n RBP: 0000000000000003 R08: 0000000000000012 R09: 0000000b00000003\n R10: 00007ffeb487db70 R11: 0000000000000246 R12: 00007ffeb487dc20\n R13: 0000000000000004 R14: 0000000000000001 R15: 000055f74a1011b0\n </TASK>\n Modules linked in:\n ---[ end trace 0000000000000000 ]---\n\nRepetition steps:\n\nFor the following cgroup tree,\n\n root\n |\n cg1\n |\n cg2\n\n 1. attach prog2 to cg2, and then attach prog1 to cg1, both bpf progs\n attach type is NONE or OVERRIDE.\n 2. write 1 to /proc/thread-self/fail-nth for failslab.\n 3. detach prog1 for cg1, and then kernel BUG occur.\n\nFailslab injection will cause kmalloc fail and fall back to\npurge_effective_progs. The problem is that cg2 have attached another prog,\nso when go through cg2 layer, iteration will add pos to 1, and subsequent\noperations will be skipped by the following condition, and cg will meet\nNULL in the end.\n\n `if (pos && !(cg->bpf.flags[atype] & BPF_F_ALLOW_MULTI))`\n\nThe NULL cg means no link or prog match, this is as expected, and it's not\na bug. So here just skip the no match situation."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, cgroup: Se corrige el error del kernel en purge_effective_progs Syzkaller inform\u00f3 un error del kernel activado de la siguiente manera: ------------[ cortar aqu\u00ed ]------------ \u00a1Error del kernel en kernel/bpf/cgroup.c:925! C\u00f3digo de operaci\u00f3n no v\u00e1lido: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 194 Comm: detach No contaminado 5.19.0-14184-g69dac8e431af #8 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__cgroup_bpf_detach+0x1f2/0x2a0 C\u00f3digo: 00 e8 92 60 30 00 84 c0 75 d8 4c 89 e0 31 f6 85 f6 74 19 42 f6 84 28 48 05 00 00 02 75 0e 48 8b 80 c0 00 00 00 48 85 c0 75 e5 &lt;0f&gt; 0b 48 8b 0c5 RSP: 0018:ffffc9000055bdb0 EFLAGS: 00000246 RAX: 000000000000000 RBX: ffff888100ec0800 RCX: ffffc900000f1000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888100ec4578 RBP: 000000000000000 R08: ffff888100ec0800 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100ec4000 R13: 000000000000000d R14: ffffc90000199000 R15: ffff888100effb00 FS: 00007f68213d2b80(0000) GS:ffff88813bc80000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f74a0e5850 CR3: 0000000102836000 CR4: 00000000000006e0 Rastreo de llamadas: cgroup_bpf_prog_detach+0xcc/0x100 __sys_bpf+0x2273/0x2a00 __x64_sys_bpf+0x17/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f68214dbcb9 C\u00f3digo: 08 44 89 e0 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff8 RSP: 002b:00007ffeb487db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 00007f68214dbcb9 RDX: 0000000000000090 RSI: 00007ffeb487db70 RDI: 0000000000000009 RBP: 0000000000000003 R08: 0000000000000012 R09: 0000000b00000003 R10: 00007ffeb487db70 R11: 0000000000000246 R12: 00007ffeb487dc20 R13: 000000000000004 R14: 000000000000001 R15: 000055f74a1011b0 M\u00f3dulos vinculados en: ---[ fin del seguimiento 0000000000000000 ]--- Pasos de repetici\u00f3n: Para el siguiente \u00e1rbol de cgroup, root | cg1 | cg2: 1. Adjuntar prog2 a cg2 y, a continuaci\u00f3n, prog1 a cg1. El tipo de conexi\u00f3n de ambos programas bpf es NONE o OVERRIDE. 2. Escribir 1 en /proc/thread-self/fail-nth para failslab. 3. Desconectar prog1 de cg1 y, a continuaci\u00f3n, se produce un error en el n\u00facleo. La inyecci\u00f3n de failslab provocar\u00e1 un fallo en kmalloc y volver\u00e1 a purge_effective_progs. El problema radica en que cg2 ha adjuntado otro programa, por lo que, al pasar por la capa cg2, la iteraci\u00f3n a\u00f1adir\u00e1 pos a 1, y las operaciones posteriores se omitir\u00e1n por la siguiente condici\u00f3n, y cg cumplir\u00e1 con NULL al final. `if (pos &amp;&amp; !(cg-&gt;bpf.flags[atype] &amp; BPF_F_ALLOW_MULTI))` El cg NULL significa que no hay coincidencia de enlace o programa, esto es como se esperaba y no es un error. Por lo tanto, aqu\u00ed simplemente omita la situaci\u00f3n de no coincidencia."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49971.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Fix a potential gpu_metrics_table memory leak\n\nMemory is allocated for gpu_metrics_table in\nsmu_v13_0_4_init_smc_tables(), but not freed in\nsmu_v13_0_4_fini_smc_tables(). This may cause memory leaks, fix it."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Se corrige una posible fuga de memoria en gpu_metrics_table. La memoria se asigna para gpu_metrics_table en smu_v13_0_4_init_smc_tables(), pero no se libera en smu_v13_0_4_fini_smc_tables(). Esto puede causar fugas de memoria; corr\u00edjalo."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49972.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: Fix corrupted packets for XDP_SHARED_UMEM\n\nFix an issue in XDP_SHARED_UMEM mode together with aligned mode where\npackets are corrupted for the second and any further sockets bound to\nthe same umem. In other words, this does not affect the first socket\nbound to the umem. The culprit for this bug is that the initialization\nof the DMA addresses for the pre-populated xsk buffer pool entries was\nnot performed for any socket but the first one bound to the umem. Only\nthe linear array of DMA addresses was populated. Fix this by populating\nthe DMA addresses in the xsk buffer pool for every socket bound to the\nsame umem."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: corrige paquetes da\u00f1ados para XDP_SHARED_UMEM Corrige un problema en el modo XDP_SHARED_UMEM junto con el modo alineado donde los paquetes se corrompen para el segundo socket y cualquier socket posterior vinculado al mismo umem. En otras palabras, esto no afecta al primer socket vinculado al umem. El culpable de este error es que la inicializaci\u00f3n de las direcciones DMA para las entradas del grupo de b\u00faferes xsk pre-rellenadas no se realiz\u00f3 para ning\u00fan socket excepto el primero vinculado al umem. Solo se rellen\u00f3 la matriz lineal de direcciones DMA. Corrige esto rellenando las direcciones DMA en el grupo de b\u00faferes xsk para cada socket vinculado al mismo umem."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49973.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nskmsg: Fix wrong last sg check in sk_msg_recvmsg()\n\nFix one kernel NULL pointer dereference as below:\n\n[ 224.462334] Call Trace:\n[ 224.462394] __tcp_bpf_recvmsg+0xd3/0x380\n[ 224.462441] ? sock_has_perm+0x78/0xa0\n[ 224.462463] tcp_bpf_recvmsg+0x12e/0x220\n[ 224.462494] inet_recvmsg+0x5b/0xd0\n[ 224.462534] __sys_recvfrom+0xc8/0x130\n[ 224.462574] ? syscall_trace_enter+0x1df/0x2e0\n[ 224.462606] ? __do_page_fault+0x2de/0x500\n[ 224.462635] __x64_sys_recvfrom+0x24/0x30\n[ 224.462660] do_syscall_64+0x5d/0x1d0\n[ 224.462709] entry_SYSCALL_64_after_hwframe+0x65/0xca\n\nIn commit 9974d37ea75f (\"skmsg: Fix invalid last sg check in\nsk_msg_recvmsg()\"), we change last sg check to sg_is_last(),\nbut in sockmap redirection case (without stream_parser/stream_verdict/\nskb_verdict), we did not mark the end of the scatterlist. Check the\nsk_msg_alloc, sk_msg_page_add, and bpf_msg_push_data functions, they all\ndo not mark the end of sg. They are expected to use sg.end for end\njudgment. So the judgment of '(i != msg_rx->sg.end)' is added back here."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: skmsg: Corrige la \u00faltima comprobaci\u00f3n sg incorrecta en sk_msg_recvmsg() Corrige una desreferencia de puntero NULL del kernel como se muestra a continuaci\u00f3n: [224.462334] Seguimiento de llamadas: [224.462394] __tcp_bpf_recvmsg+0xd3/0x380 [224.462441] ? syscall_trace_enter+0x1df/0x2e0 [ 224.462606] ? __do_page_fault+0x2de/0x500 [ 224.462635] __x64_sys_recvfrom+0x24/0x30 [ 224.462660] do_syscall_64+0x5d/0x1d0 [ 224.462709] entry_SYSCALL_64_after_hwframe+0x65/0xca En el commit 9974d37ea75f (\"skmsg: Corregir la \u00faltima comprobaci\u00f3n de sg no v\u00e1lida en sk_msg_recvmsg()\"), cambiamos la \u00faltima comprobaci\u00f3n de sg a sg_is_last(), pero en el caso de redirecci\u00f3n de sockmap (sin stream_parser/stream_verdict/skb_verdict), no marcamos el final de la lista de dispersi\u00f3n. Verifique las funciones sk_msg_alloc, sk_msg_page_add y bpf_msg_push_data; ninguna marca el final de sg. Se espera que usen sg.end para la determinaci\u00f3n del final. Por lo tanto, se a\u00f1ade aqu\u00ed la determinaci\u00f3n de '(i != msg_rx-&gt;sg.end)'."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49974.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: nintendo: fix rumble worker null pointer deref\n\nWe can dereference a null pointer trying to queue work to a destroyed\nworkqueue.\n\nIf the device is disconnected, nintendo_hid_remove is called, in which\nthe rumble_queue is destroyed. Avoid using that queue to defer rumble\nwork once the controller state is set to JOYCON_CTLR_STATE_REMOVED.\n\nThis eliminates the null pointer dereference."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: Nintendo: correcci\u00f3n de la desreferencia del puntero nulo del trabajador de rumble. Podemos desreferenciar un puntero nulo que intenta poner en cola trabajo a una cola de trabajo destruida. Si el dispositivo se desconecta, se llama a nintendo_hid_remove, lo que destruye la cola de rumble. Evite usar esa cola para aplazar el trabajo de rumble una vez que el estado del mando se establezca en JOYCON_CTLR_STATE_REMOVED. Esto elimina la desreferencia del puntero nulo."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49975.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Don't redirect packets with invalid pkt_len\n\nSyzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any\nskbs, that is, the flow->head is null.\nThe root cause, as the [2] says, is because that bpf_prog_test_run_skb()\nrun a bpf prog which redirects empty skbs.\nSo we should determine whether the length of the packet modified by bpf\nprog or others like bpf_prog_test is valid before forwarding it directly."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: No redirigir paquetes con pkt_len no v\u00e1lidos. Syzbot encontr\u00f3 un problema [1]: fq_codel_drop() intenta descartar un flujo sin skbs, es decir, el flujo-&gt;head es nulo. La causa principal, como se indica en [2], es que bpf_prog_test_run_skb() ejecuta un programa bpf que redirige skbs vac\u00edos. Por lo tanto, debemos determinar si la longitud del paquete modificado por el programa bpf u otros como bpf_prog_test es v\u00e1lida antes de reenviarlo directamente."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49976.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: x86-android-tablets: Fix broken touchscreen on Chuwi Hi8 with Windows BIOS\n\nThe x86-android-tablets handling for the Chuwi Hi8 is only necessary with\nthe Android BIOS and it is causing problems with the Windows BIOS version.\n\nSpecifically when trying to register the already present touchscreen\nx86_acpi_irq_helper_get() calls acpi_unregister_gsi(), this breaks\nthe working of the touchscreen and also leads to an oops:\n\n[ 14.248946] ------------[ cut here ]------------\n[ 14.248954] remove_proc_entry: removing non-empty directory 'irq/75', leaking at least 'MSSL0001:00'\n[ 14.248983] WARNING: CPU: 3 PID: 440 at fs/proc/generic.c:718 remove_proc_entry\n...\n[ 14.249293] unregister_irq_proc+0xe0/0x100\n[ 14.249305] free_desc+0x29/0x70\n[ 14.249312] irq_free_descs+0x4b/0x80\n[ 14.249320] mp_unmap_irq+0x5c/0x60\n[ 14.249329] acpi_unregister_gsi_ioapic+0x2a/0x40\n[ 14.249338] x86_acpi_irq_helper_get+0x4b/0x190 [x86_android_tablets]\n[ 14.249355] x86_android_tablet_init+0x178/0xe34 [x86_android_tablets]\n\nAdd an init callback for the Chuwi Hi8, which detects when the Windows BIOS\nis in use and exits with -ENODEV in that case, fixing this."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86: x86-android-tablets: Reparar la pantalla t\u00e1ctil rota en Chuwi Hi8 con BIOS de Windows El manejo de x86-android-tablets para Chuwi Hi8 solo es necesario con el BIOS de Android y est\u00e1 causando problemas con la versi\u00f3n del BIOS de Windows. Espec\u00edficamente cuando se intenta registrar la pantalla t\u00e1ctil ya presente, x86_acpi_irq_helper_get() llama a acpi_unregister_gsi(), esto interrumpe el funcionamiento de la pantalla t\u00e1ctil y tambi\u00e9n conduce a un error: [ 14.248946] ------------[ cortar aqu\u00ed ]------------ [ 14.248954] remove_proc_entry: eliminando el directorio no vac\u00edo 'irq/75', filtrando al menos 'MSSL0001:00' [ 14.248983] ADVERTENCIA: CPU: 3 PID: 440 en fs/proc/generic.c:718 remove_proc_entry ... [ 14.249293] unregister_irq_proc+0xe0/0x100 [ 14.249305] free_desc+0x29/0x70 [ 14.249312] irq_free_descs+0x4b/0x80 [ 14.249320] mp_unmap_irq+0x5c/0x60 [ 14.249329] acpi_unregister_gsi_ioapic+0x2a/0x40 [ 14.249338] x86_acpi_irq_helper_get+0x4b/0x190 [x86_android_tablets] [ 14.249355] x86_android_tablet_init+0x178/0xe34 [x86_android_tablets] Agregue una devoluci\u00f3n de llamada de inicio para Chuwi Hi8, que detecta cuando el BIOS de Windows est\u00e1 en uso y sale con -ENODEV en ese caso, solucionando esto."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49977.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead\n\nftrace_startup does not remove ops from ftrace_ops_list when\nftrace_startup_enable fails:\n\nregister_ftrace_function\n ftrace_startup\n __register_ftrace_function\n ...\n add_ftrace_ops(&ftrace_ops_list, ops)\n ...\n ...\n ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1\n ...\n return 0 // ops is in the ftrace_ops_list.\n\nWhen ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything:\nunregister_ftrace_function\n ftrace_shutdown\n if (unlikely(ftrace_disabled))\n return -ENODEV; // return here, __unregister_ftrace_function is not executed,\n // as a result, ops is still in the ftrace_ops_list\n __unregister_ftrace_function\n ...\n\nIf ops is dynamically allocated, it will be free later, in this case,\nis_ftrace_trampoline accesses NULL pointer:\n\nis_ftrace_trampoline\n ftrace_ops_trampoline\n do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL!\n\nSyzkaller reports as follows:\n[ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b\n[ 1203.508039] #PF: supervisor read access in kernel mode\n[ 1203.508798] #PF: error_code(0x0000) - not-present page\n[ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0\n[ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI\n[ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W 5.10.0 #8\n[ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0\n[ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00\n[ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246\n[ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866\n[ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b\n[ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07\n[ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399\n[ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008\n[ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000\n[ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0\n[ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n\nTherefore, when ftrace_startup_enable fails, we need to rollback registration\nprocess and remove ops from ftrace_ops_list."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Se corrige la desreferencia del puntero NULL en is_ftrace_trampoline cuando ftrace est\u00e1 inactivo ftrace_startup no elimina las operaciones de ftrace_ops_list cuando ftrace_startup_enable falla: register_ftrace_function ftrace_startup __register_ftrace_function ... add_ftrace_ops(&amp;ftrace_ops_list, ops) ... ... ftrace_startup_enable // si ftrace no se modific\u00f3, ftrace_disabled se establece en 1 ... return 0 // las operaciones est\u00e1n en ftrace_ops_list. Cuando ftrace_disabled = 1, unregister_ftrace_function simplemente regresa sin hacer nada: unregister_ftrace_function ftrace_shutdown if (unlikely(ftrace_disabled)) return -ENODEV; // regresa aqu\u00ed, __unregister_ftrace_function no se ejecuta, // como resultado, ops todav\u00eda est\u00e1 en ftrace_ops_list __unregister_ftrace_function ... Si ops se asigna din\u00e1micamente, estar\u00e1 libre m\u00e1s tarde, en este caso, is_ftrace_trampoline accede al puntero NULL: is_ftrace_trampoline ftrace_ops_trampoline do_for_each_ftrace_op(op, ftrace_ops_list) // \u00a1UPS! \u00a1op puede ser NULL! Syzkaller informa lo siguiente: [ 1203.506103] ERROR: desreferencia de puntero NULL del kernel, direcci\u00f3n: 000000000000010b [ 1203.508039] #PF: acceso de lectura del supervisor en modo kernel [ 1203.508798] #PF: error_code(0x0000) - p\u00e1gina no presente [ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0 [ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI [ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Contaminado: GBW 5.10.0 #8 [1203.512324] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 01/04/2014 [1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0 [1203.514644] C\u00f3digo: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 &lt;48&gt; 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00 [ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246 [ 1203.520092] RAX: 000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866 [ 1203.521469] RDX: 00000000000000000 RSI: 0000000000000008 RDI: 0000000000000010b [ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07 [ 1203.523550] R10: fffffbfff1be3160 R11: 000000000000001 R12: 0000000000478399 [ 1203.524596] R13: 000000000000000 R14: ffff888145088000 R15: 0000000000000008 [ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000 [ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1203.527626] CR2: 00000000000010b CR3: 0000000170e1e001 CR4: 000000000003706e0 [ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Por lo tanto, cuando ftrace_startup_enable falla, debemos revertir el proceso de registro y eliminar las operaciones de ftrace_ops_list."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49978.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: fb_pm2fb: Avoid potential divide by zero error\n\nIn `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be\ncopied from user, then go through `fb_set_var()` and\n`info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`.\nAlong the path, `var->pixclock` won't be modified. This function checks\nwhether reciprocal of `var->pixclock` is too high. If `var->pixclock` is\nzero, there will be a divide by zero error. So, it is necessary to check\nwhether denominator is zero to avoid crash. As this bug is found by\nSyzkaller, logs are listed below.\n\ndivide error in pm2fb_check_var\nCall Trace:\n <TASK>\n fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015\n do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110\n fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: fb_pm2fb: Evitar posible error de divisi\u00f3n por cero En `do_fb_ioctl()` de fbmem.c, si cmd es FBIOPUT_VSCREENINFO, var se copiar\u00e1 del usuario, luego pasar\u00e1 por `fb_set_var()` e `info-&gt;fbops-&gt;fb_check_var()` que podr\u00edan ser `pm2fb_check_var()`. A lo largo de la ruta, `var-&gt;pixclock` no se modificar\u00e1. Esta funci\u00f3n verifica si el rec\u00edproco de `var-&gt;pixclock` es demasiado alto. Si `var-&gt;pixclock` es cero, habr\u00e1 un error de divisi\u00f3n por cero. Por lo tanto, es necesario verificar si el denominador es cero para evitar un bloqueo. Como Syzkaller encontr\u00f3 este error, los registros se enumeran a continuaci\u00f3n. Error de divisi\u00f3n en el seguimiento de llamadas pm2fb_check_var: fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49979.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix refcount bug in sk_psock_get (2)\n\nSyzkaller reports refcount bug as follows:\n------------[ cut here ]------------\nrefcount_t: saturated; leaking memory.\nWARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19\nModules linked in:\nCPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0\n <TASK>\n __refcount_add_not_zero include/linux/refcount.h:163 [inline]\n __refcount_inc_not_zero include/linux/refcount.h:227 [inline]\n refcount_inc_not_zero include/linux/refcount.h:245 [inline]\n sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439\n tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091\n tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983\n tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057\n tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659\n tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682\n sk_backlog_rcv include/net/sock.h:1061 [inline]\n __release_sock+0x134/0x3b0 net/core/sock.c:2849\n release_sock+0x54/0x1b0 net/core/sock.c:3404\n inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909\n __sys_shutdown_sock net/socket.c:2331 [inline]\n __sys_shutdown_sock net/socket.c:2325 [inline]\n __sys_shutdown+0xf1/0x1b0 net/socket.c:2343\n __do_sys_shutdown net/socket.c:2351 [inline]\n __se_sys_shutdown net/socket.c:2349 [inline]\n __x64_sys_shutdown+0x50/0x70 net/socket.c:2349\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n </TASK>\n\nDuring SMC fallback process in connect syscall, kernel will\nreplaces TCP with SMC. In order to forward wakeup\nsmc socket waitqueue after fallback, kernel will sets\nclcsk->sk_user_data to origin smc socket in\nsmc_fback_replace_callbacks().\n\nLater, in shutdown syscall, kernel will calls\nsk_psock_get(), which treats the clcsk->sk_user_data\nas psock type, triggering the refcnt warning.\n\nSo, the root cause is that smc and psock, both will use\nsk_user_data field. So they will mismatch this field\neasily.\n\nThis patch solves it by using another bit(defined as\nSK_USER_DATA_PSOCK) in PTRMASK, to mark whether\nsk_user_data points to a psock object or not.\nThis patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e\n(\"net, sk_msg: Clear sk_user_data pointer on clone if tagged\").\n\nFor there will possibly be more flags in the sk_user_data field,\nthis patch also refactor sk_user_data flags code to be more generic\nto improve its maintainability."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: corrige error de recuento de referencias en sk_psock_get (2) Syzkaller informa el siguiente error de recuento de referencias: ------------[ cortar aqu\u00ed ]------------ refcount_t: saturado; p\u00e9rdida de memoria. ADVERTENCIA: CPU: 1 PID: 3605 en lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19 M\u00f3dulos vinculados: CPU: 1 PID: 3605 Comm: syz-executor208 No contaminado 5.18.0-syzkaller-03023-g7e062cda7d90 #0 __refcount_add_not_zero include/linux/refcount.h:163 [en l\u00ednea] __refcount_inc_not_zero include/linux/refcount.h:227 [en l\u00ednea] refcount_inc_not_zero include/linux/refcount.h:245 [en l\u00ednea] sk_psock_get+0x3bc/0x410 incluir/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv incluir/net/sock.h:1061 [en l\u00ednea] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [en l\u00ednea] __sys_shutdown_sock net/socket.c:2325 [en l\u00ednea] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [en l\u00ednea] __se_sys_shutdown net/socket.c:2349 [en l\u00ednea] Durante el proceso de respaldo de SMC en la llamada al sistema de conexi\u00f3n, el kernel reemplaza TCP con SMC. Para reenviar la cola de espera del socket SMC de activaci\u00f3n despu\u00e9s del respaldo, el kernel establece clcsk-&gt;sk_user_data en el socket SMC de origen en smc_fback_replace_callbacks(). Posteriormente, en la llamada al sistema de apagado, el kernel llamar\u00e1 a sk_psock_get(), que trata clcsk-&gt;sk_user_data como de tipo psock, lo que activa la advertencia refcnt. Por lo tanto, la causa principal es que tanto smc como psock utilizan el campo sk_user_data, por lo que es f\u00e1cil que no coincidan con este campo. Este parche soluciona este problema utilizando otro bit (definido como SK_USER_DATA_PSOCK) en PTRMASK para indicar si sk_user_data apunta a un objeto psock. Este parche depende de una PTRMASK introducida en el commit f1ff5ce2cd5e (\"net, sk_msg: Borrar el puntero sk_user_data al clonar si est\u00e1 etiquetado\"). Dado que posiblemente haya m\u00e1s indicadores en el campo sk_user_data, este parche tambi\u00e9n refactoriza el c\u00f3digo de indicadores sk_user_data para que sea m\u00e1s gen\u00e9rico y mejore su mantenimiento."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49980.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: Fix use-after-free Read in usb_udc_uevent()\n\nThe syzbot fuzzer found a race between uevent callbacks and gadget\ndriver unregistration that can cause a use-after-free bug:\n\n---------------------------------------------------------------\nBUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130\ndrivers/usb/gadget/udc/core.c:1732\nRead of size 8 at addr ffff888078ce2050 by task udevd/2968\n\nCPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google\n06/29/2022\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:317 [inline]\n print_report.cold+0x2ba/0x719 mm/kasan/report.c:433\n kasan_report+0xbe/0x1f0 mm/kasan/report.c:495\n usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732\n dev_uevent+0x290/0x770 drivers/base/core.c:2424\n---------------------------------------------------------------\n\nThe bug occurs because usb_udc_uevent() dereferences udc->driver but\ndoes so without acquiring the udc_lock mutex, which protects this\nfield. If the gadget driver is unbound from the udc concurrently with\nuevent processing, the driver structure may be accessed after it has\nbeen deallocated.\n\nTo prevent the race, we make sure that the routine holds the mutex\naround the racing accesses."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: gadget: Correcci\u00f3n de lectura de Use-After-Free en usb_udc_uevent() El analizador de vulnerabilidades syzbot encontr\u00f3 una ejecuci\u00f3n entre las devoluciones de llamadas de uevent y la anulaci\u00f3n del registro del controlador del gadget que puede causar un error de Use-After-Free: --------------------------------------------------------------- ERROR: KASAN: Use-After-Free en usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 Lectura de tama\u00f1o 8 en la direcci\u00f3n ffff888078ce2050 por la tarea udevd/2968 CPU: 1 PID: 2968 Comm: udevd No contaminado 5.19.0-rc4-next-20220628-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 29/06/2022 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495 usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 dev_uevent+0x290/0x770 drivers/base/core.c:2424 --------------------------------------------------------------- El error ocurre porque usb_udc_uevent() desreferencia udc-&gt;driver pero lo hace sin adquirir el Mutex udc_lock, que protege este campo. Si el controlador del gadget se desvincula del udc simult\u00e1neamente con el procesamiento de uevent, se puede acceder a la estructura del controlador despu\u00e9s de su desasignaci\u00f3n. Para evitar la competencia, nos aseguramos de que la rutina mantenga el mutex en los accesos de competencia."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49981.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: hidraw: fix memory leak in hidraw_release()\n\nFree the buffered reports before deleting the list entry.\n\nBUG: memory leak\nunreferenced object 0xffff88810e72f180 (size 32):\n comm \"softirq\", pid 0, jiffies 4294945143 (age 16.080s)\n hex dump (first 32 bytes):\n 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace:\n [<ffffffff814ac6c3>] kmemdup+0x23/0x50 mm/util.c:128\n [<ffffffff8357c1d2>] kmemdup include/linux/fortify-string.h:440 [inline]\n [<ffffffff8357c1d2>] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521\n [<ffffffff8356ddad>] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992\n [<ffffffff8356e41e>] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065\n [<ffffffff835f0d3f>] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284\n [<ffffffff82d3c7f9>] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670\n [<ffffffff82d3cc26>] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747\n [<ffffffff82ef1e14>] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988\n [<ffffffff812f50a8>] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474\n [<ffffffff812f5586>] expire_timers kernel/time/timer.c:1519 [inline]\n [<ffffffff812f5586>] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790\n [<ffffffff812f56e4>] __run_timers kernel/time/timer.c:1768 [inline]\n [<ffffffff812f56e4>] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803\n [<ffffffff848000e6>] __do_softirq+0xe6/0x2ea kernel/softirq.c:571\n [<ffffffff81246db0>] invoke_softirq kernel/softirq.c:445 [inline]\n [<ffffffff81246db0>] __irq_exit_rcu kernel/softirq.c:650 [inline]\n [<ffffffff81246db0>] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662\n [<ffffffff84574f02>] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106\n [<ffffffff84600c8b>] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649\n [<ffffffff8458a070>] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline]\n [<ffffffff8458a070>] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline]\n [<ffffffff8458a070>] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline]\n [<ffffffff8458a070>] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: hidraw: corrige p\u00e9rdida de memoria en hidraw_release() Libera los informes almacenados en b\u00fafer antes de eliminar la entrada de la lista. ERROR: Fuga de memoria, objeto no referenciado 0xffff88810e72f180 (tama\u00f1o 32): comm \"softirq\", pid 0, jiffies 4294945143 (edad 16.080s) volcado hexadecimal (primeros 32 bytes): 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 00 d..j............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemdup+0x23/0x50 mm/util.c:128 [] kmemdup include/linux/fortify-string.h:440 [inline] [] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521 [] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992 [] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065 [] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284 [] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670 [] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747 [] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988 [] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474 [] expire_timers kernel/time/timer.c:1519 [inline] [] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790 [] __run_timers kernel/time/timer.c:1768 [inline] [] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803 [] __do_softirq+0xe6/0x2ea kernel/softirq.c:571 [] invoke_softirq kernel/softirq.c:445 [inline] [] __irq_exit_rcu kernel/softirq.c:650 [inline] [] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662 [] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106 [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649 [] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline] [] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline] [] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline] [] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554 "
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49982.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: pvrusb2: fix memory leak in pvr_probe\n\nThe error handling code in pvr2_hdw_create forgets to unregister the\nv4l2 device. When pvr2_hdw_create returns back to pvr2_context_create,\nit calls pvr2_context_destroy to destroy context, but mp->hdw is NULL,\nwhich leads to that pvr2_hdw_destroy directly returns.\n\nFix this by adding v4l2_device_unregister to decrease the refcount of\nusb interface."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: pvrusb2: se corrige una fuga de memoria en pvr_probe. El c\u00f3digo de gesti\u00f3n de errores en pvr2_hdw_create olvida anular el registro del dispositivo v4l2. Cuando pvr2_hdw_create regresa a pvr2_context_create, llama a pvr2_context_destroy para destruir el contexto, pero mp-&gt;hdw es NULL, lo que provoca que pvr2_hdw_destroy regrese directamente. Para solucionar esto, agregue v4l2_device_unregister para reducir el recuento de referencias de la interfaz USB."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49983.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nudmabuf: Set the DMA mask for the udmabuf device (v2)\n\nIf the DMA mask is not set explicitly, the following warning occurs\nwhen the userspace tries to access the dma-buf via the CPU as\nreported by syzbot here:\n\nWARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188\n__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188\nModules linked in:\nCPU: 0 PID: 3595 Comm: syz-executor249 Not tainted\n5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS\nGoogle 01/01/2011\nRIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188\nCode: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0\n83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45\n 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00\nRSP: 0018:ffffc90002a07d68 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408\nRBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f\nR10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002\nR13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000\nFS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264\n get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72\n begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126\n dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164\n dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:874 [inline]\n __se_sys_ioctl fs/ioctl.c:860 [inline]\n __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f62fcf530f9\nCode: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89\nf7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01\nf0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9\nRDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006\nRBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n </TASK>\n\nv2: Dont't forget to deregister if DMA mask setup fails."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udmabuf: Establezca la m\u00e1scara DMA para el dispositivo udmabuf (v2) Si la m\u00e1scara DMA no se establece expl\u00edcitamente, se produce la siguiente advertencia cuando el espacio de usuario intenta acceder a dma-buf a trav\u00e9s de la CPU, como lo informa syzbot aqu\u00ed: ADVERTENCIA: CPU: 1 PID: 3595 en kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 M\u00f3dulos vinculados en: CPU: 0 PID: 3595 Comm: syz-executor249 No contaminado 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 C\u00f3digo: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 &lt;0f&gt; 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 00000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 000000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 v2: No olvide cancelar el registro si falla la configuraci\u00f3n de la m\u00e1scara DMA."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49984.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report\n\nIt is possible for a malicious device to forgo submitting a Feature\nReport. The HID Steam driver presently makes no prevision for this\nand de-references the 'struct hid_report' pointer obtained from the\nHID devices without first checking its validity. Let's change that."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: Steam: Impedir la desreferencia de puntero nulo en steam_{recv,send}_report. Es posible que un dispositivo malicioso no env\u00ede un Informe de Caracter\u00edsticas. El controlador HID Steam no prev\u00e9 esto actualmente y desreferencia el puntero 'struct hid_report' obtenido de los dispositivos HID sin verificar primero su validez. Vamos a corregir esto."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49985.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Don't use tnum_range on array range checking for poke descriptors\n\nHsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which\nis based on a customized syzkaller:\n\n BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0\n Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489\n CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n 1.13.0-1ubuntu1.1 04/01/2014\n Call Trace:\n <TASK>\n dump_stack_lvl+0x9c/0xc9\n print_address_description.constprop.0+0x1f/0x1f0\n ? bpf_int_jit_compile+0x1257/0x13f0\n kasan_report.cold+0xeb/0x197\n ? kvmalloc_node+0x170/0x200\n ? bpf_int_jit_compile+0x1257/0x13f0\n bpf_int_jit_compile+0x1257/0x13f0\n ? arch_prepare_bpf_dispatcher+0xd0/0xd0\n ? rcu_read_lock_sched_held+0x43/0x70\n bpf_prog_select_runtime+0x3e8/0x640\n ? bpf_obj_name_cpy+0x149/0x1b0\n bpf_prog_load+0x102f/0x2220\n ? __bpf_prog_put.constprop.0+0x220/0x220\n ? find_held_lock+0x2c/0x110\n ? __might_fault+0xd6/0x180\n ? lock_downgrade+0x6e0/0x6e0\n ? lock_is_held_type+0xa6/0x120\n ? __might_fault+0x147/0x180\n __sys_bpf+0x137b/0x6070\n ? bpf_perf_link_attach+0x530/0x530\n ? new_sync_read+0x600/0x600\n ? __fget_files+0x255/0x450\n ? lock_downgrade+0x6e0/0x6e0\n ? fput+0x30/0x1a0\n ? ksys_write+0x1a8/0x260\n __x64_sys_bpf+0x7a/0xc0\n ? syscall_enter_from_user_mode+0x21/0x70\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0033:0x7f917c4e2c2d\n\nThe problem here is that a range of tnum_range(0, map->max_entries - 1) has\nlimited ability to represent the concrete tight range with the tnum as the\nset of resulting states from value + mask can result in a superset of the\nactual intended range, and as such a tnum_in(range, reg->var_off) check may\nyield true when it shouldn't, for example tnum_range(0, 2) would result in\n00XX -> v = 0000, m = 0011 such that the intended set of {0, 1, 2} is here\nrepresented by a less precise superset of {0, 1, 2, 3}. As the register is\nknown const scalar, really just use the concrete reg->var_off.value for the\nupper index check."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: No use tnum_range en la comprobaci\u00f3n del rango de matriz para los descriptores de poke Hsin-Wei inform\u00f3 un splat de KASAN activado por su fuzzer de tiempo de ejecuci\u00f3n BPF que se basa en un syzkaller personalizado: ERROR: KASAN: slab-out-of-bounds en bpf_int_jit_compile+0x1257/0x13f0 Lectura de tama\u00f1o 8 en la direcci\u00f3n ffff888004e90b58 por la tarea syz-executor.0/1489 CPU: 1 PID: 1489 Comm: syz-executor.0 No contaminado 5.19.0 #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x9c/0xc9 print_address_description.constprop.0+0x1f/0x1f0 ? bpf_int_jit_compile+0x1257/0x13f0 kasan_report.cold+0xeb/0x197 ? kvmalloc_node+0x170/0x200 ? bpf_int_jit_compile+0x1257/0x13f0 bpf_int_jit_compile+0x1257/0x13f0 ? arch_prepare_bpf_dispatcher+0xd0/0xd0 ? rcu_read_lock_sched_held+0x43/0x70 bpf_prog_select_runtime+0x3e8/0x640 ? bpf_obj_name_cpy+0x149/0x1b0 bpf_prog_load+0x102f/0x2220 ? __bpf_prog_put.constprop.0+0x220/0x220 ? find_held_lock+0x2c/0x110 ? __might_fault+0xd6/0x180 ? lock_downgrade+0x6e0/0x6e0 ? lock_is_held_type+0xa6/0x120 ? __might_fault+0x147/0x180 __sys_bpf+0x137b/0x6070 ? bpf_perf_link_attach+0x530/0x530 ? new_sync_read+0x600/0x600 ? __fget_files+0x255/0x450 ? lock_downgrade+0x6e0/0x6e0 ? fput+0x30/0x1a0 ? ksys_write+0x1a8/0x260 __x64_sys_bpf+0x7a/0xc0 ? syscall_enter_from_user_mode+0x21/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f917c4e2c2d El problema aqu\u00ed es que un rango de tnum_range(0, map-&gt;max_entries - 1) tiene una capacidad limitada para representar el rango estrecho concreto con el tnum como el conjunto de estados resultantes de value + mask puede resultar en un superconjunto del rango real deseado, y como tal una comprobaci\u00f3n tnum_in(range, reg-&gt;var_off) puede dar como resultado verdadero cuando no deber\u00eda, por ejemplo tnum_range(0, 2) dar\u00eda como resultado 00XX -&gt; v = 0000, m = 0011 de modo que el conjunto deseado de {0, 1, 2} est\u00e1 representado aqu\u00ed por un superconjunto menos preciso de {0, 1, 2, 3}. Como el registro es un escalar constante, simplemente use el valor concreto reg-&gt;var_off.value para la verificaci\u00f3n del \u00edndice superior."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49986.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq\n\nstorvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it\ndoesn't need to make forward progress under memory pressure. Marking this\nworkqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a\nnon-WQ_MEM_RECLAIM workqueue. In the current state it causes the following\nwarning:\n\n[ 14.506347] ------------[ cut here ]------------\n[ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn\n[ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130\n[ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu\n[ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022\n[ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun\n[ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130\n\t\t<-snip->\n[ 14.506408] Call Trace:\n[ 14.506412] __flush_work+0xf1/0x1c0\n[ 14.506414] __cancel_work_timer+0x12f/0x1b0\n[ 14.506417] ? kernfs_put+0xf0/0x190\n[ 14.506418] cancel_delayed_work_sync+0x13/0x20\n[ 14.506420] disk_block_events+0x78/0x80\n[ 14.506421] del_gendisk+0x3d/0x2f0\n[ 14.506423] sr_remove+0x28/0x70\n[ 14.506427] device_release_driver_internal+0xef/0x1c0\n[ 14.506428] device_release_driver+0x12/0x20\n[ 14.506429] bus_remove_device+0xe1/0x150\n[ 14.506431] device_del+0x167/0x380\n[ 14.506432] __scsi_remove_device+0x11d/0x150\n[ 14.506433] scsi_remove_device+0x26/0x40\n[ 14.506434] storvsc_remove_lun+0x40/0x60\n[ 14.506436] process_one_work+0x209/0x400\n[ 14.506437] worker_thread+0x34/0x400\n[ 14.506439] kthread+0x121/0x140\n[ 14.506440] ? process_one_work+0x400/0x400\n[ 14.506441] ? kthread_park+0x90/0x90\n[ 14.506443] ret_from_fork+0x35/0x40\n[ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]---"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: storvsc: Eliminar WQ_MEM_RECLAIM de storvsc_error_wq. La cola de trabajo storvsc_error_wq no debe marcarse como WQ_MEM_RECLAIM, ya que no necesita avanzar bajo presi\u00f3n de memoria. Marcar esta cola de trabajo como WQ_MEM_RECLAIM puede causar un bloqueo al vaciar una cola de trabajo que no sea WQ_MEM_RECLAIM. En el estado actual, provoca la siguiente advertencia: [ 14.506347] ------------[ cortar aqu\u00ed ]------------ [ 14.506354] cola de trabajo: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun se est\u00e1 vaciando !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn [ 14.506360] ADVERTENCIA: CPU: 0 PID: 8 en &lt;-snip-&gt;kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 No contaminado 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Nombre del hardware: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI versi\u00f3n v4.1 09/05/2022 [ 14.506393] Cola de trabajo: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 &lt;-snip-&gt; [ 14.506408] Seguimiento de llamadas: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414] __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418] cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421] del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427] device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429] bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432] __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437] worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [ 14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ fin de seguimiento 2d9633159fdc6ee7 ]---"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49987.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: call __md_stop_writes in md_stop\n\nFrom the link [1], we can see raid1d was running even after the path\nraid_dtr -> md_stop -> __md_stop.\n\nLet's stop write first in destructor to align with normal md-raid to\nfix the KASAN issue.\n\n[1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: llamada a __md_stop_writes en md_stop. En el enlace [1], podemos ver que raid1d se ejecutaba incluso despu\u00e9s de la ruta raid_dtr -&gt; md_stop -&gt; __md_stop. Primero detengamos la escritura en el destructor para alinearla con el comando md-raid normal y solucionar el problema de KASAN. [1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49989.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen/privcmd: fix error exit of privcmd_ioctl_dm_op()\n\nThe error exit of privcmd_ioctl_dm_op() is calling unlock_pages()\npotentially with pages being NULL, leading to a NULL dereference.\n\nAdditionally lock_pages() doesn't check for pin_user_pages_fast()\nhaving been completely successful, resulting in potentially not\nlocking all pages into memory. This could result in sporadic failures\nwhen using the related memory in user mode.\n\nFix all of that by calling unlock_pages() always with the real number\nof pinned pages, which will be zero in case pages being NULL, and by\nchecking the number of pages pinned by pin_user_pages_fast() matching\nthe expected number of pages."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen/privcmd: correcci\u00f3n del error de salida de privcmd_ioctl_dm_op(). La salida de error de privcmd_ioctl_dm_op() est\u00e1 llamando a unlock_pages() potencialmente con p\u00e1ginas NULL, lo que lleva a una desreferencia NULL. Adem\u00e1s, lock_pages() no comprueba si pin_user_pages_fast() ha sido completamente exitoso, lo que resulta en que potencialmente no se bloqueen todas las p\u00e1ginas en la memoria. Esto podr\u00eda resultar en fallos espor\u00e1dicos al usar la memoria relacionada en modo de usuario. Corrija todo esto llamando a unlock_pages() siempre con el n\u00famero real de p\u00e1ginas ancladas, que ser\u00e1 cero en caso de que pages sea NULL, y comprobando que el n\u00famero de p\u00e1ginas ancladas por pin_user_pages_fast() coincida con el n\u00famero esperado de p\u00e1ginas."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49990.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390: fix double free of GS and RI CBs on fork() failure\n\nThe pointers for guarded storage and runtime instrumentation control\nblocks are stored in the thread_struct of the associated task. These\npointers are initially copied on fork() via arch_dup_task_struct()\nand then cleared via copy_thread() before fork() returns. If fork()\nhappens to fail after the initial task dup and before copy_thread(),\nthe newly allocated task and associated thread_struct memory are\nfreed via free_task() -> arch_release_task_struct(). This results in\na double free of the guarded storage and runtime info structs\nbecause the fields in the failed task still refer to memory\nassociated with the source task.\n\nThis problem can manifest as a BUG_ON() in set_freepointer() (with\nCONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled)\nwhen running trinity syscall fuzz tests on s390x. To avoid this\nproblem, clear the associated pointer fields in\narch_dup_task_struct() immediately after the new task is copied.\nNote that the RI flag is still cleared in copy_thread() because it\nresides in thread stack memory and that is where stack info is\ncopied."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390: se corrige la doble liberaci\u00f3n de los bloques de control de instrumentaci\u00f3n de GS y RI en el fallo de fork() Los punteros para los bloques de control de instrumentaci\u00f3n de almacenamiento protegido y tiempo de ejecuci\u00f3n se almacenan en el thread_struct de la tarea asociada. Estos punteros se copian inicialmente en fork() mediante arch_dup_task_struct() y luego se borran mediante copy_thread() antes de que fork() regrese. Si fork() falla despu\u00e9s del dup de la tarea inicial y antes de copy_thread(), la tarea reci\u00e9n asignada y la memoria thread_struct asociada se liberan mediante free_task() -&gt; arch_release_task_struct(). Esto resulta en una doble liberaci\u00f3n de las estructuras de informaci\u00f3n de almacenamiento protegido y tiempo de ejecuci\u00f3n porque los campos en la tarea fallida todav\u00eda hacen referencia a la memoria asociada con la tarea de origen. Este problema puede manifestarse como un BUG_ON() en set_freepointer() (con CONFIG_SLAB_FREELIST_HARDENED habilitado) o un error de KASAN (si est\u00e1 habilitado) al ejecutar pruebas de fuzzing de llamadas al sistema de Trinity en s390x. Para evitar este problema, borre los campos de puntero asociados en arch_dup_task_struct() inmediatamente despu\u00e9s de copiar la nueva tarea. Tenga en cuenta que el indicador RI permanece borrado en copy_thread() porque reside en la memoria de la pila de subprocesos, donde se copia la informaci\u00f3n de la pila."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49991.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pte\n\nIn MCOPY_ATOMIC_CONTINUE case with a non-shared VMA, pages in the page\ncache are installed in the ptes. But hugepage_add_new_anon_rmap is called\nfor them mistakenly because they're not vm_shared. This will corrupt the\npage->mapping used by page cache code."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: evitar la corrupci\u00f3n del mapeo de p\u00e1ginas en hugetlb_mcopy_atomic_pte. En el caso de MCOPY_ATOMIC_CONTINUE con un VMA no compartido, las p\u00e1ginas de la cach\u00e9 de p\u00e1ginas se instalan en los ptes. Sin embargo, se llama a hugepage_add_new_anon_rmap por error porque no son vm_shared. Esto corromper\u00e1 el mapeo de p\u00e1ginas utilizado por el c\u00f3digo de la cach\u00e9 de p\u00e1ginas."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49992.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mprotect: only reference swap pfn page if type match\n\nYu Zhao reported a bug after the commit \"mm/swap: Add swp_offset_pfn() to\nfetch PFN from swap entry\" added a check in swp_offset_pfn() for swap type [1]:\n\n kernel BUG at include/linux/swapops.h:117!\n CPU: 46 PID: 5245 Comm: EventManager_De Tainted: G S O L 6.0.0-dbg-DEV #2\n RIP: 0010:pfn_swap_entry_to_page+0x72/0xf0\n Code: c6 48 8b 36 48 83 fe ff 74 53 48 01 d1 48 83 c1 08 48 8b 09 f6\n c1 01 75 7b 66 90 48 89 c1 48 8b 09 f6 c1 01 74 74 5d c3 eb 9e <0f> 0b\n 48 ba ff ff ff ff 03 00 00 00 eb ae a9 ff 0f 00 00 75 13 48\n RSP: 0018:ffffa59e73fabb80 EFLAGS: 00010282\n RAX: 00000000ffffffe8 RBX: 0c00000000000000 RCX: ffffcd5440000000\n RDX: 1ffffffffff7a80a RSI: 0000000000000000 RDI: 0c0000000000042b\n RBP: ffffa59e73fabb80 R08: ffff9965ca6e8bb8 R09: 0000000000000000\n R10: ffffffffa5a2f62d R11: 0000030b372e9fff R12: ffff997b79db5738\n R13: 000000000000042b R14: 0c0000000000042b R15: 1ffffffffff7a80a\n FS: 00007f549d1bb700(0000) GS:ffff99d3cf680000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000440d035b3180 CR3: 0000002243176004 CR4: 00000000003706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n <TASK>\n change_pte_range+0x36e/0x880\n change_p4d_range+0x2e8/0x670\n change_protection_range+0x14e/0x2c0\n mprotect_fixup+0x1ee/0x330\n do_mprotect_pkey+0x34c/0x440\n __x64_sys_mprotect+0x1d/0x30\n\nIt triggers because pfn_swap_entry_to_page() could be called upon e.g. a\ngenuine swap entry.\n\nFix it by only calling it when it's a write migration entry where the page*\nis used.\n\n[1] https://lore.kernel.org/lkml/CAOUHufaVC2Za-p8m0aiHw6YkheDcrO-C3wRGixwDS32VTS+k1w@mail.gmail.com/"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/mprotect: solo hace referencia a la p\u00e1gina pfn de intercambio si coincide el tipo Yu Zhao inform\u00f3 un error despu\u00e9s de el commit \"mm/swap: Agregar swp_offset_pfn() para obtener PFN de la entrada de intercambio\" agreg\u00f3 una verificaci\u00f3n en swp_offset_pfn() para el tipo de intercambio [1]: \u00a1ERROR del kernel en include/linux/swapops.h:117! CPU: 46 PID: 5245 Com: EventManager_De Contaminado: GSOL 6.0.0-dbg-DEV #2 RIP: 0010:pfn_swap_entry_to_page+0x72/0xf0 C\u00f3digo: c6 48 8b 36 48 83 fe ff 74 53 48 01 d1 48 83 c1 08 48 8b 09 f6 c1 01 75 7b 66 90 48 89 c1 48 8b 09 f6 c1 01 74 74 5d c3 eb 9e &lt;0f&gt; 0b 48 ba ff ff ff ff 03 00 00 00 eb ae a9 ff 0f 00 00 75 13 48 RSP: 0018:ffffa59e73fabb80 EFLAGS: 00010282 RAX: 00000000ffffffe8 RBX: 0c00000000000000 RCX: ffffcd5440000000 RDX: 1ffffffffff7a80a RSI: 0000000000000000 RDI: 0c0000000000042b RBP: ffffa59e73fabb80 R08: ffff9965ca6e8bb8 R09: 0000000000000000 R10: ffffffffa5a2f62d R11: 0000030b372e9fff R12: ffff997b79db5738 R13: 000000000000042b R14: 0c0000000000042b R15: 1ffffffffff7a80a FS: 00007f549d1bb700(0000) GS:ffff99d3cf680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000440d035b3180 CR3: 0000002243176004 CR4: 00000000003706e0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: change_pte_range+0x36e/0x880 change_p4d_range+0x2e8/0x670 change_protection_range+0x14e/0x2c0 mprotect_fixup+0x1ee/0x330 do_mprotect_pkey+0x34c/0x440 __x64_sys_mprotect+0x1d/0x30 Se activa porque pfn_swap_entry_to_page() podr\u00eda invocarse, por ejemplo, en una entrada de intercambio genuina. Para solucionarlo, invoque solo cuando se trate de una entrada de migraci\u00f3n de escritura donde se use page*. [1] https://lore.kernel.org/lkml/CAOUHufaVC2Za-p8m0aiHw6YkheDcrO-C3wRGixwDS32VTS+k1w@mail.gmail.com/"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49993.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nloop: Check for overflow while configuring loop\n\nThe userspace can configure a loop using an ioctl call, wherein\na configuration of type loop_config is passed (see lo_ioctl()'s\ncase on line 1550 of drivers/block/loop.c). This proceeds to call\nloop_configure() which in turn calls loop_set_status_from_info()\n(see line 1050 of loop.c), passing &config->info which is of type\nloop_info64*. This function then sets the appropriate values, like\nthe offset.\n\nloop_device has lo_offset of type loff_t (see line 52 of loop.c),\nwhich is typdef-chained to long long, whereas loop_info64 has\nlo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).\n\nThe function directly copies offset from info to the device as\nfollows (See line 980 of loop.c):\n\tlo->lo_offset = info->lo_offset;\n\nThis results in an overflow, which triggers a warning in iomap_iter()\ndue to a call to iomap_iter_done() which has:\n\tWARN_ON_ONCE(iter->iomap.offset > iter->pos);\n\nThus, check for negative value during loop_set_status_from_info().\n\nBug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: loop: Comprobar si hay desbordamiento al configurar loop El espacio de usuario puede configurar un bucle mediante una llamada ioctl, en la que se pasa una configuraci\u00f3n de tipo loop_config (consulte el caso de lo_ioctl() en la l\u00ednea 1550 de drivers/block/loop.c). Esto procede a llamar a loop_configure() que a su vez llama a loop_set_status_from_info() (consulte la l\u00ednea 1050 de loop.c), pasando &amp;config-&gt;info que es de tipo loop_info64*. Esta funci\u00f3n luego establece los valores apropiados, como el desplazamiento. loop_device tiene lo_offset de tipo loff_t (consulte la l\u00ednea 52 de loop.c), que est\u00e1 encadenado por typdef a long long, mientras que loop_info64 tiene lo_offset de tipo __u64 (consulte la l\u00ednea 56 de include/uapi/linux/loop.h). La funci\u00f3n copia directamente el desplazamiento de info al dispositivo como se indica a continuaci\u00f3n (v\u00e9ase la l\u00ednea 980 de loop.c): lo-&gt;lo_offset = info-&gt;lo_offset; Esto genera un desbordamiento que genera una advertencia en iomap_iter() debido a una llamada a iomap_iter_done() que tiene: WARN_ON_ONCE(iter-&gt;iomap.offset &gt; iter-&gt;pos); Por lo tanto, se debe verificar si hay un valor negativo durante loop_set_status_from_info(). Informe de error: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49994.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbootmem: remove the vmemmap pages from kmemleak in put_page_bootmem\n\nThe vmemmap pages is marked by kmemleak when allocated from memblock. \nRemove it from kmemleak when freeing the page. Otherwise, when we reuse\nthe page, kmemleak may report such an error and then stop working.\n\n kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing)\n kmemleak: Kernel memory leak detector disabled\n kmemleak: Object 0xffff98fb6be00000 (size 335544320):\n kmemleak: comm \"swapper\", pid 0, jiffies 4294892296\n kmemleak: min_count = 0\n kmemleak: count = 0\n kmemleak: flags = 0x1\n kmemleak: checksum = 0\n kmemleak: backtrace:"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bootmem: eliminar las p\u00e1ginas vmemmap de kmemleak en put_page_bootmem. Las p\u00e1ginas vmemmap est\u00e1n marcadas por kmemleak cuando se asignan desde memblock. Elim\u00ednelas de kmemleak al liberar la p\u00e1gina. De lo contrario, al reutilizar la p\u00e1gina, kmemleak podr\u00eda informar dicho error y dejar de funcionar. kmemleak: No se puede insertar 0xffff98fb6eab3d40 en el \u00e1rbol de b\u00fasqueda de objetos (se superpone a los existentes) kmemleak: Detector de fugas de memoria del kernel deshabilitado kmemleak: Objeto 0xffff98fb6be00000 (tama\u00f1o 335544320): kmemleak: comm \"swapper\", pid 0, jiffies 4294892296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace:"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49995.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwriteback: avoid use-after-free after removing device\n\nWhen a disk is removed, bdi_unregister gets called to stop further\nwriteback and wait for associated delayed work to complete. However,\nwb_inode_writeback_end() may schedule bandwidth estimation dwork after\nthis has completed, which can result in the timer attempting to access the\njust freed bdi_writeback.\n\nFix this by checking if the bdi_writeback is alive, similar to when\nscheduling writeback work.\n\nSince this requires wb->work_lock, and wb_inode_writeback_end() may get\ncalled from interrupt, switch wb->work_lock to an irqsafe lock."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: writeback: evitar el Use-After-Free tras retirar un dispositivo. Al retirar un disco, se llama a bdi_unregister para detener la escritura diferida y esperar a que se complete el trabajo retrasado asociado. Sin embargo, wb_inode_writeback_end() puede programar la estimaci\u00f3n de ancho de banda dwork despu\u00e9s de que esto se haya completado, lo que puede provocar que el temporizador intente acceder al bdi_writeback reci\u00e9n liberado. Para solucionar esto, verifique si bdi_writeback est\u00e1 activo, de forma similar a cuando se programa la escritura diferida. Dado que esto requiere wb-&gt;work_lock y wb_inode_writeback_end() puede ser llamado desde una interrupci\u00f3n, cambie wb-&gt;work_lock a un bloqueo irqsafe."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49996.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix possible memory leak in btrfs_get_dev_args_from_path()\n\nIn btrfs_get_dev_args_from_path(), btrfs_get_bdev_and_sb() can fail if\nthe path is invalid. In this case, btrfs_get_dev_args_from_path()\nreturns directly without freeing args->uuid and args->fsid allocated\nbefore, which causes memory leak.\n\nTo fix these possible leaks, when btrfs_get_bdev_and_sb() fails,\nbtrfs_put_dev_args_from_path() is called to clean up the memory."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige una posible p\u00e9rdida de memoria en btrfs_get_dev_args_from_path(). En btrfs_get_dev_args_from_path(), btrfs_get_bdev_and_sb() puede fallar si la ruta no es v\u00e1lida. En este caso, btrfs_get_dev_args_from_path() retorna directamente sin liberar los argumentos args-&gt;uuid y args-&gt;fsid asignados previamente, lo que provoca una p\u00e9rdida de memoria. Para corregir estas posibles p\u00e9rdidas, cuando btrfs_get_bdev_and_sb() falla, se llama a btrfs_put_dev_args_from_path() para limpiar la memoria."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49997.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: lantiq_xrx200: restore buffer if memory allocation failed\n\nIn a situation where memory allocation fails, an invalid buffer address\nis stored. When this descriptor is used again, the system panics in the\nbuild_skb() function when accessing memory."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: lantiq_xrx200: restaurar el b\u00fafer si falla la asignaci\u00f3n de memoria. En caso de fallo en la asignaci\u00f3n de memoria, se almacena una direcci\u00f3n de b\u00fafer no v\u00e1lida. Al volver a utilizar este descriptor, el sistema entra en p\u00e1nico en la funci\u00f3n build_skb() al acceder a la memoria."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49998.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix locking in rxrpc's sendmsg\n\nFix three bugs in the rxrpc's sendmsg implementation:\n\n (1) rxrpc_new_client_call() should release the socket lock when returning\n an error from rxrpc_get_call_slot().\n\n (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex\n held in the event that we're interrupted by a signal whilst waiting\n for tx space on the socket or relocking the call mutex afterwards.\n\n Fix this by: (a) moving the unlock/lock of the call mutex up to\n rxrpc_send_data() such that the lock is not held around all of\n rxrpc_wait_for_tx_window*() and (b) indicating to higher callers\n whether we're return with the lock dropped. Note that this means\n recvmsg() will not block on this call whilst we're waiting.\n\n (3) After dropping and regaining the call mutex, rxrpc_send_data() needs\n to go and recheck the state of the tx_pending buffer and the\n tx_total_len check in case we raced with another sendmsg() on the same\n call.\n\nThinking on this some more, it might make sense to have different locks for\nsendmsg() and recvmsg(). There's probably no need to make recvmsg() wait\nfor sendmsg(). It does mean that recvmsg() can return MSG_EOR indicating\nthat a call is dead before a sendmsg() to that call returns - but that can\ncurrently happen anyway.\n\nWithout fix (2), something like the following can be induced:\n\n\tWARNING: bad unlock balance detected!\n\t5.16.0-rc6-syzkaller #0 Not tainted\n\t-------------------------------------\n\tsyz-executor011/3597 is trying to release lock (&call->user_mutex) at:\n\t[<ffffffff885163a3>] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748\n\tbut there are no more locks to release!\n\n\tother info that might help us debug this:\n\tno locks held by syz-executor011/3597.\n\t...\n\tCall Trace:\n\t <TASK>\n\t __dump_stack lib/dump_stack.c:88 [inline]\n\t dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n\t print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline]\n\t __lock_release kernel/locking/lockdep.c:5306 [inline]\n\t lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657\n\t __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900\n\t rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748\n\t rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561\n\t sock_sendmsg_nosec net/socket.c:704 [inline]\n\t sock_sendmsg+0xcf/0x120 net/socket.c:724\n\t ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409\n\t ___sys_sendmsg+0xf3/0x170 net/socket.c:2463\n\t __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492\n\t do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n\t do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n\t entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n[Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Arreglar el bloqueo en sendmsg de rxrpc Corrige tres errores en la implementaci\u00f3n de sendmsg de rxrpc: (1) rxrpc_new_client_call() deber\u00eda liberar el bloqueo del socket al devolver un error de rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() retornar\u00e1 sin el mutex de llamada retenido en caso de que seamos interrumpidos por una se\u00f1al mientras esperamos espacio de transmisi\u00f3n en el socket o volvemos a bloquear el mutex de llamada posteriormente. Corrige esto mediante: (a) mover el desbloqueo/bloqueo del mutex de llamada hasta rxrpc_send_data() de modo que el bloqueo no se mantenga alrededor de todo rxrpc_wait_for_tx_window*() y (b) indicar a los llamadores superiores si retornamos con el bloqueo eliminado. Tenga en cuenta que esto significa que recvmsg() no se bloquear\u00e1 en esta llamada mientras esperamos. (3) Despu\u00e9s de eliminar y recuperar el mutex de llamada, rxrpc_send_data() debe volver a verificar el estado del b\u00fafer tx_pending y la comprobaci\u00f3n de tx_total_len en caso de que hayamos utilizado otro sendmsg() en la misma llamada. Pens\u00e1ndolo bien, podr\u00eda tener sentido tener bloqueos diferentes para sendmsg() y recvmsg(). Probablemente no sea necesario que recvmsg() espere a sendmsg(). Esto significa que recvmsg() puede devolver MSG_EOR, lo que indica que una llamada est\u00e1 inactiva antes de que un sendmsg() a esa llamada regrese, pero eso puede ocurrir de todos modos. Sin la correcci\u00f3n (2), se puede inducir algo como lo siguiente: \u00a1ADVERTENCIA: se detect\u00f3 un saldo de desbloqueo incorrecto! 5.16.0-rc6-syzkaller #0 No contaminado ------------------------------------- syz-executor011/3597 est\u00e1 intentando liberar el bloqueo (&amp;call-&gt;user_mutex) en: [] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 \u00a1pero no hay m\u00e1s bloqueos para liberar! Otra informaci\u00f3n que podr\u00eda ayudarnos a depurar esto: syz-executor011/3597 no tiene bloqueos. ... Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en l\u00ednea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_unlock_imbalance_bug include/trace/events/lock.h:58 [en l\u00ednea] __lock_release kernel/locking/lockdep.c:5306 [en l\u00ednea] lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561 sock_sendmsg_nosec net/socket.c:704 [en l\u00ednea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [en l\u00ednea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae [Gracias a Hawkins Jiawei y Khalid Masum por sus intentos de solucionar este problema]"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-499xx/CVE-2022-49999.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix space cache corruption and potential double allocations\n\nWhen testing space_cache v2 on a large set of machines, we encountered a\nfew symptoms:\n\n1. \"unable to add free space :-17\" (EEXIST) errors.\n2. Missing free space info items, sometimes caught with a \"missing free\n space info for X\" error.\n3. Double-accounted space: ranges that were allocated in the extent tree\n and also marked as free in the free space tree, ranges that were\n marked as allocated twice in the extent tree, or ranges that were\n marked as free twice in the free space tree. If the latter made it\n onto disk, the next reboot would hit the BUG_ON() in\n add_new_free_space().\n4. On some hosts with no on-disk corruption or error messages, the\n in-memory space cache (dumped with drgn) disagreed with the free\n space tree.\n\nAll of these symptoms have the same underlying cause: a race between\ncaching the free space for a block group and returning free space to the\nin-memory space cache for pinned extents causes us to double-add a free\nrange to the space cache. This race exists when free space is cached\nfrom the free space tree (space_cache=v2) or the extent tree\n(nospace_cache, or space_cache=v1 if the cache needs to be regenerated).\nstruct btrfs_block_group::last_byte_to_unpin and struct\nbtrfs_block_group::progress are supposed to protect against this race,\nbut commit d0c2f4fa555e (\"btrfs: make concurrent fsyncs wait less when\nwaiting for a transaction commit\") subtly broke this by allowing\nmultiple transactions to be unpinning extents at the same time.\n\nSpecifically, the race is as follows:\n\n1. An extent is deleted from an uncached block group in transaction A.\n2. btrfs_commit_transaction() is called for transaction A.\n3. btrfs_run_delayed_refs() -> __btrfs_free_extent() runs the delayed\n ref for the deleted extent.\n4. __btrfs_free_extent() -> do_free_extent_accounting() ->\n add_to_free_space_tree() adds the deleted extent back to the free\n space tree.\n5. do_free_extent_accounting() -> btrfs_update_block_group() ->\n btrfs_cache_block_group() queues up the block group to get cached.\n block_group->progress is set to block_group->start.\n6. btrfs_commit_transaction() for transaction A calls\n switch_commit_roots(). It sets block_group->last_byte_to_unpin to\n block_group->progress, which is block_group->start because the block\n group hasn't been cached yet.\n7. The caching thread gets to our block group. Since the commit roots\n were already switched, load_free_space_tree() sees the deleted extent\n as free and adds it to the space cache. It finishes caching and sets\n block_group->progress to U64_MAX.\n8. btrfs_commit_transaction() advances transaction A to\n TRANS_STATE_SUPER_COMMITTED.\n9. fsync calls btrfs_commit_transaction() for transaction B. Since\n transaction A is already in TRANS_STATE_SUPER_COMMITTED and the\n commit is for fsync, it advances.\n10. btrfs_commit_transaction() for transaction B calls\n switch_commit_roots(). This time, the block group has already been\n cached, so it sets block_group->last_byte_to_unpin to U64_MAX.\n11. btrfs_commit_transaction() for transaction A calls\n btrfs_finish_extent_commit(), which calls unpin_extent_range() for\n the deleted extent. It sees last_byte_to_unpin set to U64_MAX (by\n transaction B!), so it adds the deleted extent to the space cache\n again!\n\nThis explains all of our symptoms above:\n\n* If the sequence of events is exactly as described above, when the free\n space is re-added in step 11, it will fail with EEXIST.\n* If another thread reallocates the deleted extent in between steps 7\n and 11, then step 11 will silently re-add that space to the space\n cache as free even though it is actually allocated. Then, if that\n space is allocated *again*, the free space tree will be corrupted\n (namely, the wrong item will be deleted).\n* If we don't catch this free space tree corr\n---truncated---"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: correcci\u00f3n de corrupci\u00f3n de cach\u00e9 de espacio y posibles asignaciones dobles. Al probar space_cache v2 en un conjunto grande de m\u00e1quinas, encontramos algunos s\u00edntomas: 1. Errores \"no se puede agregar espacio libre :-17\" (EEXIST). 2. Falta de informaci\u00f3n de espacio libre, a veces detectados con el error \"falta informaci\u00f3n de espacio libre para X\". 3. Espacio contabilizado dos veces: rangos asignados en el \u00e1rbol de extensiones y marcados como libres en dicho \u00e1rbol, rangos marcados como asignados dos veces en el \u00e1rbol de extensiones o rangos marcados como libres dos veces en dicho \u00e1rbol. Si estos \u00faltimos se almacenaban en el disco, el siguiente reinicio generar\u00eda el error BUG_ON() en add_new_free_space(). 4. En algunos hosts sin corrupci\u00f3n en disco ni mensajes de error, la cach\u00e9 de espacio en memoria (volcada con drgn) no coincid\u00eda con el \u00e1rbol de espacio libre. Todos estos s\u00edntomas tienen la misma causa subyacente: una competencia entre el almacenamiento en cach\u00e9 del espacio libre de un grupo de bloques y su devoluci\u00f3n a la cach\u00e9 de espacio en memoria para las extensiones fijadas provoca la duplicaci\u00f3n de un rango libre en la cach\u00e9 de espacio. Esta competencia se produce cuando se almacena en cach\u00e9 el espacio libre del \u00e1rbol de espacio libre (space_cache=v2) o del \u00e1rbol de extensiones (nospace_cache, o space_cache=v1 si es necesario regenerar la cach\u00e9). Se supone que struct btrfs_block_group::last_byte_to_unpin y struct btrfs_block_group::progress protegen contra esta competencia, pero el commit d0c2f4fa555e (\"btrfs: hacer que las sincronizaciones simult\u00e1neas esperen menos al esperar el commit de una transacci\u00f3n\") interrumpi\u00f3 esto sutilmente al permitir que varias transacciones desanclaran extensiones simult\u00e1neamente. Espec\u00edficamente, la ejecuci\u00f3n es la siguiente: 1. Se elimina una extensi\u00f3n de un grupo de bloques no almacenados en cach\u00e9 en la transacci\u00f3n A. 2. Se llama a btrfs_commit_transaction() para la transacci\u00f3n A. 3. btrfs_run_delayed_refs() -&gt; __btrfs_free_extent() ejecuta la referencia retrasada para la extensi\u00f3n eliminada. 4. __btrfs_free_extent() -&gt; do_free_extent_accounting() -&gt; add_to_free_space_tree() agrega la extensi\u00f3n eliminada nuevamente al \u00e1rbol de espacio libre. 5. do_free_extent_accounting() -&gt; btrfs_update_block_group() -&gt; btrfs_cache_block_group() pone en cola el grupo de bloques para almacenar en cach\u00e9. block_group-&gt;progress se establece en block_group-&gt;start. 6. btrfs_commit_transaction() para la transacci\u00f3n A llama a switch_commit_roots(). Establece block_group-&gt;last_byte_to_unpin en block_group-&gt;progress, que es block_group-&gt;start porque el grupo de bloques a\u00fan no se ha almacenado en cach\u00e9. 7. El hilo de cach\u00e9 accede a nuestro grupo de bloques. Dado que las ra\u00edces de las confirmaciones ya se han cambiado, load_free_space_tree() detecta la extensi\u00f3n eliminada como libre y la a\u00f1ade a la cach\u00e9 de espacio. Finaliza el almacenamiento en cach\u00e9 y establece block_group-&gt;progress en U64_MAX. 8. btrfs_commit_transaction() avanza la transacci\u00f3n A a TRANS_STATE_SUPER_COMMITTED. 9. fsync llama a btrfs_commit_transaction() para la transacci\u00f3n B. Dado que la transacci\u00f3n A ya est\u00e1 en TRANS_STATE_SUPER_COMMITTED y el commit es para fsync, avanza. 10. btrfs_commit_transaction() para la transacci\u00f3n B llama a switch_commit_roots(). Esta vez, el grupo de bloques ya se ha almacenado en cach\u00e9, por lo que establece block_group-&gt;last_byte_to_unpin en U64_MAX. 11. btrfs_commit_transaction() para la transacci\u00f3n A llama a btrfs_finish_extent_commit(), que llama a unpin_extent_range() para la extensi\u00f3n eliminada. Ve que last_byte_to_unpin est\u00e1 establecido en U64_MAX (\u00a1por la transacci\u00f3n B!), por lo que vuelve a a\u00f1adir la extensi\u00f3n eliminada a la cach\u00e9 de espacio. Esto explica todos nuestros s\u00edntomas anteriores: * Si la secuencia de eventos es exactamente la descrita anteriormente, cuando se vuelve a a\u00f1adir el espacio libre en el paso 11, fallar\u00e1 con EEXIST. * ---truncado---"
}
],
"metrics": {},

12
CVE-2022/CVE-2022-49xx/CVE-2022-4964.json
View File

@ -2,7 +2,7 @@
"id": "CVE-2022-4964",
"sourceIdentifier": "security@ubuntu.com",
"published": "2024-01-24T01:15:07.977",
"lastModified": "2024-11-21T07:36:20.560",
"lastModified": "2025-06-20T20:15:23.290",
"vulnStatus": "Modified",
"cveTags": [],
"descriptions": [
@ -69,6 +69,16 @@
"value": "CWE-276"
}
]
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-276"
}
]
}
],
"configurations": [

4
CVE-2022/CVE-2022-500xx/CVE-2022-50000.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: flowtable: fix stuck flows on cleanup due to pending work\n\nTo clear the flow table on flow table free, the following sequence\nnormally happens in order:\n\n 1) gc_step work is stopped to disable any further stats/del requests.\n 2) All flow table entries are set to teardown state.\n 3) Run gc_step which will queue HW del work for each flow table entry.\n 4) Waiting for the above del work to finish (flush).\n 5) Run gc_step again, deleting all entries from the flow table.\n 6) Flow table is freed.\n\nBut if a flow table entry already has pending HW stats or HW add work\nstep 3 will not queue HW del work (it will be skipped), step 4 will wait\nfor the pending add/stats to finish, and step 5 will queue HW del work\nwhich might execute after freeing of the flow table.\n\nTo fix the above, this patch flushes the pending work, then it sets the\nteardown flag to all flows in the flowtable and it forces a garbage\ncollector run to queue work to remove the flows from hardware, then it\nflushes this new pending work and (finally) it forces another garbage\ncollector run to remove the entry from the software flowtable.\n\nStack trace:\n[47773.882335] BUG: KASAN: use-after-free in down_read+0x99/0x460\n[47773.883634] Write of size 8 at addr ffff888103b45aa8 by task kworker/u20:6/543704\n[47773.885634] CPU: 3 PID: 543704 Comm: kworker/u20:6 Not tainted 5.12.0-rc7+ #2\n[47773.886745] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)\n[47773.888438] Workqueue: nf_ft_offload_del flow_offload_work_handler [nf_flow_table]\n[47773.889727] Call Trace:\n[47773.890214] dump_stack+0xbb/0x107\n[47773.890818] print_address_description.constprop.0+0x18/0x140\n[47773.892990] kasan_report.cold+0x7c/0xd8\n[47773.894459] kasan_check_range+0x145/0x1a0\n[47773.895174] down_read+0x99/0x460\n[47773.899706] nf_flow_offload_tuple+0x24f/0x3c0 [nf_flow_table]\n[47773.907137] flow_offload_work_handler+0x72d/0xbe0 [nf_flow_table]\n[47773.913372] process_one_work+0x8ac/0x14e0\n[47773.921325]\n[47773.921325] Allocated by task 592159:\n[47773.922031] kasan_save_stack+0x1b/0x40\n[47773.922730] __kasan_kmalloc+0x7a/0x90\n[47773.923411] tcf_ct_flow_table_get+0x3cb/0x1230 [act_ct]\n[47773.924363] tcf_ct_init+0x71c/0x1156 [act_ct]\n[47773.925207] tcf_action_init_1+0x45b/0x700\n[47773.925987] tcf_action_init+0x453/0x6b0\n[47773.926692] tcf_exts_validate+0x3d0/0x600\n[47773.927419] fl_change+0x757/0x4a51 [cls_flower]\n[47773.928227] tc_new_tfilter+0x89a/0x2070\n[47773.936652]\n[47773.936652] Freed by task 543704:\n[47773.937303] kasan_save_stack+0x1b/0x40\n[47773.938039] kasan_set_track+0x1c/0x30\n[47773.938731] kasan_set_free_info+0x20/0x30\n[47773.939467] __kasan_slab_free+0xe7/0x120\n[47773.940194] slab_free_freelist_hook+0x86/0x190\n[47773.941038] kfree+0xce/0x3a0\n[47773.941644] tcf_ct_flow_table_cleanup_work\n\nOriginal patch description and stack trace by Paul Blakey."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: flowtable: arreglo de flujos atascados en la limpieza debido a trabajo pendiente Para limpiar la tabla de flujo cuando est\u00e1 libre, normalmente ocurre la siguiente secuencia en orden: 1) Se detiene el trabajo de gc_step para deshabilitar cualquier solicitud de estad\u00edsticas/del. 2) Todas las entradas de la tabla de flujo se establecen en estado de desmontaje. 3) Se ejecuta gc_step, que pondr\u00e1 en cola el trabajo de del de HW para cada entrada de la tabla de flujo. 4) Se espera a que finalice el trabajo del del anterior (vaciado). 5) Se vuelve a ejecutar gc_step, eliminando todas las entradas de la tabla de flujo. 6) Se libera la tabla de flujo. Pero si una entrada de la tabla de flujo ya tiene estad\u00edsticas de HW pendientes o trabajo de adici\u00f3n de HW, el paso 3 no pondr\u00e1 en cola el trabajo de del de HW (se omitir\u00e1), el paso 4 esperar\u00e1 a que finalicen las adiciones/estad\u00edsticas pendientes y el paso 5 pondr\u00e1 en cola el trabajo de del de HW que podr\u00eda ejecutarse despu\u00e9s de liberar la tabla de flujo. Para solucionar lo anterior, este parche limpia el trabajo pendiente, luego establece el indicador de desmontaje en todos los flujos en la tabla de flujo y fuerza la ejecuci\u00f3n de un recolector de basura para poner en cola el trabajo para eliminar los flujos del hardware, luego limpia este nuevo trabajo pendiente y (finalmente) fuerza la ejecuci\u00f3n de otro recolector de basura para eliminar la entrada de la tabla de flujo del software. Rastreo de pila: [47773.882335] ERROR: KASAN: Use-After-Free en down_read+0x99/0x460 [47773.883634] Escritura de tama\u00f1o 8 en la direcci\u00f3n ffff888103b45aa8 por la tarea kworker/u20:6/543704 [47773.885634] CPU: 3 PID: 543704 Comm: kworker/u20:6 No contaminado 5.12.0-rc7+ #2 [47773.886745] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009) [47773.888438] Cola de trabajo: nf_ft_offload_del flow_offload_work_handler [nf_flow_table] [47773.889727] Rastreo de llamadas: [47773.890214] dump_stack+0xbb/0x107 [47773.890818] print_address_description.constprop.0+0x18/0x140 [47773.892990] kasan_report.cold+0x7c/0xd8 [47773.894459] kasan_check_range+0x145/0x1a0 [47773.895174] down_read+0x99/0x460 [47773.899706] nf_flow_offload_tuple+0x24f/0x3c0 [nf_flow_table] [47773.907137] flow_offload_work_handler+0x72d/0xbe0 [nf_flow_table] [47773.913372] process_one_work+0x8ac/0x14e0 [47773.921325] [47773.921325] Allocated by task 592159: [47773.922031] kasan_save_stack+0x1b/0x40 [47773.922730] __kasan_kmalloc+0x7a/0x90 [47773.923411] tcf_ct_flow_table_get+0x3cb/0x1230 [act_ct] [47773.924363] tcf_ct_init+0x71c/0x1156 [act_ct] [47773.925207] tcf_action_init_1+0x45b/0x700 [47773.925987] tcf_action_init+0x453/0x6b0 [47773.926692] tcf_exts_validate+0x3d0/0x600 [47773.927419] fl_change+0x757/0x4a51 [cls_flower] [47773.928227] tc_new_tfilter+0x89a/0x2070 [47773.936652] [47773.936652] Freed by task 543704: [47773.937303] kasan_save_stack+0x1b/0x40 [47773.938039] kasan_set_track+0x1c/0x30 [47773.938731] kasan_set_free_info+0x20/0x30 [47773.939467] __kasan_slab_free+0xe7/0x120 [47773.940194] slab_free_freelist_hook+0x86/0x190 [47773.941038] kfree+0xce/0x3a0 [47773.941644] tcf_ct_flow_table_cleanup_work Descripci\u00f3n del parche original y seguimiento de la pila por Paul Blakey."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-500xx/CVE-2022-50001.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_tproxy: restrict to prerouting hook\n\nTPROXY is only allowed from prerouting, but nft_tproxy doesn't check this.\nThis fixes a crash (null dereference) when using tproxy from e.g. output."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_tproxy: restricci\u00f3n al gancho de preenrutamiento. TPROXY solo se permite desde el preenrutamiento, pero nft_tproxy no lo comprueba. Esto corrige un fallo (desreferencia nula) al usar tproxy desde la salida, por ejemplo."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-500xx/CVE-2022-50002.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: LAG, fix logic over MLX5_LAG_FLAG_NDEVS_READY\n\nOnly set MLX5_LAG_FLAG_NDEVS_READY if both netdevices are registered.\nDoing so guarantees that both ldev->pf[MLX5_LAG_P0].dev and\nldev->pf[MLX5_LAG_P1].dev have valid pointers when\nMLX5_LAG_FLAG_NDEVS_READY is set.\n\nThe core issue is asymmetry in setting MLX5_LAG_FLAG_NDEVS_READY and\nclearing it. Setting it is done wrongly when both\nldev->pf[MLX5_LAG_P0].dev and ldev->pf[MLX5_LAG_P1].dev are set;\nclearing it is done right when either of ldev->pf[i].netdev is cleared.\n\nConsider the following scenario:\n1. PF0 loads and sets ldev->pf[MLX5_LAG_P0].dev to a valid pointer\n2. PF1 loads and sets both ldev->pf[MLX5_LAG_P1].dev and\n ldev->pf[MLX5_LAG_P1].netdev with valid pointers. This results in\n MLX5_LAG_FLAG_NDEVS_READY is set.\n3. PF0 is unloaded before setting dev->pf[MLX5_LAG_P0].netdev.\n MLX5_LAG_FLAG_NDEVS_READY remains set.\n\nFurther execution of mlx5_do_bond() will result in null pointer\ndereference when calling mlx5_lag_is_multipath()\n\nThis patch fixes the following call trace actually encountered:\n\n[ 1293.475195] BUG: kernel NULL pointer dereference, address: 00000000000009a8\n[ 1293.478756] #PF: supervisor read access in kernel mode\n[ 1293.481320] #PF: error_code(0x0000) - not-present page\n[ 1293.483686] PGD 0 P4D 0\n[ 1293.484434] Oops: 0000 [#1] SMP PTI\n[ 1293.485377] CPU: 1 PID: 23690 Comm: kworker/u16:2 Not tainted 5.18.0-rc5_for_upstream_min_debug_2022_05_05_10_13 #1\n[ 1293.488039] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[ 1293.490836] Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core]\n[ 1293.492448] RIP: 0010:mlx5_lag_is_multipath+0x5/0x50 [mlx5_core]\n[ 1293.494044] Code: e8 70 40 ff e0 48 8b 14 24 48 83 05 5c 1a 1b 00 01 e9 19 ff ff ff 48 83 05 47 1a 1b 00 01 eb d7 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 87 a8 09 00 00 48 85 c0 74 26 48 83 05 a7 1b 1b 00 01 41 b8\n[ 1293.498673] RSP: 0018:ffff88811b2fbe40 EFLAGS: 00010202\n[ 1293.500152] RAX: ffff88818a94e1c0 RBX: ffff888165eca6c0 RCX: 0000000000000000\n[ 1293.501841] RDX: 0000000000000001 RSI: ffff88818a94e1c0 RDI: 0000000000000000\n[ 1293.503585] RBP: 0000000000000000 R08: ffff888119886740 R09: ffff888165eca73c\n[ 1293.505286] R10: 0000000000000018 R11: 0000000000000018 R12: ffff88818a94e1c0\n[ 1293.506979] R13: ffff888112729800 R14: 0000000000000000 R15: ffff888112729858\n[ 1293.508753] FS: 0000000000000000(0000) GS:ffff88852cc40000(0000) knlGS:0000000000000000\n[ 1293.510782] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1293.512265] CR2: 00000000000009a8 CR3: 00000001032d4002 CR4: 0000000000370ea0\n[ 1293.514001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 1293.515806] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: LAG, corregir la l\u00f3gica sobre MLX5_LAG_FLAG_NDEVS_READY Solo establezca MLX5_LAG_FLAG_NDEVS_READY si ambos dispositivos de red est\u00e1n registrados. Hacerlo garantiza que tanto ldev-&gt;pf[MLX5_LAG_P0].dev como ldev-&gt;pf[MLX5_LAG_P1].dev tengan punteros v\u00e1lidos cuando MLX5_LAG_FLAG_NDEVS_READY est\u00e9 establecido. El problema principal es la asimetr\u00eda en la configuraci\u00f3n de MLX5_LAG_FLAG_NDEVS_READY y su borrado. La configuraci\u00f3n se realiza incorrectamente cuando tanto ldev-&gt;pf[MLX5_LAG_P0].dev como ldev-&gt;pf[MLX5_LAG_P1].dev est\u00e1n establecidos; Se borra correctamente cuando se borra ldev-&gt;pf[i].netdev. Considere el siguiente escenario: 1. PF0 carga y asigna un puntero v\u00e1lido a ldev-&gt;pf[MLX5_LAG_P0].dev. 2. PF1 carga y asigna punteros v\u00e1lidos a ldev-&gt;pf[MLX5_LAG_P1].dev y ldev-&gt;pf[MLX5_LAG_P1].netdev. Esto da como resultado que MLX5_LAG_FLAG_NDEVS_READY se configure. 3. PF0 se descarga antes de asignar dev-&gt;pf[MLX5_LAG_P0].netdev. MLX5_LAG_FLAG_NDEVS_READY permanece configurado. La ejecuci\u00f3n posterior de mlx5_do_bond() dar\u00e1 como resultado una desreferencia de puntero nulo al llamar a mlx5_lag_is_multipath(). Este parche corrige el siguiente seguimiento de llamada encontrado: [ 1293.475195] ERROR: desreferencia de puntero NULL del kernel, direcci\u00f3n: 00000000000009a8 [ 1293.478756] #PF: acceso de lectura del supervisor en modo kernel [ 1293.481320] #PF: error_code(0x0000) - p\u00e1gina no presente [ 1293.483686] PGD 0 P4D 0 [ 1293.484434] Oops: 0000 [#1] SMP PTI [ 1293.485377] CPU: 1 PID: 23690 Comm: kworker/u16:2 No contaminado 5.18.0-rc5_for_upstream_min_debug_2022_05_05_10_13 #1 [ 1293.488039] Nombre del hardware: PC est\u00e1ndar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 [ 1293.490836] Cola de trabajo: mlx5_lag mlx5_do_bond_work [mlx5_core] [ 1293.492448] RIP: 0010:mlx5_lag_is_multipath+0x5/0x50 [mlx5_core] [ 1293.494044] C\u00f3digo: e8 70 40 ff e0 48 8b 14 24 48 83 05 5c 1a 1b 00 01 e9 19 ff ff ff 48 83 05 47 1a 1b 00 01 eb d7 0f 1f 44 00 00 0f 1f 44 00 00 &lt;48&gt; 8b 87 a8 09 00 00 48 85 c0 74 26 48 83 05 a7 1b 1b 00 01 41 b8 [ 1293.498673] RSP: 0018:ffff88811b2fbe40 EFLAGS: 00010202 [ 1293.500152] RAX: ffff88818a94e1c0 RBX: ffff888165eca6c0 RCX: 0000000000000000 [ 1293.501841] RDX: 0000000000000001 RSI: ffff88818a94e1c0 RDI: 0000000000000000 [ 1293.503585] RBP: 0000000000000000 R08: ffff888119886740 R09: ffff888165eca73c [ 1293.505286] R10: 0000000000000018 R11: 0000000000000018 R12: ffff88818a94e1c0 [ 1293.506979] R13: ffff888112729800 R14: 0000000000000000 R15: ffff888112729858 [ 1293.508753] FS: 000000000000000(0000) GS:ffff88852cc40000(0000) knlGS:0000000000000000 [ 1293.510782] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [ 1293.512265] CR2: 00000000000009a8 CR3: 00000001032d4002 CR4: 0000000000370ea0 [ 1293.514001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1293.515806] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-500xx/CVE-2022-50003.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: xsk: prohibit usage of non-balanced queue id\n\nFix the following scenario:\n1. ethtool -L $IFACE rx 8 tx 96\n2. xdpsock -q 10 -t -z\n\nAbove refers to a case where user would like to attach XSK socket in\ntxonly mode at a queue id that does not have a corresponding Rx queue.\nAt this moment ice's XSK logic is tightly bound to act on a \"queue pair\",\ne.g. both Tx and Rx queues at a given queue id are disabled/enabled and\nboth of them will get XSK pool assigned, which is broken for the presented\nqueue configuration. This results in the splat included at the bottom,\nwhich is basically an OOB access to Rx ring array.\n\nTo fix this, allow using the ids only in scope of \"combined\" queues\nreported by ethtool. However, logic should be rewritten to allow such\nconfigurations later on, which would end up as a complete rewrite of the\ncontrol path, so let us go with this temporary fix.\n\n[420160.558008] BUG: kernel NULL pointer dereference, address: 0000000000000082\n[420160.566359] #PF: supervisor read access in kernel mode\n[420160.572657] #PF: error_code(0x0000) - not-present page\n[420160.579002] PGD 0 P4D 0\n[420160.582756] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[420160.588396] CPU: 10 PID: 21232 Comm: xdpsock Tainted: G OE 5.19.0-rc7+ #10\n[420160.597893] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019\n[420160.609894] RIP: 0010:ice_xsk_pool_setup+0x44/0x7d0 [ice]\n[420160.616968] Code: f3 48 83 ec 40 48 8b 4f 20 48 8b 3f 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 8d 04 ed 00 00 00 00 48 01 c1 48 8b 11 <0f> b7 92 82 00 00 00 48 85 d2 0f 84 2d 75 00 00 48 8d 72 ff 48 85\n[420160.639421] RSP: 0018:ffffc9002d2afd48 EFLAGS: 00010282\n[420160.646650] RAX: 0000000000000050 RBX: ffff88811d8bdd00 RCX: ffff888112c14ff8\n[420160.655893] RDX: 0000000000000000 RSI: ffff88811d8bdd00 RDI: ffff888109861000\n[420160.665166] RBP: 000000000000000a R08: 000000000000000a R09: 0000000000000000\n[420160.674493] R10: 000000000000889f R11: 0000000000000000 R12: 000000000000000a\n[420160.683833] R13: 000000000000000a R14: 0000000000000000 R15: ffff888117611828\n[420160.693211] FS: 00007fa869fc1f80(0000) GS:ffff8897e0880000(0000) knlGS:0000000000000000\n[420160.703645] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[420160.711783] CR2: 0000000000000082 CR3: 00000001d076c001 CR4: 00000000007706e0\n[420160.721399] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[420160.731045] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[420160.740707] PKRU: 55555554\n[420160.745960] Call Trace:\n[420160.750962] <TASK>\n[420160.755597] ? kmalloc_large_node+0x79/0x90\n[420160.762703] ? __kmalloc_node+0x3f5/0x4b0\n[420160.769341] xp_assign_dev+0xfd/0x210\n[420160.775661] ? shmem_file_read_iter+0x29a/0x420\n[420160.782896] xsk_bind+0x152/0x490\n[420160.788943] __sys_bind+0xd0/0x100\n[420160.795097] ? exit_to_user_mode_prepare+0x20/0x120\n[420160.802801] __x64_sys_bind+0x16/0x20\n[420160.809298] do_syscall_64+0x38/0x90\n[420160.815741] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[420160.823731] RIP: 0033:0x7fa86a0dd2fb\n[420160.830264] Code: c3 66 0f 1f 44 00 00 48 8b 15 69 8b 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bc 0f 1f 44 00 00 f3 0f 1e fa b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 8b 0c 00 f7 d8 64 89 01 48\n[420160.855410] RSP: 002b:00007ffc1146f618 EFLAGS: 00000246 ORIG_RAX: 0000000000000031\n[420160.866366] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa86a0dd2fb\n[420160.876957] RDX: 0000000000000010 RSI: 00007ffc1146f680 RDI: 0000000000000003\n[420160.887604] RBP: 000055d7113a0520 R08: 00007fa868fb8000 R09: 0000000080000000\n[420160.898293] R10: 0000000000008001 R11: 0000000000000246 R12: 000055d7113a04e0\n[420160.909038] R13: 000055d7113a0320 R14: 000000000000000a R15: 0000000000000000\n[420160.919817] </TASK>\n[420160.925659] Modules linked in: ice(OE) af_packet binfmt_misc\n---truncated---"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: xsk: prohibir el uso de un id de cola no balanceado Corrija el siguiente escenario: 1. ethtool -L $IFACE rx 8 tx 96 2. xdpsock -q 10 -t -z Lo anterior se refiere a un caso en el que el usuario desea adjuntar un socket XSK en modo txonly a un id de cola que no tiene una cola Rx correspondiente. En este momento, la l\u00f3gica XSK de ice est\u00e1 estrechamente ligada a actuar en un \"par de colas\", por ejemplo, las colas Tx y Rx en un id de cola dado est\u00e1n deshabilitadas/habilitadas y a ambas se les asignar\u00e1 un grupo XSK, lo cual no funciona para la configuraci\u00f3n de cola presentada. Esto da como resultado el splat incluido en la parte inferior, que es b\u00e1sicamente un acceso OOB a la matriz de anillo Rx. Para solucionar esto, permita el uso de los id solo en el \u00e1mbito de las colas \"combinadas\" reportadas por ethtool. Sin embargo, la l\u00f3gica debe reescribirse para permitir tales configuraciones m\u00e1s adelante, lo que terminar\u00eda como una reescritura completa de la ruta de control, as\u00ed que sigamos con esta soluci\u00f3n temporal. [420160.558008] ERROR: desreferencia de puntero NULL del kernel, direcci\u00f3n: 0000000000000082 [420160.566359] #PF: acceso de lectura del supervisor en modo kernel [420160.572657] #PF: error_code(0x0000) - p\u00e1gina no presente [420160.579002] PGD 0 P4D 0 [420160.582756] Oops: 0000 [#1] PREEMPT SMP NOPTI [420160.588396] CPU: 10 PID: 21232 Comm: xdpsock Tainted: G OE 5.19.0-rc7+ #10 [420160.597893] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 19/03/2019 [420160.609894] RIP: 0010:ice_xsk_pool_setup+0x44/0x7d0 [ice] [420160.616968] C\u00f3digo: f3 48 83 ec 40 48 8b 4f 20 48 8b 3f 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 8d 04 ed 00 00 00 00 48 01 c1 48 8b 11 &lt;0f&gt; b7 92 82 00 00 00 48 85 d2 0f 84 2d 75 00 00 48 8d 72 ff 48 85 [420160.639421] RSP: 0018:ffffc9002d2afd48 EFLAGS: 00010282 [420160.646650] RAX: 0000000000000050 RBX: ffff88811d8bdd00 RCX: ffff888112c14ff8 [420160.655893] RDX: 000000000000000 RSI: ffff88811d8bdd00 RDI: ffff888109861000 [420160.665166] RBP: 000000000000000a R08: 000000000000000a R09: 0000000000000000 [420160.674493] R10: 000000000000889f R11: 0000000000000000 R12: 000000000000000a [420160.683833] R13: 00000000000000a R14: 0000000000000000 R15: ffff888117611828 [420160.693211] FS: 00007fa869fc1f80(0000) GS:ffff8897e0880000(0000) knlGS:0000000000000000 [420160.703645] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [420160.711783] CR2: 000000000000082 CR3: 00000001d076c001 CR4: 00000000007706e0 [420160.721399] DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [420160.731045] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [420160.740707] PKRU: 55555554 [420160.745960] Rastreo de llamadas: [420160.750962] [420160.755597] ? kmalloc_large_node+0x79/0x90 [420160.762703] ? __kmalloc_node+0x3f5/0x4b0 [420160.769341] xp_assign_dev+0xfd/0x210 [420160.775661] ? shmem_file_read_iter+0x29a/0x420 [420160.782896] xsk_bind+0x152/0x490 [420160.788943] __sys_bind+0xd0/0x100 [420160.795097] ? exit_to_user_mode_prepare+0x20/0x120 [420160.802801] __x64_sys_bind+0x16/0x20 [420160.809298] do_syscall_64+0x38/0x90 [420160.815741] entry_SYSCALL_64_after_hwframe+0x63/0xcd [420160.823731] RIP: 0033:0x7fa86a0dd2fb [420160.830264] Code: c3 66 0f 1f 44 00 00 48 8b 15 69 8b 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bc 0f 1f 44 00 00 f3 0f 1e fa b8 31 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 8b 0c 00 f7 d8 64 89 01 48 [420160.855410] RSP: 002b:00007ffc1146f618 EFLAGS: 00000246 ORIG_RAX: 0000000000000031 [420160.866366] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa86a0dd2fb [420160.876957] RDX: 0000000000000010 RSI: 00007ffc1146f680 RDI: 0000000000000003 [420160.887604] RBP: 000055d7113a0520 R08: 00007fa868fb8000 R09: 0000000080000000 [420160.898293] R10: 0000000000008001 R11: 0000000000000246 R12: 000055d7113a04e0 [420160.909038] R13: 000055d7113a0320 R14: 000000000000000a R15: 0000000000000000 [420160.91 ---truncado---"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-500xx/CVE-2022-50004.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: policy: fix metadata dst->dev xmit null pointer dereference\n\nWhen we try to transmit an skb with metadata_dst attached (i.e. dst->dev\n== NULL) through xfrm interface we can hit a null pointer dereference[1]\nin xfrmi_xmit2() -> xfrm_lookup_with_ifid() due to the check for a\nloopback skb device when there's no policy which dereferences dst->dev\nunconditionally. Not having dst->dev can be interepreted as it not being\na loopback device, so just add a check for a null dst_orig->dev.\n\nWith this fix xfrm interface's Tx error counters go up as usual.\n\n[1] net-next calltrace captured via netconsole:\n BUG: kernel NULL pointer dereference, address: 00000000000000c0\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP\n CPU: 1 PID: 7231 Comm: ping Kdump: loaded Not tainted 5.19.0+ #24\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014\n RIP: 0010:xfrm_lookup_with_ifid+0x5eb/0xa60\n Code: 8d 74 24 38 e8 26 a4 37 00 48 89 c1 e9 12 fc ff ff 49 63 ed 41 83 fd be 0f 85 be 01 00 00 41 be ff ff ff ff 45 31 ed 48 8b 03 <f6> 80 c0 00 00 00 08 75 0f 41 80 bc 24 19 0d 00 00 01 0f 84 1e 02\n RSP: 0018:ffffb0db82c679f0 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: ffffd0db7fcad430 RCX: ffffb0db82c67a10\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb0db82c67a80\n RBP: ffffb0db82c67a80 R08: ffffb0db82c67a14 R09: 0000000000000000\n R10: 0000000000000000 R11: ffff8fa449667dc8 R12: ffffffff966db880\n R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000\n FS: 00007ff35c83f000(0000) GS:ffff8fa478480000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00000000000000c0 CR3: 000000001ebb7000 CR4: 0000000000350ee0\n Call Trace:\n <TASK>\n xfrmi_xmit+0xde/0x460\n ? tcf_bpf_act+0x13d/0x2a0\n dev_hard_start_xmit+0x72/0x1e0\n __dev_queue_xmit+0x251/0xd30\n ip_finish_output2+0x140/0x550\n ip_push_pending_frames+0x56/0x80\n raw_sendmsg+0x663/0x10a0\n ? try_charge_memcg+0x3fd/0x7a0\n ? __mod_memcg_lruvec_state+0x93/0x110\n ? sock_sendmsg+0x30/0x40\n sock_sendmsg+0x30/0x40\n __sys_sendto+0xeb/0x130\n ? handle_mm_fault+0xae/0x280\n ? do_user_addr_fault+0x1e7/0x680\n ? kvm_read_and_reset_apf_flags+0x3b/0x50\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x34/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n RIP: 0033:0x7ff35cac1366\n Code: eb 0b 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 72 c3 90 55 48 83 ec 30 44 89 4c 24 2c 4c 89\n RSP: 002b:00007fff738e4028 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\n RAX: ffffffffffffffda RBX: 00007fff738e57b0 RCX: 00007ff35cac1366\n RDX: 0000000000000040 RSI: 0000557164e4b450 RDI: 0000000000000003\n RBP: 0000557164e4b450 R08: 00007fff738e7a2c R09: 0000000000000010\n R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040\n R13: 00007fff738e5770 R14: 00007fff738e4030 R15: 0000001d00000001\n </TASK>\n Modules linked in: netconsole veth br_netfilter bridge bonding virtio_net [last unloaded: netconsole]\n CR2: 00000000000000c0"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: pol\u00edtica: corregir la desreferencia de puntero nulo de metadatos dst-&gt;dev xmit Cuando intentamos transmitir un skb con metadata_dst adjunto (es decir, dst-&gt;dev == NULL) a trav\u00e9s de la interfaz xfrm, podemos alcanzar una desreferencia de puntero nulo[1] en xfrmi_xmit2() -&gt; xfrm_lookup_with_ifid() debido a la comprobaci\u00f3n de un dispositivo skb de bucle invertido cuando no hay ninguna pol\u00edtica que desreferencia dst-&gt;dev incondicionalmente. No tener dst-&gt;dev puede interpretarse como que no es un dispositivo de bucle invertido, as\u00ed que simplemente agregue una comprobaci\u00f3n para un dst_orig-&gt;dev nulo. Con esta correcci\u00f3n, los contadores de errores de Tx de la interfaz xfrm suben como de costumbre. [1] net-next calltrace capturado a trav\u00e9s de netconsole: ERROR: desreferencia de puntero NULL del kernel, direcci\u00f3n: 00000000000000c0 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - p\u00e1gina no presente PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 1 PID: 7231 Comm: ping Kdump: cargado No contaminado 5.19.0+ #24 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014 RIP: 0010:xfrm_lookup_with_ifid+0x5eb/0xa60 C\u00f3digo: 8d 74 24 38 e8 26 a4 37 00 48 89 c1 e9 12 fc ff ff 49 63 ed 41 83 fd ser 0f 85 ser 01 00 00 41 ser ff ff ff ff 45 31 ed 48 8b 03 80 c0 00 00 00 08 75 0f 41 80 bc 24 19 0d 00 00 01 0f 84 1e 02 RSP: 0018:ffffb0db82c679f0 EFLAGS: 00010246 RAX: 000000000000000 RBX: ffffd0db7fcad430 RCX: ffffb0db82c67a10 RDX: 00000000000000000 RSI: 0000000000000000 RDI: ffffb0db82c67a80 RBP: ffffb0db82c67a80 R08: ffffb0db82c67a14 R09: 0000000000000000 R10: 0000000000000000 R11: ffff8fa449667dc8 R12: ffffffff966db880 R13: 000000000000000 R14: 00000000ffffffff R15: 000000000000000 FS: 00007ff35c83f000(0000) GS:ffff8fa478480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 000000001ebb7000 CR4: 0000000000350ee0 Seguimiento de llamadas: xfrmi_xmit+0xde/0x460 ? tcf_bpf_act+0x13d/0x2a0 dev_hard_start_xmit+0x72/0x1e0 __dev_queue_xmit+0x251/0xd30 ip_finish_output2+0x140/0x550 ip_push_pending_frames+0x56/0x80 raw_sendmsg+0x663/0x10a0 ? try_charge_memcg+0x3fd/0x7a0 ? __mod_memcg_lruvec_state+0x93/0x110 ? sock_sendmsg+0x30/0x40 sock_sendmsg+0x30/0x40 __sys_sendto+0xeb/0x130 ? manejar_mm_fault+0xae/0x280 ? hacer_direcci\u00f3n_usuario_fault+0x1e7/0x680 ? kvm_read_and_reset_apf_flags+0x3b/0x50 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7ff35cac1366 C\u00f3digo: eb 0b 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff ff eb b8 0f 1f 00 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 72 c3 90 55 48 83 ec 30 44 89 4c 24 2c 4c 89 RSP: 002b:00007fff738e4028 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007fff738e57b0 RCX: 00007ff35cac1366 RDX: 0000000000000040 RSI: 0000557164e4b450 RDI: 0000000000000003 RBP: 0000557164e4b450 R08: 00007fff738e7a2c R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040 R13: 00007fff738e5770 R14: 00007fff738e4030 R15: 0000001d00000001 M\u00f3dulos vinculados en: netconsole veth br_netfilter bridge bonding virtio_net [\u00faltima descarga: netconsole] CR2: 00000000000000c0"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-500xx/CVE-2022-50005.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: pn533: Fix use-after-free bugs caused by pn532_cmd_timeout\n\nWhen the pn532 uart device is detaching, the pn532_uart_remove()\nis called. But there are no functions in pn532_uart_remove() that\ncould delete the cmd_timeout timer, which will cause use-after-free\nbugs. The process is shown below:\n\n (thread 1) | (thread 2)\n | pn532_uart_send_frame\npn532_uart_remove | mod_timer(&pn532->cmd_timeout,...)\n ... | (wait a time)\n kfree(pn532) //FREE | pn532_cmd_timeout\n | pn532_uart_send_frame\n | pn532->... //USE\n\nThis patch adds del_timer_sync() in pn532_uart_remove() in order to\nprevent the use-after-free bugs. What's more, the pn53x_unregister_nfc()\nis well synchronized, it sets nfc_dev->shutting_down to true and there\nare no syscalls could restart the cmd_timeout timer."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfc: pn533: Se corrigen los errores de Use-After-Free causados por pn532_cmd_timeout. Cuando se desconecta el dispositivo uart pn532, se llama a pn532_uart_remove(). Sin embargo, no hay funciones en pn532_uart_remove() que puedan eliminar el temporizador cmd_timeout, lo que causar\u00eda errores de Use-After-Free. El proceso se muestra a continuaci\u00f3n: (hilo 1) | (hilo 2) | pn532_uart_send_frame pn532_uart_remove | mod_timer(&amp;pn532-&gt;cmd_timeout,...) ... | (esperar un tiempo) kfree(pn532) //FREE | pn532_cmd_timeout | pn532_uart_send_frame | pn532-&gt;... //USE Este parche a\u00f1ade del_timer_sync() a pn532_uart_remove() para evitar errores de Use-After-Free. Adem\u00e1s, pn53x_unregister_nfc() est\u00e1 bien sincronizado, establece nfc_dev-&gt;shutting_down como verdadero y ninguna llamada al sistema podr\u00eda reiniciar el temporizador cmd_timeout."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-500xx/CVE-2022-50006.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4.2 fix problems with __nfs42_ssc_open\n\nA destination server while doing a COPY shouldn't accept using the\npassed in filehandle if its not a regular filehandle.\n\nIf alloc_file_pseudo() has failed, we need to decrement a reference\non the newly created inode, otherwise it leaks."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4.2 corrige problemas con __nfs42_ssc_open. Al realizar una copia, un servidor de destino no deber\u00eda aceptar el identificador de archivo proporcionado si no es un identificador de archivo normal. Si alloc_file_pseudo() falla, debemos decrementar una referencia en el inodo reci\u00e9n creado; de lo contrario, se produce una fuga."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-500xx/CVE-2022-50007.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: fix refcount leak in __xfrm_policy_check()\n\nThe issue happens on an error path in __xfrm_policy_check(). When the\nfetching process of the object `pols[1]` fails, the function simply\nreturns 0, forgetting to decrement the reference count of `pols[0]`,\nwhich is incremented earlier by either xfrm_sk_policy_lookup() or\nxfrm_policy_lookup(). This may result in memory leaks.\n\nFix it by decreasing the reference count of `pols[0]` in that path."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: se corrige una fuga de referencias en __xfrm_policy_check(). El problema ocurre en una ruta de error en __xfrm_policy_check(). Cuando falla la obtenci\u00f3n del objeto `pols[1]`, la funci\u00f3n simplemente devuelve 0, olvidando decrementar el recuento de referencias de `pols[0]`, que se incrementa previamente mediante xfrm_sk_policy_lookup() o xfrm_policy_lookup(). Esto puede provocar fugas de memoria. Para solucionarlo, reduzca el recuento de referencias de `pols[0]` en esa ruta."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-500xx/CVE-2022-50008.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nkprobes: don't call disarm_kprobe() for disabled kprobes\n\nThe assumption in __disable_kprobe() is wrong, and it could try to disarm\nan already disarmed kprobe and fire the WARN_ONCE() below. [0] We can\neasily reproduce this issue.\n\n1. Write 0 to /sys/kernel/debug/kprobes/enabled.\n\n # echo 0 > /sys/kernel/debug/kprobes/enabled\n\n2. Run execsnoop. At this time, one kprobe is disabled.\n\n # /usr/share/bcc/tools/execsnoop &\n [1] 2460\n PCOMM PID PPID RET ARGS\n\n # cat /sys/kernel/debug/kprobes/list\n ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE]\n ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]\n\n3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes\n kprobes_all_disarmed to false but does not arm the disabled kprobe.\n\n # echo 1 > /sys/kernel/debug/kprobes/enabled\n\n # cat /sys/kernel/debug/kprobes/list\n ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE]\n ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]\n\n4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the\n disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace().\n\n # fg\n /usr/share/bcc/tools/execsnoop\n ^C\n\nActually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses\nsome cleanups and leaves the aggregated kprobe in the hash table. Then,\n__unregister_trace_kprobe() initialises tk->rp.kp.list and creates an\ninfinite loop like this.\n\n aggregated kprobe.list -> kprobe.list -.\n ^ |\n '.__.'\n\nIn this situation, these commands fall into the infinite loop and result\nin RCU stall or soft lockup.\n\n cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() enters into the\n infinite loop with RCU.\n\n /usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() holds kprobe_mutex,\n and __get_valid_kprobe() is stuck in\n\t\t\t\t the loop.\n\nTo avoid the issue, make sure we don't call disarm_kprobe() for disabled\nkprobes.\n\n[0]\nFailed to disarm kprobe-ftrace at __x64_sys_execve+0x0/0x40 (error -2)\nWARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129)\nModules linked in: ena\nCPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28\nHardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017\nRIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129)\nCode: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94\nRSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001\nRDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff\nRBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff\nR10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40\nR13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000\nFS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n<TASK>\n __disable_kprobe (kernel/kprobes.c:1716)\n disable_kprobe (kernel/kprobes.c:2392)\n __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340)\n disable_trace_kprobe (kernel/trace/trace_kprobe.c:429)\n perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168)\n perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295)\n _free_event (kernel/events/core.c:4971)\n perf_event_release_kernel (kernel/events/core.c:5176)\n perf_release (kernel/events/core.c:5186)\n __fput (fs/file_table.c:321)\n task_work_run (./include/linux/\n---truncated---"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kprobes: no llamar a disarm_kprobe() para kprobes deshabilitados. La suposici\u00f3n en __disable_kprobe() es err\u00f3nea, y podr\u00eda intentar desarmar un kprobe ya desarmado y ejecutar el comando WARN_ONCE() a continuaci\u00f3n. [0] Podemos reproducir f\u00e1cilmente este problema. 1. Escriba 0 en /sys/kernel/debug/kprobes/enabled. # echo 0 &gt; /sys/kernel/debug/kprobes/enabled 2. Ejecute execsnoop. En este momento, un kprobe est\u00e1 deshabilitado. # /usr/share/bcc/tools/execsnoop &amp; [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 3. Escriba 1 en /sys/kernel/debug/kprobes/enabled, lo cual cambia kprobes_all_disarmed a falso pero no arma el kprobe deshabilitado. # echo 1 &gt; /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DESHABILITADO][FTRACE] 4. Matar execsnoop, cuando __disable_kprobe() llama a disarm_kprobe() para el kprobe deshabilitado y llega a WARN_ONCE() en __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^C En realidad, WARN_ONCE() se dispara dos veces, y __unregister_kprobe_top() pierde algunas limpiezas y deja el kprobe agregado en la tabla hash. Luego, __unregister_trace_kprobe() inicializa tk-&gt;rp.kp.list y crea un bucle infinito como este: addedd kprobe.list -&gt; kprobe.list -. ^ | '.__.' En esta situaci\u00f3n, estos comandos caen en el bucle infinito y provocan una parada o un bloqueo suave de la RCU. cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() entra en el bucle infinito con la RCU. /usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() contiene kprobe_mutex, y __get_valid_kprobe() queda atascado en el bucle. Para evitar este problema, aseg\u00farese de no llamar a disarm_kprobe() para las kprobes deshabilitadas. [0] No se pudo desarmar kprobe-ftrace en __x64_sys_execve+0x0/0x40 (error -2) ADVERTENCIA: CPU: 6 PID: 2460 en kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) M\u00f3dulos vinculados: ena CPU: 6 PID: 2460 Comm: execsnoop No contaminado 5.19.0+ #28 Nombre del hardware: Amazon EC2 c5.2xlarge/, BIOS 1.0 16/10/2017 RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) C\u00f3digo: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff &lt;0f&gt; 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 000000000000000 R09: c0000000fffeffff R10: 000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 PKRU: 55555554 Seguimiento de llamadas: __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/---truncado---"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-500xx/CVE-2022-50009.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix null-ptr-deref in f2fs_get_dnode_of_data\n\nThere is issue as follows when test f2fs atomic write:\nF2FS-fs (loop0): Can't find valid F2FS filesystem in 2th superblock\nF2FS-fs (loop0): invalid crc_offset: 0\nF2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=1, run fsck to fix.\nF2FS-fs (loop0): f2fs_check_nid_range: out-of-range nid=2, run fsck to fix.\n==================================================================\nBUG: KASAN: null-ptr-deref in f2fs_get_dnode_of_data+0xac/0x16d0\nRead of size 8 at addr 0000000000000028 by task rep/1990\n\nCPU: 4 PID: 1990 Comm: rep Not tainted 5.19.0-rc6-next-20220715 #266\nCall Trace:\n <TASK>\n dump_stack_lvl+0x6e/0x91\n print_report.cold+0x49a/0x6bb\n kasan_report+0xa8/0x130\n f2fs_get_dnode_of_data+0xac/0x16d0\n f2fs_do_write_data_page+0x2a5/0x1030\n move_data_page+0x3c5/0xdf0\n do_garbage_collect+0x2015/0x36c0\n f2fs_gc+0x554/0x1d30\n f2fs_balance_fs+0x7f5/0xda0\n f2fs_write_single_data_page+0xb66/0xdc0\n f2fs_write_cache_pages+0x716/0x1420\n f2fs_write_data_pages+0x84f/0x9a0\n do_writepages+0x130/0x3a0\n filemap_fdatawrite_wbc+0x87/0xa0\n file_write_and_wait_range+0x157/0x1c0\n f2fs_do_sync_file+0x206/0x12d0\n f2fs_sync_file+0x99/0xc0\n vfs_fsync_range+0x75/0x140\n f2fs_file_write_iter+0xd7b/0x1850\n vfs_write+0x645/0x780\n ksys_write+0xf1/0x1e0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nAs 3db1de0e582c commit changed atomic write way which new a cow_inode for\natomic write file, and also mark cow_inode as FI_ATOMIC_FILE.\nWhen f2fs_do_write_data_page write cow_inode will use cow_inode's cow_inode\nwhich is NULL. Then will trigger null-ptr-deref.\nTo solve above issue, introduce FI_COW_FILE flag for COW inode.\n\nFiexes: 3db1de0e582c(\"f2fs: change the current atomic write way\")"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrige null-ptr-deref en f2fs_get_dnode_of_data Hay un problema como el siguiente cuando se prueba la escritura at\u00f3mica de f2fs: F2FS-fs (loop0): No se puede encontrar un sistema de archivos F2FS v\u00e1lido en el 2.\u00ba superbloque F2FS-fs (loop0): crc_offset no v\u00e1lido: 0 F2FS-fs (loop0): f2fs_check_nid_range: nid fuera de rango = 1, ejecute fsck para corregirlo. F2FS-fs (loop0): f2fs_check_nid_range: nid fuera de rango = 2, ejecute fsck para corregirlo. ======================================================================= ERROR: KASAN: null-ptr-deref en f2fs_get_dnode_of_data+0xac/0x16d0 Lectura de tama\u00f1o 8 en la direcci\u00f3n 000000000000028 por la tarea rep/1990 CPU: 4 PID: 1990 Comm: rep No contaminado 5.19.0-rc6-next-20220715 #266 Rastreo de llamadas: dump_stack_lvl+0x6e/0x91 print_report.cold+0x49a/0x6bb kasan_report+0xa8/0x130 f2fs_get_dnode_of_data+0xac/0x16d0 f2fs_do_write_data_page+0x2a5/0x1030 move_data_page+0x3c5/0xdf0 do_garbage_collect+0x2015/0x36c0 f2fs_gc+0x554/0x1d30 f2fs_balance_fs+0x7f5/0xda0 f2fs_write_single_data_page+0xb66/0xdc0 f2fs_write_cache_pages+0x716/0x1420 f2fs_write_data_pages+0x84f/0x9a0 do_writepages+0x130/0x3a0 filemap_fdatawrite_wbc+0x87/0xa0 file_write_and_wait_range+0x157/0x1c0 f2fs_do_sync_file+0x206/0x12d0 f2fs_sync_file+0x99/0xc0 vfs_fsync_range+0x75/0x140 f2fs_file_write_iter+0xd7b/0x1850 vfs_write+0x645/0x780 ksys_write+0xf1/0x1e0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Como el commit 3db1de0e582c cambi\u00f3 la forma de escritura at\u00f3mica que ahora es un cow_inode para el archivo de escritura at\u00f3mica, y tambi\u00e9n marca cow_inode como FI_ATOMIC_FILE. Al escribir en f2fs_do_write_data_page, cow_inode usar\u00e1 el valor nulo de cow_inode. Esto activar\u00e1 null-ptr-deref. Para solucionar el problema, introduzca el indicador FI_COW_FILE para el inodo COW. Fiexes: 3db1de0e582c(\"f2fs: cambiar la ruta de escritura at\u00f3mica actual\")"
}
],
"metrics": {},

4
CVE-2022/CVE-2022-500xx/CVE-2022-50010.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvideo: fbdev: i740fb: Check the argument of i740_calc_vclk()\n\nSince the user can control the arguments of the ioctl() from the user\nspace, under special arguments that may result in a divide-by-zero bug.\n\nIf the user provides an improper 'pixclock' value that makes the argumet\nof i740_calc_vclk() less than 'I740_RFREQ_FIX', it will cause a\ndivide-by-zero bug in:\n drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX)));\n\nThe following log can reveal it:\n\ndivide error: 0000 [#1] PREEMPT SMP KASAN PTI\nRIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [inline]\nRIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [inline]\nRIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742\nCall Trace:\n fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034\n do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110\n fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189\n\nFix this by checking the argument of i740_calc_vclk() first."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: i740fb: Comprobaci\u00f3n del argumento de i740_calc_vclk(). Dado que el usuario puede controlar los argumentos de ioctl() desde el espacio de usuario, bajo argumentos especiales, esto puede provocar un error de divisi\u00f3n por cero. Si el usuario proporciona un valor de 'pixclock' incorrecto que hace que el argumento de i740_calc_vclk() sea menor que 'I740_RFREQ_FIX', se producir\u00e1 un error de divisi\u00f3n por cero en: drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX))); El siguiente registro puede revelarlo: error de divisi\u00f3n: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [en l\u00ednea] RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [en l\u00ednea] RIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742 Seguimiento de llamadas: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Solucione esto verificando primero el argumento de i740_calc_vclk()."
}
],
"metrics": {},

4
CVE-2022/CVE-2022-500xx/CVE-2022-50011.json
View File

@ -9,6 +9,10 @@
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvenus: pm_helpers: Fix warning in OPP during probe\n\nFix the following WARN triggered during Venus driver probe on\n5.19.0-rc8-next-20220728:\n\n WARNING: CPU: 7 PID: 339 at drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610\n Modules linked in: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor\n qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+)\n videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched\n snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats\n drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5\n phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro\n lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers\n qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector\n drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6\n CPU: 7 PID: 339 Comm: systemd-udevd Not tainted 5.19.0-rc8-next-20220728 #4\n Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)\n pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : dev_pm_opp_set_config+0x49c/0x610\n lr : dev_pm_opp_set_config+0x58/0x610\n sp : ffff8000093c3710\n x29: ffff8000093c3710 x28: ffffbca3959d82b8 x27: ffff8000093c3d00\n x26: ffffbca3959d8e08 x25: ffff4396cac98118 x24: ffff4396c0e24810\n x23: ffff4396c4272c40 x22: ffff4396c0e24810 x21: ffff8000093c3810\n x20: ffff4396cac36800 x19: ffff4396cac96800 x18: 0000000000000000\n x17: 0000000000000003 x16: ffffbca3f4edf198 x15: 0000001cba64a858\n x14: 0000000000000180 x13: 000000000000017e x12: 0000000000000000\n x11: 0000000000000002 x10: 0000000000000a60 x9 : ffff8000093c35c0\n x8 : ffff4396c4273700 x7 : ffff43983efca6c0 x6 : ffff43983efca640\n x5 : 00000000410fd0d0 x4 : ffff4396c4272c40 x3 : ffffbca3f5d1e008\n x2 : 0000000000000000 x1 : ffff4396c2421600 x0 : ffff4396cac96860\n Call trace:\n dev_pm_opp_set_config+0x49c/0x610\n devm_pm_opp_set_config+0x18/0x70\n vcodec_domains_get+0xb8/0x1638 [venus_core]\n core_get_v4+0x1d8/0x218 [venus_core]\n venus_probe+0xf4/0x468 [venus_core]\n platform_probe+0x68/0xd8\n really_probe+0xbc/0x2a8\n __driver_probe_device+0x78/0xe0\n driver_probe_device+0x3c/0xf0\n __driver_attach+0x70/0x120\n bus_for_each_dev+0x70/0xc0\n driver_attach+0x24/0x30\n bus_add_driver+0x150/0x200\n driver_register+0x64/0x120\n __platform_driver_register+0x28/0x38\n qcom_venus_driver_init+0x24/0x1000 [venus_core]\n do_one_initcall+0x54/0x1c8\n do_init_module+0x44/0x1d0\n load_module+0x16c8/0x1aa0\n __do_sys_finit_module+0xbc/0x110\n __arm64_sys_finit_module+0x20/0x30\n invoke_syscall+0x44/0x108\n el0_svc_common.constprop.0+0xcc/0xf0\n do_el0_svc+0x2c/0xb8\n el0_svc+0x2c/0x88\n el0t_64_sync_handler+0xb8/0xc0\n el0t_64_sync+0x18c/0x190\n qcom-venus: probe of aa00000.video-codec failed with error -16\n\nThe fix is re-ordering the code related to OPP core. The OPP core\nexpects all configuration options to be provided before the OPP\ntable is added."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: venus: pm_helpers: Se corrige la advertencia en OPP durante el sondeo Se corrige el siguiente WARN activado durante el sondeo del controlador Venus en 5.19.0-rc8-next-20220728: ADVERTENCIA: CPU: 7 PID: 339 en drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610 M\u00f3dulos vinculados en: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+) videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5 phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6 CPU: 7 PID: 339 Comm: systemd-udevd No contaminado 5.19.0-rc8-next-20220728 #4 Nombre del hardware: Qualcomm Technologies, Inc. Robotics RB5 (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dev_pm_opp_set_config+0x49c/0x610 lr : dev_pm_opp_set_config+0x58/0x610 sp : ffff8000093c3710 x29: ffff8000093c3710 x28: ffffbca3959d82b8 x27: ffff8000093c3d00 x26: ffffbca3959d8e08 x25: ffff4396cac98118 x24: ffff4396c0e24810 x23: ffff4396c4272c40 x22: ffff4396c0e24810 x21: ffff8000093c3810 x20: ffff4396cac36800 x19: ffff4396cac96800 x18: 0000000000000000 x17: 0000000000000003 x16: ffffbca3f4edf198 x15: 0000001cba64a858 x14: 0000000000000180 x13: 000000000000017e x12: 0000000000000000 x11: 0000000000000002 x10: 0000000000000a60 x9: ffff8000093c35c0 x8: ffff4396c4273700 x7: ffff43983efca6c0 x6: ffff43983efca640 x5: 00000000410fd0d0 x4: ffff4396c4272c40 x3: ffffbca3f5d1e008 x2: 00000000000000000 x1 : ffff4396c2421600 x0 : ffff4396cac96860 Rastreo de llamadas: dev_pm_opp_set_config+0x49c/0x610 devm_pm_opp_set_config+0x18/0x70 vcodec_domains_get+0xb8/0x1638 [venus_core] core_get_v4+0x1d8/0x218 [venus_core] venus_probe+0xf4/0x468 [venus_core] platform_probe+0x68/0xd8 really_probe+0xbc/0x2a8 __driver_probe_device+0x78/0xe0 driver_probe_device+0x3c/0xf0 __driver_attach+0x70/0x120 bus_for_each_dev+0x70/0xc0 driver_attach+0x24/0x30 bus_add_driver+0x150/0x200 driver_register+0x64/0x120 __platform_driver_register+0x28/0x38 qcom_venus_driver_init+0x24/0x1000 [venus_core] do_one_initcall+0x54/0x1c8 do_init_module+0x44/0x1d0 load_module+0x16c8/0x1aa0 __do_sys_finit_module+0xbc/0x110 __arm64_sys_finit_module+0x20/0x30 invoke_syscall+0x44/0x108 el0_svc_common.constprop.0+0xcc/0xf0 do_el0_svc+0x2c/0xb8 el0_svc+0x2c/0x88 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x18c/0x190 qcom-venus: probe of aa00000.video-codec failed with error -16. La soluci\u00f3n consiste en reordenar el c\u00f3digo relacionado con el n\u00facleo OPP. El n\u00facleo OPP espera que se proporcionen todas las opciones de configuraci\u00f3n antes de agregar la tabla OPP."
}
],
"metrics": {},

Some files were not shown because too many files have changed in this diff Show More