The Junos kernel may crash when receiving a certain ARP request from a client when a 'family inet' interface:
interfaces { ge-3/0/0 { interface-transmit-statistics; flexible-vlan-tagging; encapsulation flexible-ethernet-services; unit 4000 { arp-resp unrestricted; proxy-arp unrestricted; vlan-tags outer 1 inner 4000; family inet { mac-validate strict; unnumbered-address lo0.0; } } } lo0 { unit 0 { family inet { address 10.0.0.1/24; } } } ge-3/1/0 { unit 0 { family inet { address 20.0.0.2/24; address 10.0.0.4/31; } } } } routing-options { static { route 11.0.0.0/24 next-hop 20.0.0.1; } }
All Junos OS software releases built on or after 2013-06-09 have fixed this specific issue. Releases containing the fix specifically include: 10.4R14, 11.4R8, 11.4X27.43 (BBE), and 12.1X44-D20 (SRX), 12.1R6, 12.2R4, 12.3R2, 13.1R1, and all subsequent releases (i.e. all releases built after 13.1R1). Customers can confirm the build date of any Junos OS release by issuing the command 'show version detail'. This issue is being tracked as PR 842091 and is visible on the Customer Support website. KB16765 [juniper.net] - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies.
How to obtain fixed software: Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version. In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame. For these cases, Service Releases are made available in order to be more timely. Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release. Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request.
If the 'arp-resp unrestricted' and/or 'proxy-arp unrestricted' options are not required, removing either configuration statement will completely mitigate this kernel crash. Additionally, if there is no specific need to use a non-/32 address on the lo0 interface, changing the mask to /32 will also mitigate this issue.