Port 53 bricks Container Creation

[l4rm4nd]

Before submitting / 提交之前

• I have verified that I use latest version and no similar issues were found. / 我已验证我使用的是最新版本，并且没有找到类似的问题。

What version of GZCTF are you using? / 您使用的 GZCTF 版本是什么？

v1.8.4

What is the commit hash for your build? (in About page and backend logs) / 您所使用的构建的提交哈希是什么？（在关于页面和后端日志中）

4ba7b62

In which browsers you can reproduce the issue? / 您在哪些浏览器中可以重现此问题？

All

Describe the bug / 描述 bug

I have a CTF challenge that uses the port 53. Challenge worked in previous GZCTF versions but I cannot tell which ones. Maybe 1.8.0 broke something with the introduction of networks and DB migrations. It's an old challenge not often spawned.

If i try to create the container now, GZCTF fails and reports back an error in the browser frontend:

An error has occurred
Internal server error

The container logs show:

gzctf-app  | [26-04-27 11:18:11.395 ERR] ExceptionHandlerMiddleware: An unhandled exception has occurred while executing the request.
gzctf-app  | System.InvalidOperationException: Sequence contains more than one element
gzctf-app  |    at System.Linq.ThrowHelper.ThrowMoreThanOneElementException()
gzctf-app  |    at System.Linq.Enumerable.TryGetSingle[TSource](IEnumerable`1 source, Boolean& found)
gzctf-app  |    at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source)
gzctf-app  |    at GZCTF.Services.Container.Manager.DockerManager.CreateContainerAsync(ContainerConfig config, CancellationToken token) in /home/runner/work/GZCTF/GZCTF/src/GZCTF/Services/Container/Manager/DockerManager.cs:line 230
gzctf-app  |    at GZCTF.Controllers.EditController.CreateTestContainer(Int32 id, Int32 cId, CancellationToken token) in /home/runner/work/GZCTF/GZCTF/src/GZCTF/Controllers/EditController.cs:line 776
gzctf-app  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.TaskOfIActionResultExecutor.Execute(ActionContext actionContext, IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
gzctf-app  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Awaited|12_0(ControllerActionInvoker invoker, ValueTask`1 actionResultValueTask)
gzctf-app  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
gzctf-app  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
gzctf-app  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
gzctf-app  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
gzctf-app  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|25_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
gzctf-app  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
gzctf-app  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
gzctf-app  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
gzctf-app  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
gzctf-app  |    at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
gzctf-app  |    at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
gzctf-app  |    at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
gzctf-app  |    at Microsoft.AspNetCore.RateLimiting.RateLimitingMiddleware.InvokeInternal(HttpContext context, EnableRateLimitingAttribute enableRateLimitingAttribute)
gzctf-app  |    at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddlewareImpl.<Invoke>g__Awaited|10_0(ExceptionHandlerMiddlewareImpl middleware, HttpContext context, Task task)

If i define a different port (e.g. 54) it works and the container spawns successfully. Though, not being operational as the target port would be 53.

I could rework the challenge's Dockerfile but still want to report this potential bug.

Expected behavior / 期望行为

Port 53 does not interfere with container creation

Possible fix / 可能的修复

I don't know

[l4rm4nd]

LLM root cause analysis:

In v1.8.4, DockerManager.cs does this:

var portString = config.ExposedPort.ToString();
var bindings = info.NetworkSettings.Ports
    .Where(kv => kv.Key.StartsWith(portString))
    .Select(kv => kv.Value)
    .SingleOrDefault();

For port 53, Docker can report multiple matching keys, commonly 53/tcp and 53/udp. Because both start with "53", .SingleOrDefault() throws:

System.InvalidOperationException: Sequence contains more than one element

That exactly matches the issue log at DockerManager.cs:line 230.

The regression appears to come from commit e9300a5, feat(container): custom network mode for challenges (#534), on Dec 3, 2025. GitHub blame attributes the current var bindings = ... SingleOrDefault() block to that commit.

Older versions like v1.7.2 used:

info.NetworkSettings.Ports
    .FirstOrDefault(p => p.Key.StartsWith(config.ExposedPort.ToString()))
    .Value.First().HostPort;

So multiple 53/* entries did not throw, it just picked the first match.

Suggested fix:

var key = $"{config.ExposedPort}/tcp";

var bindings = info.NetworkSettings.Ports
    .Where(kv => kv.Key == key)
    .Select(kv => kv.Value)
    .SingleOrDefault();

Or more robustly, support protocol explicitly instead of matching only by numeric port. The current StartsWith("53") + SingleOrDefault() combination is the bug.