6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Bernard Pidoux rose_state3_machine() logs "ROSE: unknown %02X in state 3" at KERN_WARNING for any frame type it does not handle during data transfer. Two of them reach that default arm routinely on real AX.25 links and alarm sysops watching the console, even though they are harmless: - CALL_ACCEPTED (0x0F): a late or duplicated Call Accepted that arrives after the socket has already moved to STATE_3, typically a retransmission on a slow link. - CLEAR_CONFIRMATION (0x17): crossed clearing, or a clear confirmation left over from a previous incarnation of a reused logical channel. In both cases the frame is simply dropped: no state change, no teardown, nothing freed. Only the noise is a problem. Drop these two frame types silently. Keep reporting any other, genuinely unexpected frame type, but through net_warn_ratelimited() so a misbehaving peer cannot flood the kernel log. Signed-off-by: Bernard Pidoux Signed-off-by: Greg Kroah-Hartman --- net/rose/rose_in.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) --- a/net/rose/rose_in.c +++ b/net/rose/rose_in.c @@ -203,7 +203,18 @@ static int rose_state3_machine(struct so break; default: - printk(KERN_WARNING "ROSE: unknown %02X in state 3\n", frametype); + /* + * CALL_ACCEPTED (0x0F) and CLEAR_CONFIRMATION (0x17) may show + * up in state 3 as a late or duplicated Call Accepted, or as + * crossed clearing / a reused logical channel on a slow AX.25 + * link. These are harmless protocol races, so drop them + * silently. Any other frame type is genuinely unexpected and + * is still reported, rate limited to avoid flooding the log. + */ + if (frametype != ROSE_CALL_ACCEPTED && + frametype != ROSE_CLEAR_CONFIRMATION) + net_warn_ratelimited("ROSE: unknown %02X in state 3\n", + frametype); break; }