* Re: CVE-2023-52605: ACPI: extlog: fix NULL pointer dereference check [not found] <2024030647-CVE-2023-52605-292a@gregkh> @ 2024-03-10 8:10 ` Vegard Nossum 2024-03-11 12:14 ` Prarit Bhargava 0 siblings, 1 reply; 5+ messages in thread From: Vegard Nossum @ 2024-03-10 8:10 UTC (permalink / raw) To: cve, linux-kernel, linux-cve-announce Cc: Greg Kroah-Hartman, Prarit Bhargava, Rafael J. Wysocki (Added author/maintainer to Cc) On 06/03/2024 07:46, Greg Kroah-Hartman wrote: > Description > =========== > > In the Linux kernel, the following vulnerability has been resolved: > > ACPI: extlog: fix NULL pointer dereference check > > The gcc plugin -fanalyzer [1] tries to detect various > patterns of incorrect behaviour. The tool reports: > > drivers/acpi/acpi_extlog.c: In function ‘extlog_exit’: > drivers/acpi/acpi_extlog.c:307:12: warning: check of ‘extlog_l1_addr’ for NULL after already dereferencing it [-Wanalyzer-deref-before-check] > | > | 306 | ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; > | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ > | | | > | | (1) pointer ‘extlog_l1_addr’ is dereferenced here > | 307 | if (extlog_l1_addr) > | | ~ > | | | > | | (2) pointer ‘extlog_l1_addr’ is checked for NULL here but it was already dereferenced at (1) > | > > Fix the NULL pointer dereference check in extlog_exit(). > > The Linux kernel CVE team has assigned CVE-2023-52605 to this issue. This code is in an __exit function: diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c index e120a96e1eaee..193147769146e 100644 --- a/drivers/acpi/acpi_extlog.c +++ b/drivers/acpi/acpi_extlog.c @@ -303,9 +303,10 @@ err: static void __exit extlog_exit(void) { mce_unregister_decode_chain(&extlog_mce_dec); - ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; - if (extlog_l1_addr) + if (extlog_l1_addr) { + ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; acpi_os_unmap_iomem(extlog_l1_addr, l1_size); + } if (elog_addr) acpi_os_unmap_iomem(elog_addr, elog_size); release_mem_region(elog_base, elog_size); This can only run when you unload a module, which is a privileged operation (restricted to CAP_SYS_MODULE). Moreover, extlog_l1_addr is only ever assigned in the corresponding module init function, and it looks like it will never be NULL if the module was loaded successfully, at least on a recent mainline kernel. Since the module exit won't be called unless module init succeeded, I don't see a way to trigger this bug. Is this a vulnerability? It might be better to just delete the NULL check altogether. As usual, I could be wrong... Vegard ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: CVE-2023-52605: ACPI: extlog: fix NULL pointer dereference check 2024-03-10 8:10 ` CVE-2023-52605: ACPI: extlog: fix NULL pointer dereference check Vegard Nossum @ 2024-03-11 12:14 ` Prarit Bhargava 2024-03-14 11:01 ` Lee Jones 0 siblings, 1 reply; 5+ messages in thread From: Prarit Bhargava @ 2024-03-11 12:14 UTC (permalink / raw) To: Vegard Nossum, cve, linux-kernel, linux-cve-announce Cc: Greg Kroah-Hartman, Rafael J. Wysocki On 3/10/24 04:10, Vegard Nossum wrote: > > (Added author/maintainer to Cc) > > On 06/03/2024 07:46, Greg Kroah-Hartman wrote: >> Description >> =========== >> >> In the Linux kernel, the following vulnerability has been resolved: >> >> ACPI: extlog: fix NULL pointer dereference check >> >> The gcc plugin -fanalyzer [1] tries to detect various >> patterns of incorrect behaviour. The tool reports: >> >> drivers/acpi/acpi_extlog.c: In function ‘extlog_exit’: >> drivers/acpi/acpi_extlog.c:307:12: warning: check of ‘extlog_l1_addr’ >> for NULL after already dereferencing it [-Wanalyzer-deref-before-check] >> | >> | 306 | ((struct extlog_l1_head *)extlog_l1_addr)->flags >> &= ~FLAG_OS_OPTIN; >> | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ >> | | | >> | | (1) >> pointer ‘extlog_l1_addr’ is dereferenced here >> | 307 | if (extlog_l1_addr) >> | | ~ >> | | | >> | | (2) pointer ‘extlog_l1_addr’ is checked for >> NULL here but it was already dereferenced at (1) >> | >> >> Fix the NULL pointer dereference check in extlog_exit(). >> >> The Linux kernel CVE team has assigned CVE-2023-52605 to this issue. > > This code is in an __exit function: > > diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c > index e120a96e1eaee..193147769146e 100644 > --- a/drivers/acpi/acpi_extlog.c > +++ b/drivers/acpi/acpi_extlog.c > @@ -303,9 +303,10 @@ err: > static void __exit extlog_exit(void) > { > mce_unregister_decode_chain(&extlog_mce_dec); > - ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; > - if (extlog_l1_addr) > + if (extlog_l1_addr) { > + ((struct extlog_l1_head *)extlog_l1_addr)->flags &= > ~FLAG_OS_OPTIN; > acpi_os_unmap_iomem(extlog_l1_addr, l1_size); > + } > if (elog_addr) > acpi_os_unmap_iomem(elog_addr, elog_size); > release_mem_region(elog_base, elog_size); > > This can only run when you unload a module, which is a privileged > operation (restricted to CAP_SYS_MODULE). > > Moreover, extlog_l1_addr is only ever assigned in the corresponding > module init function, and it looks like it will never be NULL if the > module was loaded successfully, at least on a recent mainline kernel. > > Since the module exit won't be called unless module init succeeded, I > don't see a way to trigger this bug. Is this a vulnerability? > This is certainly not a CVE. > It might be better to just delete the NULL check altogether. > > As usual, I could be wrong... > When I made this code change I thought the same thing: Perhaps it's better to remove the NULL check given the status of the code. I assumed that the check was there as a failsafe on unload. P. > > Vegard > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: CVE-2023-52605: ACPI: extlog: fix NULL pointer dereference check 2024-03-11 12:14 ` Prarit Bhargava @ 2024-03-14 11:01 ` Lee Jones 2024-03-15 19:24 ` Wysocki, Rafael J 0 siblings, 1 reply; 5+ messages in thread From: Lee Jones @ 2024-03-14 11:01 UTC (permalink / raw) To: Prarit Bhargava Cc: Vegard Nossum, cve, linux-kernel, linux-cve-announce, Greg Kroah-Hartman, Rafael J. Wysocki On Mon, 11 Mar 2024, Prarit Bhargava wrote: > On 3/10/24 04:10, Vegard Nossum wrote: > > > > (Added author/maintainer to Cc) > > > > On 06/03/2024 07:46, Greg Kroah-Hartman wrote: > > > Description > > > =========== > > > > > > In the Linux kernel, the following vulnerability has been resolved: > > > > > > ACPI: extlog: fix NULL pointer dereference check > > > > > > The gcc plugin -fanalyzer [1] tries to detect various > > > patterns of incorrect behaviour. The tool reports: > > > > > > drivers/acpi/acpi_extlog.c: In function ‘extlog_exit’: > > > drivers/acpi/acpi_extlog.c:307:12: warning: check of > > > ‘extlog_l1_addr’ for NULL after already dereferencing it > > > [-Wanalyzer-deref-before-check] > > > | > > > | 306 | ((struct extlog_l1_head > > > *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; > > > | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ > > > | | | > > > | | (1) > > > pointer ‘extlog_l1_addr’ is dereferenced here > > > | 307 | if (extlog_l1_addr) > > > | | ~ > > > | | | > > > | | (2) pointer ‘extlog_l1_addr’ is checked for > > > NULL here but it was already dereferenced at (1) > > > | > > > > > > Fix the NULL pointer dereference check in extlog_exit(). > > > > > > The Linux kernel CVE team has assigned CVE-2023-52605 to this issue. > > > > This code is in an __exit function: > > > > diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c > > index e120a96e1eaee..193147769146e 100644 > > --- a/drivers/acpi/acpi_extlog.c > > +++ b/drivers/acpi/acpi_extlog.c > > @@ -303,9 +303,10 @@ err: > > static void __exit extlog_exit(void) > > { > > mce_unregister_decode_chain(&extlog_mce_dec); > > - ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; > > - if (extlog_l1_addr) > > + if (extlog_l1_addr) { > > + ((struct extlog_l1_head *)extlog_l1_addr)->flags &= > > ~FLAG_OS_OPTIN; > > acpi_os_unmap_iomem(extlog_l1_addr, l1_size); > > + } > > if (elog_addr) > > acpi_os_unmap_iomem(elog_addr, elog_size); > > release_mem_region(elog_base, elog_size); > > > > This can only run when you unload a module, which is a privileged > > operation (restricted to CAP_SYS_MODULE). > > > > Moreover, extlog_l1_addr is only ever assigned in the corresponding > > module init function, and it looks like it will never be NULL if the > > module was loaded successfully, at least on a recent mainline kernel. > > > > Since the module exit won't be called unless module init succeeded, I > > don't see a way to trigger this bug. Is this a vulnerability? > > > > This is certainly not a CVE. > > > It might be better to just delete the NULL check altogether. > > > > As usual, I could be wrong... > > > > When I made this code change I thought the same thing: Perhaps it's better > to remove the NULL check given the status of the code. I assumed that the > check was there as a failsafe on unload. If Rafael agrees with you both, I'd be happy to revoke its CVE status. -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: CVE-2023-52605: ACPI: extlog: fix NULL pointer dereference check 2024-03-14 11:01 ` Lee Jones @ 2024-03-15 19:24 ` Wysocki, Rafael J 2024-03-18 15:13 ` Lee Jones 0 siblings, 1 reply; 5+ messages in thread From: Wysocki, Rafael J @ 2024-03-15 19:24 UTC (permalink / raw) To: Lee Jones, Prarit Bhargava Cc: Vegard Nossum, cve, linux-kernel, linux-cve-announce, Greg Kroah-Hartman On 3/14/2024 12:01 PM, Lee Jones wrote: > On Mon, 11 Mar 2024, Prarit Bhargava wrote: > >> On 3/10/24 04:10, Vegard Nossum wrote: >>> (Added author/maintainer to Cc) >>> >>> On 06/03/2024 07:46, Greg Kroah-Hartman wrote: >>>> Description >>>> =========== >>>> >>>> In the Linux kernel, the following vulnerability has been resolved: >>>> >>>> ACPI: extlog: fix NULL pointer dereference check >>>> >>>> The gcc plugin -fanalyzer [1] tries to detect various >>>> patterns of incorrect behaviour. The tool reports: >>>> >>>> drivers/acpi/acpi_extlog.c: In function ‘extlog_exit’: >>>> drivers/acpi/acpi_extlog.c:307:12: warning: check of >>>> ‘extlog_l1_addr’ for NULL after already dereferencing it >>>> [-Wanalyzer-deref-before-check] >>>> | >>>> | 306 | ((struct extlog_l1_head >>>> *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; >>>> | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ >>>> | | | >>>> | | (1) >>>> pointer ‘extlog_l1_addr’ is dereferenced here >>>> | 307 | if (extlog_l1_addr) >>>> | | ~ >>>> | | | >>>> | | (2) pointer ‘extlog_l1_addr’ is checked for >>>> NULL here but it was already dereferenced at (1) >>>> | >>>> >>>> Fix the NULL pointer dereference check in extlog_exit(). >>>> >>>> The Linux kernel CVE team has assigned CVE-2023-52605 to this issue. >>> This code is in an __exit function: >>> >>> diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c >>> index e120a96e1eaee..193147769146e 100644 >>> --- a/drivers/acpi/acpi_extlog.c >>> +++ b/drivers/acpi/acpi_extlog.c >>> @@ -303,9 +303,10 @@ err: >>> static void __exit extlog_exit(void) >>> { >>> mce_unregister_decode_chain(&extlog_mce_dec); >>> - ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; >>> - if (extlog_l1_addr) >>> + if (extlog_l1_addr) { >>> + ((struct extlog_l1_head *)extlog_l1_addr)->flags &= >>> ~FLAG_OS_OPTIN; >>> acpi_os_unmap_iomem(extlog_l1_addr, l1_size); >>> + } >>> if (elog_addr) >>> acpi_os_unmap_iomem(elog_addr, elog_size); >>> release_mem_region(elog_base, elog_size); >>> >>> This can only run when you unload a module, which is a privileged >>> operation (restricted to CAP_SYS_MODULE). >>> >>> Moreover, extlog_l1_addr is only ever assigned in the corresponding >>> module init function, and it looks like it will never be NULL if the >>> module was loaded successfully, at least on a recent mainline kernel. >>> >>> Since the module exit won't be called unless module init succeeded, I >>> don't see a way to trigger this bug. Is this a vulnerability? >>> >> This is certainly not a CVE. >> >>> It might be better to just delete the NULL check altogether. >>> >>> As usual, I could be wrong... >>> >> When I made this code change I thought the same thing: Perhaps it's better >> to remove the NULL check given the status of the code. I assumed that the >> check was there as a failsafe on unload. > If Rafael agrees with you both, I'd be happy to revoke its CVE status. I do agree with the analysis above, sorry for the delay. Thanks, Rafael ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: CVE-2023-52605: ACPI: extlog: fix NULL pointer dereference check 2024-03-15 19:24 ` Wysocki, Rafael J @ 2024-03-18 15:13 ` Lee Jones 0 siblings, 0 replies; 5+ messages in thread From: Lee Jones @ 2024-03-18 15:13 UTC (permalink / raw) To: Wysocki, Rafael J Cc: Prarit Bhargava, Vegard Nossum, cve, linux-kernel, linux-cve-announce, Greg Kroah-Hartman On Fri, 15 Mar 2024, Wysocki, Rafael J wrote: > On 3/14/2024 12:01 PM, Lee Jones wrote: > > On Mon, 11 Mar 2024, Prarit Bhargava wrote: > > > > > On 3/10/24 04:10, Vegard Nossum wrote: > > > > (Added author/maintainer to Cc) > > > > > > > > On 06/03/2024 07:46, Greg Kroah-Hartman wrote: > > > > > Description > > > > > =========== > > > > > > > > > > In the Linux kernel, the following vulnerability has been resolved: > > > > > > > > > > ACPI: extlog: fix NULL pointer dereference check > > > > > > > > > > The gcc plugin -fanalyzer [1] tries to detect various > > > > > patterns of incorrect behaviour. The tool reports: > > > > > > > > > > drivers/acpi/acpi_extlog.c: In function ‘extlog_exit’: > > > > > drivers/acpi/acpi_extlog.c:307:12: warning: check of > > > > > ‘extlog_l1_addr’ for NULL after already dereferencing it > > > > > [-Wanalyzer-deref-before-check] > > > > > | > > > > > | 306 | ((struct extlog_l1_head > > > > > *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; > > > > > | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ > > > > > | | | > > > > > | | (1) > > > > > pointer ‘extlog_l1_addr’ is dereferenced here > > > > > | 307 | if (extlog_l1_addr) > > > > > | | ~ > > > > > | | | > > > > > | | (2) pointer ‘extlog_l1_addr’ is checked for > > > > > NULL here but it was already dereferenced at (1) > > > > > | > > > > > > > > > > Fix the NULL pointer dereference check in extlog_exit(). > > > > > > > > > > The Linux kernel CVE team has assigned CVE-2023-52605 to this issue. > > > > This code is in an __exit function: > > > > > > > > diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c > > > > index e120a96e1eaee..193147769146e 100644 > > > > --- a/drivers/acpi/acpi_extlog.c > > > > +++ b/drivers/acpi/acpi_extlog.c > > > > @@ -303,9 +303,10 @@ err: > > > > static void __exit extlog_exit(void) > > > > { > > > > mce_unregister_decode_chain(&extlog_mce_dec); > > > > - ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; > > > > - if (extlog_l1_addr) > > > > + if (extlog_l1_addr) { > > > > + ((struct extlog_l1_head *)extlog_l1_addr)->flags &= > > > > ~FLAG_OS_OPTIN; > > > > acpi_os_unmap_iomem(extlog_l1_addr, l1_size); > > > > + } > > > > if (elog_addr) > > > > acpi_os_unmap_iomem(elog_addr, elog_size); > > > > release_mem_region(elog_base, elog_size); > > > > > > > > This can only run when you unload a module, which is a privileged > > > > operation (restricted to CAP_SYS_MODULE). > > > > > > > > Moreover, extlog_l1_addr is only ever assigned in the corresponding > > > > module init function, and it looks like it will never be NULL if the > > > > module was loaded successfully, at least on a recent mainline kernel. > > > > > > > > Since the module exit won't be called unless module init succeeded, I > > > > don't see a way to trigger this bug. Is this a vulnerability? > > > > > > > This is certainly not a CVE. > > > > > > > It might be better to just delete the NULL check altogether. > > > > > > > > As usual, I could be wrong... > > > > > > > When I made this code change I thought the same thing: Perhaps it's better > > > to remove the NULL check given the status of the code. I assumed that the > > > check was there as a failsafe on unload. > > If Rafael agrees with you both, I'd be happy to revoke its CVE status. > > I do agree with the analysis above, sorry for the delay. No problem Rafael. Okay, CVE-2023-52605 has now been rejected. https://lore.kernel.org/all/20240318151025.2952751-2-lee@kernel.org/ -- Lee Jones [李琼斯] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-03-18 15:13 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <2024030647-CVE-2023-52605-292a@gregkh>
2024-03-10 8:10 ` CVE-2023-52605: ACPI: extlog: fix NULL pointer dereference check Vegard Nossum
2024-03-11 12:14 ` Prarit Bhargava
2024-03-14 11:01 ` Lee Jones
2024-03-15 19:24 ` Wysocki, Rafael J
2024-03-18 15:13 ` Lee Jones
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox