| Message ID | 20210718210006.26212-1-paskripkin@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | net: 802: fix memory leak in garp_uninit_applicant | expand |
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 <kuba@kernel.org> 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
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);
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: syzbot+13ad608e190b5f8ad8a8@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> --- net/802/garp.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)