summaryrefslogtreecommitdiffstats
path: root/meta/recipes-core/glibc/glibc/CVE-2016-10739.patch
diff options
context:
space:
mode:
authorRoss Burton <ross.burton@intel.com>2019-12-08 20:35:57 +0200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2019-12-16 23:11:10 +0000
commit962cbc60d73c91b4d355a32327295fa2e1397dd9 (patch)
treed9ddf63f5a4eb5ebd9859eee4b5bfd69ff53e337 /meta/recipes-core/glibc/glibc/CVE-2016-10739.patch
parent51553d9da2ada4a912110d5ecd4b4bc5d020f80f (diff)
downloadpoky-962cbc60d73c91b4d355a32327295fa2e1397dd9.tar.gz
cve-check: fetch CVE data once at a time instead of in a single call
This code used to construct a single SQL statement that fetched the NVD data for every CVE requested. For recipes such as the kernel where there are over 2000 CVEs to report this can hit the variable count limit and the query fails with "sqlite3.OperationalError: too many SQL variables". The default limit is 999 variables, but some distributions such as Debian set the default to 250000. As the NVD table has an index on the ID column, whilst requesting the data CVE-by-CVE is five times slower when working with 2000 CVEs the absolute time different is insignificant: 0.05s verses 0.01s on my machine. (From OE-Core rev: 53d0cc1e9b7190fa66d7ff1c59518f91b0128d99) (From OE-Core rev: b52d6340acdad27d41caf057b78f181297a9a75e) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-core/glibc/glibc/CVE-2016-10739.patch')
0 files changed, 0 insertions, 0 deletions