* CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure @ 2024-12-28 9:45 Greg Kroah-Hartman 2025-04-23 7:54 ` Michal Hocko 0 siblings, 1 reply; 9+ messages in thread From: Greg Kroah-Hartman @ 2024-12-28 9:45 UTC (permalink / raw) To: linux-cve-announce; +Cc: Greg Kroah-Hartman Description =========== In the Linux kernel, the following vulnerability has been resolved: media: atomisp: Add check for rgby_data memory allocation failure In ia_css_3a_statistics_allocate(), there is no check on the allocation result of the rgby_data memory. If rgby_data is not successfully allocated, it may trigger the assert(host_stats->rgby_data) assertion in ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue. The Linux kernel CVE team has assigned CVE-2024-56705 to this issue. Affected and fixed versions =========================== Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.10.231 with commit 0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.15.174 with commit 4676e50444046b498555b849e6080a5c78cdda9b Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.1.120 with commit 02a97d9d7ff605fa4a1f908d1bd3ad8573234b61 Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.6.64 with commit 8066badaf7463194473fb4be19dbe50b11969aa0 Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.11.11 with commit 74aa783682c4d78c69d87898e40c78df1fec204e Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.12.2 with commit 0c25ab93f2878cab07d37ca5afd302283201e5af Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.13-rc1 with commit ed61c59139509f76d3592683c90dc3fdc6e23cd6 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2024-56705 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: drivers/staging/media/atomisp/pci/sh_css_params.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a https://git.kernel.org/stable/c/4676e50444046b498555b849e6080a5c78cdda9b https://git.kernel.org/stable/c/02a97d9d7ff605fa4a1f908d1bd3ad8573234b61 https://git.kernel.org/stable/c/8066badaf7463194473fb4be19dbe50b11969aa0 https://git.kernel.org/stable/c/74aa783682c4d78c69d87898e40c78df1fec204e https://git.kernel.org/stable/c/0c25ab93f2878cab07d37ca5afd302283201e5af https://git.kernel.org/stable/c/ed61c59139509f76d3592683c90dc3fdc6e23cd6 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure 2024-12-28 9:45 CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure Greg Kroah-Hartman @ 2025-04-23 7:54 ` Michal Hocko 2025-04-23 8:21 ` Greg Kroah-Hartman 0 siblings, 1 reply; 9+ messages in thread From: Michal Hocko @ 2025-04-23 7:54 UTC (permalink / raw) To: cve, linux-kernel; +Cc: linux-cve-announce, Greg Kroah-Hartman Hi, our internal tools which are working with vulns.git tree have noticed that this CVE entry has been altered after the announcement. There was an additional commit added to the CVE entry. The current state is $ cat cve/published/2024/CVE-2024-56705.sha1 ed61c59139509f76d3592683c90dc3fdc6e23cd6 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654 There seem to be handful of other cases like this one AFAICS. I have 3 questions: 1) What is 51b8dc5163d2 ("media: staging: atomisp: Remove driver") relation to the original CVE which seems to be about a missing memory allocation failure check? 2) What is the process when a CVE is altered? have I missed any email notification? 3) Until now CVE -> sha was a 1:1 mapping. Can we expect this to change and what exactly is the process here? Thanks! On Sat 28-12-24 10:45:57, Greg KH wrote: > Description > =========== > > In the Linux kernel, the following vulnerability has been resolved: > > media: atomisp: Add check for rgby_data memory allocation failure > > In ia_css_3a_statistics_allocate(), there is no check on the allocation > result of the rgby_data memory. If rgby_data is not successfully > allocated, it may trigger the assert(host_stats->rgby_data) assertion in > ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue. > > The Linux kernel CVE team has assigned CVE-2024-56705 to this issue. > > > Affected and fixed versions > =========================== > > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.10.231 with commit 0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.15.174 with commit 4676e50444046b498555b849e6080a5c78cdda9b > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.1.120 with commit 02a97d9d7ff605fa4a1f908d1bd3ad8573234b61 > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.6.64 with commit 8066badaf7463194473fb4be19dbe50b11969aa0 > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.11.11 with commit 74aa783682c4d78c69d87898e40c78df1fec204e > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.12.2 with commit 0c25ab93f2878cab07d37ca5afd302283201e5af > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.13-rc1 with commit ed61c59139509f76d3592683c90dc3fdc6e23cd6 > > Please see https://www.kernel.org for a full list of currently supported > kernel versions by the kernel community. > > Unaffected versions might change over time as fixes are backported to > older supported kernel versions. The official CVE entry at > https://cve.org/CVERecord/?id=CVE-2024-56705 > will be updated if fixes are backported, please check that for the most > up to date information about this issue. > > > Affected files > ============== > > The file(s) affected by this issue are: > drivers/staging/media/atomisp/pci/sh_css_params.c > > > Mitigation > ========== > > The Linux kernel CVE team recommends that you update to the latest > stable kernel version for this, and many other bugfixes. Individual > changes are never tested alone, but rather are part of a larger kernel > release. Cherry-picking individual commits is not recommended or > supported by the Linux kernel community at all. If however, updating to > the latest release is impossible, the individual changes to resolve this > issue can be found at these commits: > https://git.kernel.org/stable/c/0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a > https://git.kernel.org/stable/c/4676e50444046b498555b849e6080a5c78cdda9b > https://git.kernel.org/stable/c/02a97d9d7ff605fa4a1f908d1bd3ad8573234b61 > https://git.kernel.org/stable/c/8066badaf7463194473fb4be19dbe50b11969aa0 > https://git.kernel.org/stable/c/74aa783682c4d78c69d87898e40c78df1fec204e > https://git.kernel.org/stable/c/0c25ab93f2878cab07d37ca5afd302283201e5af > https://git.kernel.org/stable/c/ed61c59139509f76d3592683c90dc3fdc6e23cd6 -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure 2025-04-23 7:54 ` Michal Hocko @ 2025-04-23 8:21 ` Greg Kroah-Hartman 2025-04-23 9:18 ` Michal Hocko 0 siblings, 1 reply; 9+ messages in thread From: Greg Kroah-Hartman @ 2025-04-23 8:21 UTC (permalink / raw) To: Michal Hocko; +Cc: cve, linux-kernel, linux-cve-announce On Wed, Apr 23, 2025 at 09:54:08AM +0200, Michal Hocko wrote: > Hi, > our internal tools which are working with vulns.git tree have noticed > that this CVE entry has been altered after the announcement. Good catch! > There was an additional commit added to the CVE entry. The current state > is > $ cat cve/published/2024/CVE-2024-56705.sha1 > ed61c59139509f76d3592683c90dc3fdc6e23cd6 > 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654 Yup! > There seem to be handful of other cases like this one AFAICS. Yes, we had to add support for this type of problem. > I have 3 questions: > 1) What is 51b8dc5163d2 ("media: staging: atomisp: Remove driver") > relation to the original CVE which seems to be about a missing memory > allocation failure check? Removing the driver entirely from the kernel "fixed" the vulnerability :) > 2) What is the process when a CVE is altered? have I missed any email > notification? We do not do email notifications when CVEs are altered. You have to watch the cve.org json feed for that. Otherwise the email list would just be too confusing. Think about every new stable update that happens which causes 10+ different CVEs to be updated showing where they are now resolved. That does not come across well in an email feed, but the json feed shows it exactly. Or you can follow the github cve feed, which shows this, OR you can just follow the vulns.git git commits which also show this. > 3) Until now CVE -> sha was a 1:1 mapping. Can we expect this to change > and what exactly is the process here? The process has changed in that we have had to handle a number of CVEs where both the commit that caused the vulnerabilty has been tracked to mutiple commits (think of one-off changes that only happened on different stable branches, and then were fixed with different commit ids, like what happened in CVE-2025-40364), or this example you are pointing out where a vulnerability was introduced, later removed by having the entire driver removed, and then added back by adding the driver back and then resolving the vulnerability. The original CVE had this information as you point out: Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.10.231 with commit 0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.15.174 with commit 4676e50444046b498555b849e6080a5c78cdda9b Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.1.120 with commit 02a97d9d7ff605fa4a1f908d1bd3ad8573234b61 Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.6.64 with commit 8066badaf7463194473fb4be19dbe50b11969aa0 Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.11.11 with commit 74aa783682c4d78c69d87898e40c78df1fec204e Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.12.2 with commit 0c25ab93f2878cab07d37ca5afd302283201e5af Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.13-rc1 with commit ed61c59139509f76d3592683c90dc3fdc6e23cd6 And now it shows this: Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 4.18 with commit 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654 Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 5.10.231 with commit 0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 5.15.174 with commit 4676e50444046b498555b849e6080a5c78cdda9b Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.1.120 with commit 02a97d9d7ff605fa4a1f908d1bd3ad8573234b61 Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.6.64 with commit 8066badaf7463194473fb4be19dbe50b11969aa0 Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.11.11 with commit 74aa783682c4d78c69d87898e40c78df1fec204e Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.12.2 with commit 0c25ab93f2878cab07d37ca5afd302283201e5af Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.13 with commit ed61c59139509f76d3592683c90dc3fdc6e23cd6 Showing that the kernel ranges from 4.18 -> 5.8 were NOT vulnerable to this specific issue. Information that is hopefully very valuable to distros dealing with old kernels, like yours :) So now we can properly handle this types of issues in an automated fashion, thanks again for noticing, this was a non-trivial amount of work to implement. Given that no one had ever done this before, we have had to create all of this "from scratch". Our trees are crazy, hopefully this helps explain the lifecycle of vulnerabilities and their fixes better than before. One other note, perhaps you just want to parse the .dyad files we create instead of mbox files? That provides a machine-readable format of what commits caused a specific vulnerability, and what commits fixed it, if any, in any specific kernel branch that is known. I know at least one distro and one company that just relies on those files directly instead of attempting to parse the crazy json output that cve.org requires which in some places, I would argue, shows actually incorrect information, but that's a different topic... I really should write up more information about all of this one day, but we've just been heads-down trying to implement all of this to deal with the complexity involved in a way that is scalable over time. Does that help? thanks, greg k-h ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure 2025-04-23 8:21 ` Greg Kroah-Hartman @ 2025-04-23 9:18 ` Michal Hocko 2025-04-23 10:20 ` Greg Kroah-Hartman 0 siblings, 1 reply; 9+ messages in thread From: Michal Hocko @ 2025-04-23 9:18 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: cve, linux-kernel, linux-cve-announce On Wed 23-04-25 10:21:04, Greg KH wrote: > On Wed, Apr 23, 2025 at 09:54:08AM +0200, Michal Hocko wrote: > > Hi, > > our internal tools which are working with vulns.git tree have noticed > > that this CVE entry has been altered after the announcement. > > Good catch! > > > There was an additional commit added to the CVE entry. The current state > > is > > $ cat cve/published/2024/CVE-2024-56705.sha1 > > ed61c59139509f76d3592683c90dc3fdc6e23cd6 > > 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654 > > Yup! > > > There seem to be handful of other cases like this one AFAICS. > > Yes, we had to add support for this type of problem. > > > I have 3 questions: > > 1) What is 51b8dc5163d2 ("media: staging: atomisp: Remove driver") > > relation to the original CVE which seems to be about a missing memory > > allocation failure check? > > Removing the driver entirely from the kernel "fixed" the vulnerability :) What is _the_ vulnerability? While I do understand that _any_ potential vulnerability in the removed code is removed as well I still do not see how the driver removal is related to _this_ specific CVE. > > 2) What is the process when a CVE is altered? have I missed any email > > notification? > > We do not do email notifications when CVEs are altered. You have to > watch the cve.org json feed for that. Otherwise the email list would > just be too confusing. Think about every new stable update that happens > which causes 10+ different CVEs to be updated showing where they are now > resolved. That does not come across well in an email feed, but the json > feed shows it exactly. I do understand you do not want to send notifications for that. Would it make sense to announce a new upstream commit added to the CVE, though? This would make it much easier to see that we might be missing a fix that is considered related to a particular CVE. > Or you can follow the github cve feed, which shows this, OR you can just > follow the vulns.git git commits which also show this. > > > 3) Until now CVE -> sha was a 1:1 mapping. Can we expect this to change > > and what exactly is the process here? > > The process has changed in that we have had to handle a number of CVEs > where both the commit that caused the vulnerabilty has been tracked to > mutiple commits (think of one-off changes that only happened on > different stable branches, and then were fixed with different commit > ids, like what happened in CVE-2025-40364), or this example you are > pointing out where a vulnerability was introduced, later removed by > having the entire driver removed, and then added back by adding the > driver back and then resolving the vulnerability. > > The original CVE had this information as you point out: > > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.10.231 with commit 0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 5.15.174 with commit 4676e50444046b498555b849e6080a5c78cdda9b > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.1.120 with commit 02a97d9d7ff605fa4a1f908d1bd3ad8573234b61 > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.6.64 with commit 8066badaf7463194473fb4be19dbe50b11969aa0 > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.11.11 with commit 74aa783682c4d78c69d87898e40c78df1fec204e > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.12.2 with commit 0c25ab93f2878cab07d37ca5afd302283201e5af > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 6.13-rc1 with commit ed61c59139509f76d3592683c90dc3fdc6e23cd6 > > And now it shows this: > > Issue introduced in 4.12 with commit a49d25364dfb9f8a64037488a39ab1f56c5fa419 and fixed in 4.18 with commit 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654 > Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 5.10.231 with commit 0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a > Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 5.15.174 with commit 4676e50444046b498555b849e6080a5c78cdda9b > Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.1.120 with commit 02a97d9d7ff605fa4a1f908d1bd3ad8573234b61 > Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.6.64 with commit 8066badaf7463194473fb4be19dbe50b11969aa0 > Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.11.11 with commit 74aa783682c4d78c69d87898e40c78df1fec204e > Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.12.2 with commit 0c25ab93f2878cab07d37ca5afd302283201e5af > Issue introduced in 5.8 with commit ad85094b293e40e7a2f831b0311a389d952ebd5e and fixed in 6.13 with commit ed61c59139509f76d3592683c90dc3fdc6e23cd6 > > Showing that the kernel ranges from 4.18 -> 5.8 were NOT vulnerable to > this specific issue. Information that is hopefully very valuable to > distros dealing with old kernels, like yours :) Nope, not really. Specific stable tree versions affected is not the most important information to downstreams like ours. We really do care about specific commits that are coupled with the CVE. If the specific commit doesn't have Fixes tag then we look a the CVE-$FOO.vulnerable as well (btw. I have a growing list of those that we have identified breakers for and I am looking for the best way to contribute that information to others. I am just not sure how to do that in the most efficient way - sorry slightly offtopic here - we can follow up off the list.). > So now we can properly handle this types of issues in an automated > fashion, thanks again for noticing, this was a non-trivial amount of > work to implement. Given that no one had ever done this before, we have > had to create all of this "from scratch". > > Our trees are crazy, hopefully this helps explain the lifecycle of > vulnerabilities and their fixes better than before. > > One other note, perhaps you just want to parse the .dyad files we > create instead of mbox files? We are not parsing mbox files. We do care about CVE-$FOO.sha1 and that provides the base for our future analysis. If we need to expect several upstream commits there we are fine with that. Quite honestly seeing a stream of CVEs all fixing the same vulnerability just because those fixes happened in many commits doesn't seem to be optimal. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure 2025-04-23 9:18 ` Michal Hocko @ 2025-04-23 10:20 ` Greg Kroah-Hartman 2025-04-23 11:25 ` Michal Hocko 0 siblings, 1 reply; 9+ messages in thread From: Greg Kroah-Hartman @ 2025-04-23 10:20 UTC (permalink / raw) To: Michal Hocko; +Cc: cve, linux-kernel, linux-cve-announce On Wed, Apr 23, 2025 at 11:18:32AM +0200, Michal Hocko wrote: > On Wed 23-04-25 10:21:04, Greg KH wrote: > > On Wed, Apr 23, 2025 at 09:54:08AM +0200, Michal Hocko wrote: > > > Hi, > > > our internal tools which are working with vulns.git tree have noticed > > > that this CVE entry has been altered after the announcement. > > > > Good catch! > > > > > There was an additional commit added to the CVE entry. The current state > > > is > > > $ cat cve/published/2024/CVE-2024-56705.sha1 > > > ed61c59139509f76d3592683c90dc3fdc6e23cd6 > > > 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654 > > > > Yup! > > > > > There seem to be handful of other cases like this one AFAICS. > > > > Yes, we had to add support for this type of problem. > > > > > I have 3 questions: > > > 1) What is 51b8dc5163d2 ("media: staging: atomisp: Remove driver") > > > relation to the original CVE which seems to be about a missing memory > > > allocation failure check? > > > > Removing the driver entirely from the kernel "fixed" the vulnerability :) > > What is _the_ vulnerability? While I do understand that _any_ potential > vulnerability in the removed code is removed as well I still do not see > how the driver removal is related to _this_ specific CVE. "The" vulnerability is what is fixed in the last commit id, and is what is documented in the text of the CVE, specifically: In ia_css_3a_statistics_allocate(), there is no check on the allocation result of the rgby_data memory. If rgby_data is not successfully allocated, it may trigger the assert(host_stats->rgby_data) assertion in ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue. That has not changed here at all. It's just that the ranges of git versions for when Linux was vulnerable to this issue has been "tightened up" to only reflect when it was possible for this to be a problem (i.e. we now do not count the range of releases where the driver was not present at all in the kernel tree.) > > > 2) What is the process when a CVE is altered? have I missed any email > > > notification? > > > > We do not do email notifications when CVEs are altered. You have to > > watch the cve.org json feed for that. Otherwise the email list would > > just be too confusing. Think about every new stable update that happens > > which causes 10+ different CVEs to be updated showing where they are now > > resolved. That does not come across well in an email feed, but the json > > feed shows it exactly. > > I do understand you do not want to send notifications for that. Would it > make sense to announce a new upstream commit added to the CVE, though? This > would make it much easier to see that we might be missing a fix that is > considered related to a particular CVE. As this has only happened 2 times so far, it's a pretty rare occurance given us allocating over 6000 CVEs. And how exactly would that email look like? We are just changing the ranges here, we change ranges of where a kernel is vulnerable all the time by adding new .vulnerable files to the tree as people report them, and as fixes are backported to older stable kernel trees. That's much more important to you than this type of change, right? > > Showing that the kernel ranges from 4.18 -> 5.8 were NOT vulnerable to > > this specific issue. Information that is hopefully very valuable to > > distros dealing with old kernels, like yours :) > > Nope, not really. Specific stable tree versions affected is not the most > important information to downstreams like ours. We really do care about > specific commits that are coupled with the CVE. If the specific commit > doesn't have Fixes tag then we look a the CVE-$FOO.vulnerable as well > (btw. I have a growing list of those that we have identified breakers > for and I am looking for the best way to contribute that information to > others. I am just not sure how to do that in the most efficient way - > sorry slightly offtopic here - we can follow up off the list.). The simplest way is to send us patches to the repo that add .vulnerable files for those CVE ids, like others have been doing. Look at the git history for many examples of this happening. And yes, git ids are the most important thing, and now we have also tightened up that range. That can be shown in the diff to the dyad file: diff --git a/cve/published/2024/CVE-2024-56705.dyad b/cve/published/2024/CVE-2024-56705.dyad index d4897cd95a08..41ccd4b840c1 100644 --- a/cve/published/2024/CVE-2024-56705.dyad +++ b/cve/published/2024/CVE-2024-56705.dyad @@ -1,9 +1,13 @@ -# dyad version: 0752e6917bd6 +# dyad version: 1.1.0 +# getting vulnerable:fixed pairs for git id 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654 # getting vulnerable:fixed pairs for git id ed61c59139509f76d3592683c90dc3fdc6e23cd6 -4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:5.10.231:0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a -4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:5.15.174:4676e50444046b498555b849e6080a5c78cdda9b -4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:6.1.120:02a97d9d7ff605fa4a1f908d1bd3ad8573234b61 -4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:6.6.64:8066badaf7463194473fb4be19dbe50b11969aa0 -4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:6.11.11:74aa783682c4d78c69d87898e40c78df1fec204e -4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:6.12.2:0c25ab93f2878cab07d37ca5afd302283201e5af -4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:6.13:ed61c59139509f76d3592683c90dc3fdc6e23cd6 +# Setting original vulnerable kernel to be kernel 4.12 and git id a49d25364dfb9f8a64037488a39ab1f56c5fa419 +# Setting original vulnerable kernel to be kernel 5.8 and git id ad85094b293e40e7a2f831b0311a389d952ebd5e +4.12:a49d25364dfb9f8a64037488a39ab1f56c5fa419:4.18:51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654 +5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:5.10.231:0c24b82bc4d12c6a58ceacbf2598cd4df63abf9a +5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:5.15.174:4676e50444046b498555b849e6080a5c78cdda9b +5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:6.1.120:02a97d9d7ff605fa4a1f908d1bd3ad8573234b61 +5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:6.6.64:8066badaf7463194473fb4be19dbe50b11969aa0 +5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:6.11.11:74aa783682c4d78c69d87898e40c78df1fec204e +5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:6.12.2:0c25ab93f2878cab07d37ca5afd302283201e5af +5.8:ad85094b293e40e7a2f831b0311a389d952ebd5e:6.13:ed61c59139509f76d3592683c90dc3fdc6e23cd6 > > So now we can properly handle this types of issues in an automated > > fashion, thanks again for noticing, this was a non-trivial amount of > > work to implement. Given that no one had ever done this before, we have > > had to create all of this "from scratch". > > > > Our trees are crazy, hopefully this helps explain the lifecycle of > > vulnerabilities and their fixes better than before. > > > > One other note, perhaps you just want to parse the .dyad files we > > create instead of mbox files? > > We are not parsing mbox files. We do care about CVE-$FOO.sha1 and that > provides the base for our future analysis. If we need to expect several > upstream commits there we are fine with that. Quite honestly seeing a > stream of CVEs all fixing the same vulnerability just because those > fixes happened in many commits doesn't seem to be optimal. I don't see any multiple CVEs happening here for the same issue, so I do not understand what you are referring to. Again, try following the .dyad files. I think that will help you out a lot more. thanks, greg k-h ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure 2025-04-23 10:20 ` Greg Kroah-Hartman @ 2025-04-23 11:25 ` Michal Hocko 2025-04-23 14:50 ` Greg Kroah-Hartman 0 siblings, 1 reply; 9+ messages in thread From: Michal Hocko @ 2025-04-23 11:25 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: cve, linux-kernel, linux-cve-announce On Wed 23-04-25 12:20:47, Greg KH wrote: > On Wed, Apr 23, 2025 at 11:18:32AM +0200, Michal Hocko wrote: > > On Wed 23-04-25 10:21:04, Greg KH wrote: > > > On Wed, Apr 23, 2025 at 09:54:08AM +0200, Michal Hocko wrote: > > > > Hi, > > > > our internal tools which are working with vulns.git tree have noticed > > > > that this CVE entry has been altered after the announcement. > > > > > > Good catch! > > > > > > > There was an additional commit added to the CVE entry. The current state > > > > is > > > > $ cat cve/published/2024/CVE-2024-56705.sha1 > > > > ed61c59139509f76d3592683c90dc3fdc6e23cd6 > > > > 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654 > > > > > > Yup! > > > > > > > There seem to be handful of other cases like this one AFAICS. > > > > > > Yes, we had to add support for this type of problem. > > > > > > > I have 3 questions: > > > > 1) What is 51b8dc5163d2 ("media: staging: atomisp: Remove driver") > > > > relation to the original CVE which seems to be about a missing memory > > > > allocation failure check? > > > > > > Removing the driver entirely from the kernel "fixed" the vulnerability :) > > > > What is _the_ vulnerability? While I do understand that _any_ potential > > vulnerability in the removed code is removed as well I still do not see > > how the driver removal is related to _this_ specific CVE. > > "The" vulnerability is what is fixed in the last commit id, and is what > is documented in the text of the CVE, specifically: > > In ia_css_3a_statistics_allocate(), there is no check on the allocation > result of the rgby_data memory. If rgby_data is not successfully > allocated, it may trigger the assert(host_stats->rgby_data) assertion in > ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue. I do understand this statement. > That has not changed here at all. It's just that the ranges of git > versions for when Linux was vulnerable to this issue has been "tightened > up" to only reflect when it was possible for this to be a problem (i.e. > we now do not count the range of releases where the driver was not > present at all in the kernel tree.) But I fail to follow this. The commit itself says Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") which makes it clear since when the issue has been introduced. If this tag was not present then there is CVE-$FOO.vulnerable which can specify the same thing. I do not understand how 51b8dc5163d2 is related as it has a different implementation of ia_css_3a_statistics_allocate that doesn't have any unchecked kernel allocations AFAICS. > > > > 2) What is the process when a CVE is altered? have I missed any email > > > > notification? > > > > > > We do not do email notifications when CVEs are altered. You have to > > > watch the cve.org json feed for that. Otherwise the email list would > > > just be too confusing. Think about every new stable update that happens > > > which causes 10+ different CVEs to be updated showing where they are now > > > resolved. That does not come across well in an email feed, but the json > > > feed shows it exactly. > > > > I do understand you do not want to send notifications for that. Would it > > make sense to announce a new upstream commit added to the CVE, though? This > > would make it much easier to see that we might be missing a fix that is > > considered related to a particular CVE. > > As this has only happened 2 times so far, it's a pretty rare occurance > given us allocating over 6000 CVEs. And how exactly would that email > look like? We have identified that CVE-$FOO fix has been incomplete so far and extended list of fixes required for this CVE. Please make sure that those are appplied. Or something in those lines. > We are just changing the ranges here, we change ranges of where a kernel > is vulnerable all the time by adding new .vulnerable files to the tree > as people report them, and as fixes are backported to older stable > kernel trees. That's much more important to you than this type of > change, right? Nope, being aware of what is actually the CVE fix is the most important information. Which kernels are affected specifcally is something that is downstream specific and stable tree ranges are only of a value to those who are using stable trees. Updates to vulnerable files is helpful during evaluation phase but once the assessment is done it acts mostly as a double check. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure 2025-04-23 11:25 ` Michal Hocko @ 2025-04-23 14:50 ` Greg Kroah-Hartman 2025-04-24 9:59 ` Michal Hocko 0 siblings, 1 reply; 9+ messages in thread From: Greg Kroah-Hartman @ 2025-04-23 14:50 UTC (permalink / raw) To: Michal Hocko; +Cc: cve, linux-kernel, linux-cve-announce On Wed, Apr 23, 2025 at 01:25:31PM +0200, Michal Hocko wrote: > On Wed 23-04-25 12:20:47, Greg KH wrote: > > On Wed, Apr 23, 2025 at 11:18:32AM +0200, Michal Hocko wrote: > > > On Wed 23-04-25 10:21:04, Greg KH wrote: > > > > On Wed, Apr 23, 2025 at 09:54:08AM +0200, Michal Hocko wrote: > > > > > Hi, > > > > > our internal tools which are working with vulns.git tree have noticed > > > > > that this CVE entry has been altered after the announcement. > > > > > > > > Good catch! > > > > > > > > > There was an additional commit added to the CVE entry. The current state > > > > > is > > > > > $ cat cve/published/2024/CVE-2024-56705.sha1 > > > > > ed61c59139509f76d3592683c90dc3fdc6e23cd6 > > > > > 51b8dc5163d2ff2bf04019f8bf7e3bd0e75bb654 > > > > > > > > Yup! > > > > > > > > > There seem to be handful of other cases like this one AFAICS. > > > > > > > > Yes, we had to add support for this type of problem. > > > > > > > > > I have 3 questions: > > > > > 1) What is 51b8dc5163d2 ("media: staging: atomisp: Remove driver") > > > > > relation to the original CVE which seems to be about a missing memory > > > > > allocation failure check? > > > > > > > > Removing the driver entirely from the kernel "fixed" the vulnerability :) > > > > > > What is _the_ vulnerability? While I do understand that _any_ potential > > > vulnerability in the removed code is removed as well I still do not see > > > how the driver removal is related to _this_ specific CVE. > > > > "The" vulnerability is what is fixed in the last commit id, and is what > > is documented in the text of the CVE, specifically: > > > > In ia_css_3a_statistics_allocate(), there is no check on the allocation > > result of the rgby_data memory. If rgby_data is not successfully > > allocated, it may trigger the assert(host_stats->rgby_data) assertion in > > ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue. > > I do understand this statement. That is the commit information, and as such we deemed it a vulnerability. > > > That has not changed here at all. It's just that the ranges of git > > versions for when Linux was vulnerable to this issue has been "tightened > > up" to only reflect when it was possible for this to be a problem (i.e. > > we now do not count the range of releases where the driver was not > > present at all in the kernel tree.) > > But I fail to follow this. The commit itself says Fixes: a49d25364dfb > ("staging/atomisp: Add support for the Intel IPU v2") which makes it > clear since when the issue has been introduced. If this tag was not > present then there is CVE-$FOO.vulnerable which can specify the same > thing. I do not understand how 51b8dc5163d2 is related as it has a > different implementation of ia_css_3a_statistics_allocate that doesn't > have any unchecked kernel allocations AFAICS. Ah, ok, that changes things. The person who said that we should count the previous version of the driver said it was vulnerable at that point when it was in the kernel tree. If this isn't the case, we will be glad to change this CVE to reflect that. > > > > > 2) What is the process when a CVE is altered? have I missed any email > > > > > notification? > > > > > > > > We do not do email notifications when CVEs are altered. You have to > > > > watch the cve.org json feed for that. Otherwise the email list would > > > > just be too confusing. Think about every new stable update that happens > > > > which causes 10+ different CVEs to be updated showing where they are now > > > > resolved. That does not come across well in an email feed, but the json > > > > feed shows it exactly. > > > > > > I do understand you do not want to send notifications for that. Would it > > > make sense to announce a new upstream commit added to the CVE, though? This > > > would make it much easier to see that we might be missing a fix that is > > > considered related to a particular CVE. > > > > As this has only happened 2 times so far, it's a pretty rare occurance > > given us allocating over 6000 CVEs. And how exactly would that email > > look like? > > We have identified that CVE-$FOO fix has been incomplete so far and > extended list of fixes required for this CVE. Please make sure that > those are appplied. > > Or something in those lines. Again, that would happen every stable release, and every -rc release, could you really keep up with such an email flow in a way that wouldn't just mirror watching the json feed instead? > > We are just changing the ranges here, we change ranges of where a kernel > > is vulnerable all the time by adding new .vulnerable files to the tree > > as people report them, and as fixes are backported to older stable > > kernel trees. That's much more important to you than this type of > > change, right? > > Nope, being aware of what is actually the CVE fix is the most important > information. Which kernels are affected specifcally is something that is > downstream specific and stable tree ranges are only of a value to those > who are using stable trees. Updates to vulnerable files is helpful > during evaluation phase but once the assessment is done it acts mostly > as a double check. .vulnerable files get added all the time, so hopefully you are catching those updates :) thanks, greg k-h ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure 2025-04-23 14:50 ` Greg Kroah-Hartman @ 2025-04-24 9:59 ` Michal Hocko 2025-04-24 13:48 ` Greg Kroah-Hartman 0 siblings, 1 reply; 9+ messages in thread From: Michal Hocko @ 2025-04-24 9:59 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: cve, linux-kernel, linux-cve-announce On Wed 23-04-25 16:50:48, Greg KH wrote: > On Wed, Apr 23, 2025 at 01:25:31PM +0200, Michal Hocko wrote: > > On Wed 23-04-25 12:20:47, Greg KH wrote: [...] > > > In ia_css_3a_statistics_allocate(), there is no check on the allocation > > > result of the rgby_data memory. If rgby_data is not successfully > > > allocated, it may trigger the assert(host_stats->rgby_data) assertion in > > > ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue. > > > > I do understand this statement. > > That is the commit information, and as such we deemed it a > vulnerability. > > > > > > That has not changed here at all. It's just that the ranges of git > > > versions for when Linux was vulnerable to this issue has been "tightened > > > up" to only reflect when it was possible for this to be a problem (i.e. > > > we now do not count the range of releases where the driver was not > > > present at all in the kernel tree.) > > > > But I fail to follow this. The commit itself says Fixes: a49d25364dfb > > ("staging/atomisp: Add support for the Intel IPU v2") which makes it > > clear since when the issue has been introduced. If this tag was not > > present then there is CVE-$FOO.vulnerable which can specify the same > > thing. I do not understand how 51b8dc5163d2 is related as it has a > > different implementation of ia_css_3a_statistics_allocate that doesn't > > have any unchecked kernel allocations AFAICS. > > Ah, ok, that changes things. The person who said that we should count > the previous version of the driver said it was vulnerable at that point > when it was in the kernel tree. If this isn't the case, we will be glad > to change this CVE to reflect that. OK, so I have dived into this deeper just to be sure - fix ed61c5913950 merged v6.13-rc1 - breaker: the commit says Fixes: a49d25364dfb merged v4.12-rc1 which indeed adds ia_css_3a_statistics_allocate and uses it in atomisp_alloc_3a_output_buf - now we have 51b8dc5163d2 ("media: staging: atomisp: Remove driver") merged 4.18 mentioned in .sha1 file which drops the whole driver. The driver was later reintroduced by ad85094b293e in v5.8-rc1 - that being said the kernel has been vulnerable since 4.12 until 4.18 and 5.8 until 6.13. There is a gap when the code was not there and the kernel was therefore not affected. All that being said I do understand the second entry now but considering the first entry and its Fixes tag I believe the second entry is simply redundant. CVE-2024-53204, CVE-2024-53205 are the same situation. CVE-2025-40364 is different. Both of the sha1 entries are stable specific commits (same change) with a references to Fixes: c7fb19428d67d merged in v5.19-rc1. This one has a follow up fix merged in fc9375e3f763 v5.19-rc3. So this CVE seems like stable specific (probably a misbackport?) or is this a mistake? > > > > > > 2) What is the process when a CVE is altered? have I missed any email > > > > > > notification? > > > > > > > > > > We do not do email notifications when CVEs are altered. You have to > > > > > watch the cve.org json feed for that. Otherwise the email list would > > > > > just be too confusing. Think about every new stable update that happens > > > > > which causes 10+ different CVEs to be updated showing where they are now > > > > > resolved. That does not come across well in an email feed, but the json > > > > > feed shows it exactly. > > > > > > > > I do understand you do not want to send notifications for that. Would it > > > > make sense to announce a new upstream commit added to the CVE, though? This > > > > would make it much easier to see that we might be missing a fix that is > > > > considered related to a particular CVE. > > > > > > As this has only happened 2 times so far, it's a pretty rare occurance > > > given us allocating over 6000 CVEs. And how exactly would that email > > > look like? > > > > We have identified that CVE-$FOO fix has been incomplete so far and > > extended list of fixes required for this CVE. Please make sure that > > those are appplied. > > > > Or something in those lines. > > Again, that would happen every stable release, and every -rc release, > could you really keep up with such an email flow in a way that wouldn't > just mirror watching the json feed instead? AFAICS there usually are no updates to CVE-$FOO.sha1 file and that is what really matters to us to identify all the commits that are associated with the specific CVE. -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure 2025-04-24 9:59 ` Michal Hocko @ 2025-04-24 13:48 ` Greg Kroah-Hartman 0 siblings, 0 replies; 9+ messages in thread From: Greg Kroah-Hartman @ 2025-04-24 13:48 UTC (permalink / raw) To: Michal Hocko; +Cc: cve, linux-kernel, linux-cve-announce On Thu, Apr 24, 2025 at 11:59:35AM +0200, Michal Hocko wrote: > On Wed 23-04-25 16:50:48, Greg KH wrote: > > On Wed, Apr 23, 2025 at 01:25:31PM +0200, Michal Hocko wrote: > > > On Wed 23-04-25 12:20:47, Greg KH wrote: > [...] > > > > In ia_css_3a_statistics_allocate(), there is no check on the allocation > > > > result of the rgby_data memory. If rgby_data is not successfully > > > > allocated, it may trigger the assert(host_stats->rgby_data) assertion in > > > > ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue. > > > > > > I do understand this statement. > > > > That is the commit information, and as such we deemed it a > > vulnerability. > > > > > > > > > That has not changed here at all. It's just that the ranges of git > > > > versions for when Linux was vulnerable to this issue has been "tightened > > > > up" to only reflect when it was possible for this to be a problem (i.e. > > > > we now do not count the range of releases where the driver was not > > > > present at all in the kernel tree.) > > > > > > But I fail to follow this. The commit itself says Fixes: a49d25364dfb > > > ("staging/atomisp: Add support for the Intel IPU v2") which makes it > > > clear since when the issue has been introduced. If this tag was not > > > present then there is CVE-$FOO.vulnerable which can specify the same > > > thing. I do not understand how 51b8dc5163d2 is related as it has a > > > different implementation of ia_css_3a_statistics_allocate that doesn't > > > have any unchecked kernel allocations AFAICS. > > > > Ah, ok, that changes things. The person who said that we should count > > the previous version of the driver said it was vulnerable at that point > > when it was in the kernel tree. If this isn't the case, we will be glad > > to change this CVE to reflect that. > > OK, so I have dived into this deeper just to be sure > - fix ed61c5913950 merged v6.13-rc1 > - breaker: the commit says Fixes: a49d25364dfb merged v4.12-rc1 which > indeed adds ia_css_3a_statistics_allocate and uses it in atomisp_alloc_3a_output_buf > - now we have 51b8dc5163d2 ("media: staging: atomisp: Remove driver") > merged 4.18 mentioned in .sha1 file which drops the whole > driver. The driver was later reintroduced by ad85094b293e in v5.8-rc1 > - that being said the kernel has been vulnerable since 4.12 > until 4.18 and 5.8 until 6.13. There is a gap when the code > was not there and the kernel was therefore not affected. > All that being said I do understand the second entry now but considering > the first entry and its Fixes tag I believe the second entry is simply > redundant. Redundant if you are just using the .sha1 files, yes. Not if you use the .dyad files which show you exactly what you came up with here. So for now, let's leave the .sha1 file alone, as without that second commit in there, the tools can not figure out what you just determined above in a programatic way. Or if you think they can, hey, patches are always gladly accepted! The tools are now in rust, not crazy bash, with a regression test suite, and any help is always welcome. > CVE-2024-53204, CVE-2024-53205 are the same situation. > > CVE-2025-40364 is different. Both of the sha1 entries are stable > specific commits (same change) with a references to Fixes: c7fb19428d67d > merged in v5.19-rc1. This one has a follow up fix merged in fc9375e3f763 > v5.19-rc3. > So this CVE seems like stable specific (probably a misbackport?) or is this > a mistake? It is a stable-specific CVE. It's not the first time we've had this, and will probably not be the last. > > > > > > > 2) What is the process when a CVE is altered? have I missed any email > > > > > > > notification? > > > > > > > > > > > > We do not do email notifications when CVEs are altered. You have to > > > > > > watch the cve.org json feed for that. Otherwise the email list would > > > > > > just be too confusing. Think about every new stable update that happens > > > > > > which causes 10+ different CVEs to be updated showing where they are now > > > > > > resolved. That does not come across well in an email feed, but the json > > > > > > feed shows it exactly. > > > > > > > > > > I do understand you do not want to send notifications for that. Would it > > > > > make sense to announce a new upstream commit added to the CVE, though? This > > > > > would make it much easier to see that we might be missing a fix that is > > > > > considered related to a particular CVE. > > > > > > > > As this has only happened 2 times so far, it's a pretty rare occurance > > > > given us allocating over 6000 CVEs. And how exactly would that email > > > > look like? > > > > > > We have identified that CVE-$FOO fix has been incomplete so far and > > > extended list of fixes required for this CVE. Please make sure that > > > those are appplied. > > > > > > Or something in those lines. > > > > Again, that would happen every stable release, and every -rc release, > > could you really keep up with such an email flow in a way that wouldn't > > just mirror watching the json feed instead? > > AFAICS there usually are no updates to CVE-$FOO.sha1 file and that is what > really matters to us to identify all the commits that are associated > with the specific CVE. Hopefully you all have the same tooling in place that we've created to dig through the git repo to track what has been backported where. But again, if not, feel free to use the .dyad files which show you all of the needed information in a machine readable format :) thanks, greg k-h ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2025-04-24 13:48 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-12-28 9:45 CVE-2024-56705: media: atomisp: Add check for rgby_data memory allocation failure Greg Kroah-Hartman 2025-04-23 7:54 ` Michal Hocko 2025-04-23 8:21 ` Greg Kroah-Hartman 2025-04-23 9:18 ` Michal Hocko 2025-04-23 10:20 ` Greg Kroah-Hartman 2025-04-23 11:25 ` Michal Hocko 2025-04-23 14:50 ` Greg Kroah-Hartman 2025-04-24 9:59 ` Michal Hocko 2025-04-24 13:48 ` Greg Kroah-Hartman
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.