atm: lec: fix null-ptr-deref in lec_arp_clear_vccs

In the Linux kernel, the following vulnerability has been resolved:

atm: lec: fix null-ptr-deref in lec_arp_clear_vccs

syzkaller reported a null-ptr-deref in lec_arp_clear_vccs().

This issue can be easily reproduced using the syzkaller reproducer.

In the ATM LANE (LAN Emulation) module, the same atm_vcc can be shared by

multiple lec_arp_table entries (e.g., via entry->vcc or entry->recv_vcc).

When the underlying VCC is closed, lec_vcc_close() iterates over all

ARP entries and calls lec_arp_clear_vccs() for each matched entry.

For example, when lec_vcc_close() iterates through the hlists in

priv->lec_arp_empty_ones or other ARP tables:

1. In the first iteration, for the first matched ARP entry sharing the VCC,

lec_arp_clear_vccs() frees the associated vpriv (which is vcc->user_back)

and sets vcc->user_back to NULL.

2. In the second iteration, for the next matched ARP entry sharing the same

VCC, lec_arp_clear_vccs() is called again. It obtains a NULL vpriv from

vcc->user_back (via LEC_VCC_PRIV(vcc)) and then attempts to dereference it

via `vcc->pop = vpriv->old_pop`, leading to a null-ptr-deref crash.

Fix this by adding a null check for vpriv before dereferencing

it. If vpriv is already NULL, it means the VCC has been cleared

by a previous call, so we can safely skip the cleanup and just

clear the entry's vcc/recv_vcc pointers.

The entire cleanup block (including vcc_release_async()) is placed inside

the vpriv guard because a NULL vpriv indicates the VCC has already been

fully released by a prior iteration — repeating the teardown would

redundantly set flags and trigger callbacks on an already-closing socket.

The Fixes tag points to the initial commit because the entry->vcc path has

been vulnerable since the original code. The entry->recv_vcc path was later

added by commit 8d9f73c0ad2f ("atm: fix a memory leak of vcc->user_back")

with the same pattern, and both paths are fixed here.