user1446: If I am not mistaken the mainline bitcoind will accept unsolicited  addr messages, and upon receiving this message - the struct is deserialized, and then verify each address from the unsolicited sender.  The addr struct allows for up to 1,000 arbitrary addresses:port tuples and there isn't a port restriction... so what exactly is preventing an attacker from flooding the 100k or so Bitciond nodes with the address to some target web servers on 80 and 443?
...To make things more abusable, the client knowingly accepts information drafted in the future, and will retry three times regardless of the error - even on a protocol mismatch. This means that flooding a control-plane service like sshd or a vpn or even an entire IP range of services could cause a lot of problems for a target entity with a large network footprint.
A similar issue to this was exploited on the DC++ network.

user1446: This specific DDoS vulnerability was exploited in 2021, which lead to an emergency patch.  PR #22387 is how Bitcoin prevents DDoS, clients running a version older than v22 may still be used to amplify attacks.

user131606: For a long time, there was a restriction to strongly prefer connecting to addresses with port 8333. This restriction was recently removed in PR 23542 and PR 23306, although a list of "bad ports" was introduced that bitcoin core nodes would still avoid to connect to.
If you send an address to a node, it will often save it in the new table of the AddrMan database (if there is no collision with an existing one), but it won't automatically connect to it. That might happen at some later point when they have less than the default 10 outbound connections and therefore need more, or when they make a periodic feeler connection. But since addresses are gossiped over the bitcoin network all the time, they will know about thousands of potential peers, so they would connect to a specific address of the victim only with a low probability.
So even if you send a victim's address to all bitcoin nodes, that doesn't mean that they would receive so many connections that it would qualify as a DoS attack.
There has been a rough calculation in this post by vasild, which comes to the conclusion that even in the unrealistic scenario where nodes made new connections all the time, the number of connection attempts the victim would receive would be ~2 per second.
In reality, it should be much less because nodes don't make connections all the time - the victim might get the occasional connection attempt from a bitcoin node, but nothing that would qualify as a DDoS attack.
Also note that your verification link from the OP is part  of the AddrMan::Unserialize() function, only used to load saved addresses from the peers.dat file at startup, the function in AddrMan that is executed when receiving addresses from peers is AddrMan::Add().

1446: <p>If I am not mistaken the mainline bitcoind will accept unsolicited  <code>addr</code> messages, and upon receiving this message - the struct is deserialized, and then <a href="https://github.com/bitcoin/bitcoin/blob/62c864605a3d082855dbbb839d969c2ffc7acace/src/addrman.cpp#L396" rel="nofollow noreferrer">verify each address from the unsolicited sender</a>.  The <code>addr</code> struct allows for up to 1,000 arbitrary <code>addresses:port</code> tuples and there isn't a port restriction... so what exactly is preventing an attacker from flooding the 100k or so Bitciond nodes with the address to some target web servers on 80 and 443?</p>
<p>...To make things more abusable, the client <a href="https://github.com/bitcoin/bitcoin/blob/62c864605a3d082855dbbb839d969c2ffc7acace/src/addrman.cpp#L73-L74" rel="nofollow noreferrer">knowingly accepts information drafted in the future</a>, and will <a href="https://github.com/bitcoin/bitcoin/blob/62c864605a3d082855dbbb839d969c2ffc7acace/src/addrman.cpp#L33-L34" rel="nofollow noreferrer">retry three times</a> regardless of the error - even on a protocol mismatch. This means that flooding a control-plane service like sshd or a vpn or even an entire IP range of services could cause a lot of problems for a target entity with a large network footprint.</p>
<p>A similar issue to this was exploited on the <a href="https://www.iiis.org/cds2009/cd2009sci/SCI2009/PapersPdf/S167TT.pdf" rel="nofollow noreferrer">DC++ network</a>.</p>
 1446: <p>This specific <a href="https://arxiv.org/abs/2108.00815v2" rel="nofollow noreferrer">DDoS vulnerability was exploited in 2021</a>, which lead to <a href="https://github.com/bitcoin/bitcoin/pull/22387" rel="nofollow noreferrer">an emergency patch</a>.  PR #22387 is how Bitcoin prevents DDoS, clients running a version older than v22 may still be used to amplify attacks.</p>
 131606: <p>For a long time, there was a restriction to strongly prefer connecting to addresses with port 8333. This restriction was recently removed in <a href="https://github.com/bitcoin/bitcoin/pull/23542" rel="nofollow noreferrer">PR 23542</a> and <a href="https://github.com/bitcoin/bitcoin/pull/23306" rel="nofollow noreferrer">PR 23306</a>, although a <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/p2p-bad-ports.md" rel="nofollow noreferrer">list</a> of &quot;bad ports&quot; was introduced that bitcoin core nodes would still avoid to connect to.</p>
<p>If you send an address to a node, it will often save it in the new table of the AddrMan database (if there is no collision with an existing one), but it won't automatically connect to it. That might happen at some later point when they have less than the default 10 outbound connections and therefore need more, or when they make a periodic <a href="https://bitcoin.stackexchange.com/questions/112247/what-is-a-feeler-connection-when-is-it-used">feeler</a> connection. But since addresses are gossiped over the bitcoin network all the time, they will know about thousands of potential peers, so they would connect to a specific address of the victim only with a low probability.</p>
<p>So even if you send a victim's address to all bitcoin nodes, that doesn't mean that they would receive so many connections that it would qualify as a DoS attack.
There has been a rough calculation in <a href="https://github.com/bitcoin/bitcoin/issues/5150#issuecomment-853888909" rel="nofollow noreferrer">this post</a> by vasild, which comes to the conclusion that even in the unrealistic scenario where nodes made new connections all the time, the number of connection attempts the victim would receive would be ~2 per second.
In reality, it should be much less because nodes don't make connections all the time - the victim might get the occasional connection attempt from a bitcoin node, but nothing that would qualify as a DDoS attack.</p>
<p>Also note that your <a href="https://github.com/bitcoin/bitcoin/blob/207a22877330709e4462e6092c265ab55c8653ac/src/addrman.cpp#L396" rel="nofollow noreferrer">verification link</a> from the OP is part  of the <code>AddrMan::Unserialize()</code> function, only used to load saved addresses from the peers.dat file at startup, the function in AddrMan that is executed when receiving addresses from peers is <code>AddrMan::Add()</code>.</p>
