Re: [PATCH net v2] tipc: fix memory leaks in bundle and fragment paths

[xiaoshoukui@gmail.com]

Hi Eric,

Since you previously provided helpful feedback on this thread, I would
appreciate your guidance on the appropriate way to address this TIPC
receive-path issue.

To summarize the current situation:

1. Demonstrated issue:
   Streaming 30,000 crafted TIPC UDP packets to a 4 GB VM reliably triggers
   unconsumed skb memory leaks originating from
   tipc_buf_acquire() -> tipc_msg_extract() -> tipc_link_input() when
   tipc_data_input() returns false. The memory growth eventually results in
   an OOM kernel panic in 14 seconds.

2. Benchmark results:
   I re-ran the benchmark for 10 back-to-back rounds with strict CPU
   affinity. The results did not show any measurable throughput regression
   between the pre-patch and post-patch versions with unlikely().

3. Current review concern:
   Tung rejected the v2 implementation because of the concern that adding
   caller-side cleanup checks may introduce overhead on the fast path, and
   because these malformed inputs are not generated by compliant TIPC
   senders.

Given that the remote memory exhaustion issue is reliably reproducible, 
I would appreciate your thoughts on the preferred netdev/TIPC approach:

- Should the TIPC receive path defensively handle such malformed wire inputs
  to prevent unbounded skb memory consumption and remote DoS?
- If the current caller-side cleanup is not the preferred approach, what would
  be the cleanest way to ensure that the unconsumed skbs are released without
  adding meaningful overhead to the normal receive path?

I am not wedded to the current v2 implementation. I would be happy to explore 
a cleaner, more effective fix based on the maintainers' guidance.

Thanks,
Xiaoshoukui