FreeBSD -- arc4random(9) predictable sequence vulnerability

Problem Description:
When the arc4random(9) random number generator is
initialized, there may be inadequate entropy to meet the
needs of kernel systems which rely on arc4random(9); and it
may take up to 5 minutes before arc4random(9) is reseeded
with secure entropy from the Yarrow random number generator.
Impact:
All security-related kernel subsystems that rely on a
quality random number generator are subject to a wide range of
possible attacks for the 300 seconds after boot or until 64k
of random data is consumed. The list includes:

• GEOM ELI providers with onetime keys. When a provider is
  configured in a way so that it gets attached at the same time
  during boot (e.g. it uses the rc subsystem to initialize) it
  might be possible for an attacker to recover the encrypted
  data.
• GEOM shsec providers. The GEOM shsec subsytem is used to
  split a shared secret between two providers so that it can be
  recovered when both of them are present. This is done by
  writing the random sequence to one of providers while
  appending the result of the random sequence on the other host
  to the original data. If the provider was created within the
  first 300 seconds after booting, it might be possible for an
  attacker to extract the original data with access to only one
  of the two providers between which the secret data is split.
• System processes started early after boot may receive
  predictable IDs.
• The 802.11 network stack uses arc4random(9) to generate
  initial vectors (IV) for WEP encryption when operating in
  client mode and WEP authentication challenges when operating
  in hostap mode, which may be insecure.
• The IPv4, IPv6 and TCP/UDP protocol implementations rely
  on a quality random number generator to produce unpredictable
  IP packet identifiers, initial TCP sequence numbers and
  outgoing port numbers. During the first 300 seconds after
  booting, it may be easier for an attacker to execute IP
  session hijacking, OS fingerprinting, idle scanning, or in
  some cases DNS cache poisoning and blind TCP data injection
  attacks.
• The kernel RPC code uses arc4random(9) to retrieve
  transaction identifiers, which might make RPC clients
  vulnerable to hijacking attacks.
  Workaround:
  No workaround is available for affected systems.