mirror of
https://github.com/moby/moby.git
synced 2026-08-03 22:51:03 +00:00
624cba566d
SetBaseChainPolicy read the table's Chains map and modified the chain it found without holding applyLock, only taking the lock when it called Apply to make the change. Racing with an Apply that adds a chain, the map read is a fatal "concurrent map read and map write". Nothing calls it yet - the nftabler doesn't implement filterForwardDrop - so this isn't a live bug, but the API shouldn't come with the race attached. Hold applyLock for the whole read-modify-apply. That needs an unexported apply which assumes the lock is held, so split the body out of Table.Apply, leaving the exported method as the wrapper that checks the table and takes the lock, much like Reload and table.reload. While here, make Reload report a closed table the same way as the other two, rather than relying on the check in table.nftApply and reporting a generic "invalid table" for a table that raced with Close. The happy path of SetBaseChainPolicy had no test coverage at all, which now matters more because it applies the table with applyLock held - a deadlock would be silent. Add one. Signed-off-by: Cory Snider <csnider@mirantis.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
9 lines
156 B
Plaintext
Generated
9 lines
156 B
Plaintext
Generated
table ip this_is_a_table {
|
|
chain this_is_a_base_chain {
|
|
type filter hook forward priority filter; policy drop;
|
|
}
|
|
|
|
chain this_is_a_regular_chain {
|
|
}
|
|
}
|