Fix panic in winlog input by faec · Pull Request #45730 · elastic/beats

faec · 2025-08-04T17:06:20Z

Fixes a panic in the winlog input that happened because of a conflict in the internal id of its metrics registry #45693.

When checking whether a registry input id already exists, the check didn't include the ids of input registries with "nested" type (which are unreported containers for cursor-based inputs that can have several sub-inputs inside).

This is usually not a problem because the default (and what most inputs use even when overriding their id, e.g. I think this is why it probably didn't hit the GCP input) is to use a scoped id like "input_id::source_id", so they don't conflict with the container which has bare id "input_id".
This hit winlog in particular because:

winlog always uses a source id that is the same as its input id
winlog still used the global input metrics helpers in the inputmon package instead of the metrics registry provided by the Filebeat inputs API
winlog is the only input that did not add a scope prefix on the id provided to inputmon.NewInputRegistry, so the globally-created registry conflicted with the input manager's container (and this conflict was missed because of the missed "nested" type check above).

Fixing the missed "nested" collision check would prevent the input panic, but the collision itself would still exist and prevent winlog input metrics from being reported.

This PR both fixes the missed "nested" conflict check and removes the deprecated global metrics call from the winlog input, replacing it with the API-provided registry.

Checklist

My code follows the style guidelines of this project
I have commented my code, particularly in hard-to-understand areas
~~I have made corresponding changes to the documentation~~
~~I have made corresponding change to the default configuration files~~
I have added tests that prove my fix is effective or that my feature works
I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Related issues

Fixes Windows security event processing stops working in versions 9.1.0 and 8.19.0 #45693.

…registry

elasticmachine · 2025-08-04T17:06:24Z

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

github-actions · 2025-08-04T17:06:30Z

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

mergify · 2025-08-04T17:06:59Z

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @faec? 🙏.
For such, you'll need to label your PR with:

The upcoming major version of the Elastic Stack
The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit
backport-active-all is the label that automatically backports to all active branches.
backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

libbeat/monitoring/inputmon/httphandler.go

mauri870

Thanks for fixing this! I don't see anything wrong with the code, but I'm not experienced enough with Winlogbeat to give detailed feedback. Appreciate you adding a test.

…running standalone winlogbeat

winlogbeat/beater/eventlogger.go

winlogbeat/eventlog/wineventlog.go

github-actions · 2025-08-04T21:42:13Z

@Mergifyio backport 8.17 8.18 8.19 9.0 9.1

mergify · 2025-08-04T21:42:33Z

backport 8.17 8.18 8.19 9.0 9.1

✅ Backports have been created

Details

#45736 [8.17](backport #45730) Fix panic in winlog input has been created for branch 8.17 but encountered conflicts
#45737 [8.18](backport #45730) Fix panic in winlog input has been created for branch 8.18 but encountered conflicts
#45738 [8.19](backport #45730) Fix panic in winlog input has been created for branch 8.19 but encountered conflicts
#45740 [9.0](backport #45730) Fix panic in winlog input has been created for branch 9.0 but encountered conflicts
#45741 [9.1](backport #45730) Fix panic in winlog input has been created for branch 9.1

Fixes a panic in the winlog input that happened because of a conflict in the internal id of its metrics registry #45693. When checking whether a registry input id already exists, the check didn't include the ids of input registries with "nested" type (which are unreported containers for cursor-based inputs that can have several sub-inputs inside). This is usually not a problem because the default (and what most inputs use even when overriding their id, e.g. I think this is why it probably didn't hit the GCP input) is to use a scoped id like "input_id::source_id", so they don't conflict with the container which has bare id "input_id". This hit winlog in particular because: - winlog always uses a source id that is the same as its input id - winlog still used the global input metrics helpers in the `inputmon` package instead of the metrics registry provided by the Filebeat inputs API - winlog is the only input that did not add a scope prefix on the id provided to `inputmon.NewInputRegistry`, so the globally-created registry conflicted with the input manager's container (and this conflict was missed because of the missed "nested" type check above). Fixing the missed "nested" collision check would prevent the input panic, but the collision itself would still exist and prevent winlog input metrics from being reported. This PR both fixes the missed "nested" conflict check and removes the deprecated global metrics call from the winlog input, replacing it with the API-provided registry. (cherry picked from commit 4081f24) # Conflicts: # libbeat/monitoring/inputmon/httphandler.go # libbeat/monitoring/inputmon/input_test.go # winlogbeat/beater/eventlogger.go # winlogbeat/eventlog/metrics.go # winlogbeat/eventlog/wineventlog.go

Fixes a panic in the winlog input that happened because of a conflict in the internal id of its metrics registry #45693. When checking whether a registry input id already exists, the check didn't include the ids of input registries with "nested" type (which are unreported containers for cursor-based inputs that can have several sub-inputs inside). This is usually not a problem because the default (and what most inputs use even when overriding their id, e.g. I think this is why it probably didn't hit the GCP input) is to use a scoped id like "input_id::source_id", so they don't conflict with the container which has bare id "input_id". This hit winlog in particular because: - winlog always uses a source id that is the same as its input id - winlog still used the global input metrics helpers in the `inputmon` package instead of the metrics registry provided by the Filebeat inputs API - winlog is the only input that did not add a scope prefix on the id provided to `inputmon.NewInputRegistry`, so the globally-created registry conflicted with the input manager's container (and this conflict was missed because of the missed "nested" type check above). Fixing the missed "nested" collision check would prevent the input panic, but the collision itself would still exist and prevent winlog input metrics from being reported. This PR both fixes the missed "nested" conflict check and removes the deprecated global metrics call from the winlog input, replacing it with the API-provided registry. (cherry picked from commit 4081f24) # Conflicts: # filebeat/input/winlog/input.go # libbeat/monitoring/inputmon/httphandler.go # libbeat/monitoring/inputmon/input_test.go # winlogbeat/beater/eventlogger.go # winlogbeat/eventlog/metrics.go # winlogbeat/eventlog/runner.go # winlogbeat/eventlog/wineventlog.go

Fixes a panic in the winlog input that happened because of a conflict in the internal id of its metrics registry #45693. When checking whether a registry input id already exists, the check didn't include the ids of input registries with "nested" type (which are unreported containers for cursor-based inputs that can have several sub-inputs inside). This is usually not a problem because the default (and what most inputs use even when overriding their id, e.g. I think this is why it probably didn't hit the GCP input) is to use a scoped id like "input_id::source_id", so they don't conflict with the container which has bare id "input_id". This hit winlog in particular because: - winlog always uses a source id that is the same as its input id - winlog still used the global input metrics helpers in the `inputmon` package instead of the metrics registry provided by the Filebeat inputs API - winlog is the only input that did not add a scope prefix on the id provided to `inputmon.NewInputRegistry`, so the globally-created registry conflicted with the input manager's container (and this conflict was missed because of the missed "nested" type check above). Fixing the missed "nested" collision check would prevent the input panic, but the collision itself would still exist and prevent winlog input metrics from being reported. This PR both fixes the missed "nested" conflict check and removes the deprecated global metrics call from the winlog input, replacing it with the API-provided registry. (cherry picked from commit 4081f24) # Conflicts: # winlogbeat/eventlog/metrics.go # winlogbeat/eventlog/wineventlog.go

Fixes a panic in the winlog input that happened because of a conflict in the internal id of its metrics registry #45693. When checking whether a registry input id already exists, the check didn't include the ids of input registries with "nested" type (which are unreported containers for cursor-based inputs that can have several sub-inputs inside). This is usually not a problem because the default (and what most inputs use even when overriding their id, e.g. I think this is why it probably didn't hit the GCP input) is to use a scoped id like "input_id::source_id", so they don't conflict with the container which has bare id "input_id". This hit winlog in particular because: - winlog always uses a source id that is the same as its input id - winlog still used the global input metrics helpers in the `inputmon` package instead of the metrics registry provided by the Filebeat inputs API - winlog is the only input that did not add a scope prefix on the id provided to `inputmon.NewInputRegistry`, so the globally-created registry conflicted with the input manager's container (and this conflict was missed because of the missed "nested" type check above). Fixing the missed "nested" collision check would prevent the input panic, but the collision itself would still exist and prevent winlog input metrics from being reported. This PR both fixes the missed "nested" conflict check and removes the deprecated global metrics call from the winlog input, replacing it with the API-provided registry. (cherry picked from commit 4081f24) # Conflicts: # libbeat/monitoring/inputmon/httphandler.go # libbeat/monitoring/inputmon/input_test.go

Fixes a panic in the winlog input that happened because of a conflict in the internal id of its metrics registry #45693. When checking whether a registry input id already exists, the check didn't include the ids of input registries with "nested" type (which are unreported containers for cursor-based inputs that can have several sub-inputs inside). This is usually not a problem because the default (and what most inputs use even when overriding their id, e.g. I think this is why it probably didn't hit the GCP input) is to use a scoped id like "input_id::source_id", so they don't conflict with the container which has bare id "input_id". This hit winlog in particular because: - winlog always uses a source id that is the same as its input id - winlog still used the global input metrics helpers in the `inputmon` package instead of the metrics registry provided by the Filebeat inputs API - winlog is the only input that did not add a scope prefix on the id provided to `inputmon.NewInputRegistry`, so the globally-created registry conflicted with the input manager's container (and this conflict was missed because of the missed "nested" type check above). Fixing the missed "nested" collision check would prevent the input panic, but the collision itself would still exist and prevent winlog input metrics from being reported. This PR both fixes the missed "nested" conflict check and removes the deprecated global metrics call from the winlog input, replacing it with the API-provided registry. (cherry picked from commit 4081f24)

* Fix panic in winlog input (#45730) Fixes a panic in the winlog input that happened because of a conflict in the internal id of its metrics registry #45693. When checking whether a registry input id already exists, the check didn't include the ids of input registries with "nested" type (which are unreported containers for cursor-based inputs that can have several sub-inputs inside). This is usually not a problem because the default (and what most inputs use even when overriding their id, e.g. I think this is why it probably didn't hit the GCP input) is to use a scoped id like "input_id::source_id", so they don't conflict with the container which has bare id "input_id". This hit winlog in particular because: - winlog always uses a source id that is the same as its input id - winlog still used the global input metrics helpers in the `inputmon` package instead of the metrics registry provided by the Filebeat inputs API - winlog is the only input that did not add a scope prefix on the id provided to `inputmon.NewInputRegistry`, so the globally-created registry conflicted with the input manager's container (and this conflict was missed because of the missed "nested" type check above). Fixing the missed "nested" collision check would prevent the input panic, but the collision itself would still exist and prevent winlog input metrics from being reported. This PR both fixes the missed "nested" conflict check and removes the deprecated global metrics call from the winlog input, replacing it with the API-provided registry. (cherry picked from commit 4081f24) * fix changelog merge --------- Co-authored-by: Fae Charlton <fae.charlton@elastic.co>

* Fix panic in winlog input (#45730) Fixes a panic in the winlog input that happened because of a conflict in the internal id of its metrics registry #45693. When checking whether a registry input id already exists, the check didn't include the ids of input registries with "nested" type (which are unreported containers for cursor-based inputs that can have several sub-inputs inside). This is usually not a problem because the default (and what most inputs use even when overriding their id, e.g. I think this is why it probably didn't hit the GCP input) is to use a scoped id like "input_id::source_id", so they don't conflict with the container which has bare id "input_id". This hit winlog in particular because: - winlog always uses a source id that is the same as its input id - winlog still used the global input metrics helpers in the `inputmon` package instead of the metrics registry provided by the Filebeat inputs API - winlog is the only input that did not add a scope prefix on the id provided to `inputmon.NewInputRegistry`, so the globally-created registry conflicted with the input manager's container (and this conflict was missed because of the missed "nested" type check above). Fixing the missed "nested" collision check would prevent the input panic, but the collision itself would still exist and prevent winlog input metrics from being reported. This PR both fixes the missed "nested" conflict check and removes the deprecated global metrics call from the winlog input, replacing it with the API-provided registry. (cherry picked from commit 4081f24) # Conflicts: # winlogbeat/eventlog/metrics.go # winlogbeat/eventlog/wineventlog.go * fix merge * fix merge for raw event logs that only exist in 8.x * remove nil access of unused field --------- Co-authored-by: Fae Charlton <fae.charlton@elastic.co>

Fixes a panic in the winlog input that happened because of a conflict in the internal id of its metrics registry elastic#45693. When checking whether a registry input id already exists, the check didn't include the ids of input registries with "nested" type (which are unreported containers for cursor-based inputs that can have several sub-inputs inside). This is usually not a problem because the default (and what most inputs use even when overriding their id, e.g. I think this is why it probably didn't hit the GCP input) is to use a scoped id like "input_id::source_id", so they don't conflict with the container which has bare id "input_id". This hit winlog in particular because: - winlog always uses a source id that is the same as its input id - winlog still used the global input metrics helpers in the `inputmon` package instead of the metrics registry provided by the Filebeat inputs API - winlog is the only input that did not add a scope prefix on the id provided to `inputmon.NewInputRegistry`, so the globally-created registry conflicted with the input manager's container (and this conflict was missed because of the missed "nested" type check above). Fixing the missed "nested" collision check would prevent the input panic, but the collision itself would still exist and prevent winlog input metrics from being reported. This PR both fixes the missed "nested" conflict check and removes the deprecated global metrics call from the winlog input, replacing it with the API-provided registry.

Fix winlog metrics crash, have winlog input use API-provided metrics …

a9af734

…registry

faec self-assigned this Aug 4, 2025

faec requested review from a team as code owners August 4, 2025 17:06

faec added bug Team:Elastic-Agent-Data-Plane Label for the Agent Data Plane team labels Aug 4, 2025

faec requested review from leehinman and mauri870 August 4, 2025 17:06

botelastic bot added the needs_team Indicates that the issue/PR needs a Team:* label label Aug 4, 2025

botelastic bot removed the needs_team Indicates that the issue/PR needs a Team:* label label Aug 4, 2025

add changelog

bf1f4ff

faec added the backport-active-all Automated backport with mergify to all the active branches label Aug 4, 2025

faec commented Aug 4, 2025

View reviewed changes

libbeat/monitoring/inputmon/httphandler.go Show resolved Hide resolved

mauri870 approved these changes Aug 4, 2025

View reviewed changes

Fix leaked Filebeat namespace and restore global metrics helper when …

42641e2

…running standalone winlogbeat

nfritts approved these changes Aug 4, 2025

View reviewed changes

faec commented Aug 4, 2025

View reviewed changes

winlogbeat/beater/eventlogger.go Show resolved Hide resolved

leehinman reviewed Aug 4, 2025

View reviewed changes

winlogbeat/eventlog/wineventlog.go Show resolved Hide resolved

leehinman approved these changes Aug 4, 2025

View reviewed changes

Don't include nested input containers in filtered snapshots

6c2e482

faec merged commit 4081f24 into elastic:main Aug 4, 2025
204 of 207 checks passed

faec deleted the winlog-crash-fix branch August 4, 2025 21:42

mergify bot mentioned this pull request Aug 4, 2025

[8.17](backport #45730) Fix panic in winlog input #45736

Closed

6 tasks

This was referenced Aug 4, 2025

[8.18](backport #45730) Fix panic in winlog input #45737

Closed

[8.19](backport #45730) Fix panic in winlog input #45738

Merged

mergify bot mentioned this pull request Aug 4, 2025

[9.0](backport #45730) Fix panic in winlog input #45740

Closed

6 tasks

mergify bot mentioned this pull request Aug 4, 2025

[9.1](backport #45730) Fix panic in winlog input #45741

Merged

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix panic in winlog input#45730

Fix panic in winlog input#45730
faec merged 4 commits intoelastic:mainfrom
faec:winlog-crash-fix

faec commented Aug 4, 2025 •

edited

Loading

elasticmachine commented Aug 4, 2025

github-actions bot commented Aug 4, 2025

mergify bot commented Aug 4, 2025

Uh oh!

mauri870 left a comment

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Aug 4, 2025

mergify bot commented Aug 4, 2025 •

edited

Loading

Labels

5 participants

Conversation

faec commented Aug 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Related issues

elasticmachine commented Aug 4, 2025

github-actions bot commented Aug 4, 2025

🤖 GitHub comments

mergify bot commented Aug 4, 2025

Uh oh!

mauri870 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Aug 4, 2025

mergify bot commented Aug 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Backports have been created

Labels

5 participants

faec commented Aug 4, 2025 •

edited

Loading

mergify bot commented Aug 4, 2025 •

edited

Loading