Syzbot reported memory leak in garp_uninit_applicant(). The problem was
in missing clean up function in garp_uninit_applicant().
The reproducer provided by syzbot doing following things in order:
1. garp_request_join()
garp_attr_event(app, attr, GARP_EVENT_REQ_JOIN);
/* attr->state == GARP_APPLICANT_VP */
2. garp_request_leave()
garp_attr_event(app, attr, GARP_EVENT_REQ_LEAVE);
/* attr->state == GARP_APPLICANT_VO */
3. garp_uninit_applicant()
garp_gid_event(app, GARP_EVENT_TRANSMIT_PDU);
/* attr is not freed */
Why attr won't be freed? Let's refer to garp_applicant_state_table:
[GARP_APPLICANT_VO] = {
[GARP_EVENT_TRANSMIT_PDU] = { .state = GARP_APPLICANT_INVALID },
[GARP_EVENT_R_JOIN_IN] = { .state = GARP_APPLICANT_AO },
[GARP_EVENT_R_JOIN_EMPTY] = { .state = GARP_APPLICANT_VO },
[GARP_EVENT_R_EMPTY] = { .state = GARP_APPLICANT_VO },
[GARP_EVENT_R_LEAVE_IN] = { .state = GARP_APPLICANT_VO },
[GARP_EVENT_R_LEAVE_EMPTY] = { .state = GARP_APPLICANT_VO },
[GARP_EVENT_REQ_JOIN] = { .state = GARP_APPLICANT_VP },
[GARP_EVENT_REQ_LEAVE] = { .state = GARP_APPLICANT_INVALID },
REQ_LEAVE event has INVALID state as standard says and
garp_attr_event() just returns in case of invalid state.
Since garp_uninit_applicant() is destroy function for applicant we need
to free remaining attrs to avoid memory leaks.
Fixes: eca9ebac651f ("net: Add GARP applicant-only participant")
Reported-and-tested-by: [email protected]
Signed-off-by: Pavel Skripkin <[email protected]>
---
net/802/garp.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/net/802/garp.c b/net/802/garp.c
index 400bd857e5f5..4a1ef95ae428 100644
--- a/net/802/garp.c
+++ b/net/802/garp.c
@@ -553,6 +553,16 @@ static void garp_release_port(struct net_device *dev)
kfree_rcu(port, rcu);
}
+static void garp_destroy_remaining_attrs(struct garp_applicant *app)
+{
+ while (!RB_EMPTY_ROOT(&app->gid)) {
+ struct garp_attr *attr =
+ rb_entry(rb_first(&app->gid),
+ struct garp_attr, node);
+ garp_attr_destroy(app, attr);
+ }
+}
+
int garp_init_applicant(struct net_device *dev, struct garp_application *appl)
{
struct garp_applicant *app;
@@ -610,6 +620,13 @@ void garp_uninit_applicant(struct net_device *dev, struct garp_application *appl
spin_lock_bh(&app->lock);
garp_gid_event(app, GARP_EVENT_TRANSMIT_PDU);
garp_pdu_queue(app);
+
+ /* We need to free remaining attrs since this scenario is possible:
+ * garp_request_join()
+ * garp_request_leave()
+ * garp_uninit_applicant()
+ */
+ garp_destroy_remaining_attrs(app);
spin_unlock_bh(&app->lock);
garp_queue_xmit(app);
--
2.32.0
On Mon, 19 Jul 2021 00:00:06 +0300, Pavel Skripkin wrote:
> Syzbot reported memory leak in garp_uninit_applicant(). The problem was
> in missing clean up function in garp_uninit_applicant().
Looks like it's fixed in net by commit 42ca63f98084 ("net/802/garp: fix
memleak in garp_request_join()"), would you mind double checking that fix
and closing the syzbot report manually?
Similar with your MRP patch and commit 996af62167d0 ("net/802/mrp: fix
memleak in mrp_request_join()").
On Mon, 19 Jul 2021 12:05:41 +0200
Jakub Kicinski <[email protected]> wrote:
> On Mon, 19 Jul 2021 00:00:06 +0300, Pavel Skripkin wrote:
> > Syzbot reported memory leak in garp_uninit_applicant(). The problem
> > was in missing clean up function in garp_uninit_applicant().
>
> Looks like it's fixed in net by commit 42ca63f98084 ("net/802/garp:
> fix memleak in garp_request_join()"), would you mind double checking
> that fix and closing the syzbot report manually?
>
> Similar with your MRP patch and commit 996af62167d0 ("net/802/mrp: fix
> memleak in mrp_request_join()").
Hi, Jakub.
Yes, these patches are identical, so I will close the syzbot bugs
manually. Thank you for pointing it out.
With regards,
Pavel Skripkin