FreeRADIUS服务器中EAP模块的dedup_key死锁问题分析

问题背景

在FreeRADIUS服务器的EAP认证模块中，当启用dedup_key配置项时，服务器会出现死锁现象。这个问题发生在使用%{Calling-Station-Id}作为去重键的情况下，导致认证过程完全停滞。

问题现象

当在EAP模块配置中取消注释dedup_key = "%{Calling-Station-Id}"这一行时，服务器在处理EAP认证请求时会卡在futex锁上。从日志中可以看到服务器成功展开了Calling-Station-Id的值（如"02-00-00-00-00-01"），但随后就停止了响应。

技术分析

通过GDB调试分析，发现死锁发生在eap_handler_alloc函数中。具体原因是代码中存在连续两次对同一互斥锁的锁定操作：

1. 第一次锁定inst->session_mutex是正常的，用于保护对dedup_tree的访问
2. 在查找并删除旧的handler后，代码错误地再次尝试锁定同一个互斥锁，而不是释放它

这种重复锁定同一个互斥锁的行为导致了线程永久阻塞，因为线程已经持有该锁，无法再次获取。

解决方案

正确的做法应该是：

1. 锁定互斥锁
2. 执行树操作和handler删除
3. 解锁互斥锁

修复方案是确保在操作完成后释放互斥锁，而不是再次尝试获取它。同时，修复还包括了对handler清理流程的优化，确保所有相关的树和列表都能被正确清理。

安全建议

在配置dedup_key时，建议考虑以下安全最佳实践：

1. 考虑使用Called-Station-Id和Calling-Station-Id的组合作为去重键，这样可以增加安全性
2. 避免仅使用客户端提供的标识符作为去重依据，因为恶意客户端可能伪造这些信息
3. 在生产环境中启用此功能前，应在测试环境中充分验证其行为

总结

这个死锁问题展示了在多线程环境下正确管理互斥锁的重要性。即使是经验丰富的开发者也可能在复制粘贴代码时引入这类错误。FreeRADIUS团队迅速响应并修复了这个问题，确保了EAP模块的稳定性和可靠性。

对于系统管理员和网络工程师来说，这个案例也提醒我们在修改关键配置项（如认证相关的参数）时，应该先在测试环境中验证，并准备好回滚方案。