Call for testers: fxp(4) Rx buffer use after free

[Pyun YongHyeon]

Hi,

It seems that fxp(4) has a long standing races between controller
and driver. The exotic RFD handling of controller is race prone as
we had seen old ethernet controllers. I could easily reproduce this
by rebooting system while netperf 64bytes UDP test is in progress.
If heavy RX frames hit the controller while interface UP is in
progress, controller started DMAing to freed mbufs such that
"Memory modified after free" message showed up. Based on OpenBSD's
patch I made a patch which seems to fix the issue.
If you saw this type of issue please give it try and let me how
it goes on your box. The patch has effect only on interrupt mode so
if you're using polling(4) you would have no effects.
You can get download the patch at the following URL.
http://people.freebsd.org/~yongari/fxp/fxp.rx.race.patch

After applying the patch you may see somewhat increased RNR counter
value from sysctl node(dev.fxp.0.rnr). Previously fxp(4) might have
lower RNR counter value but that fake value came from DMAing to
freed mbufs which was completely wrong.

Thanks.

[Pyun YongHyeon]

Post by Pyun YongHyeon
Hi,
It seems that fxp(4) has a long standing races between controller
and driver. The exotic RFD handling of controller is race prone as
we had seen old ethernet controllers. I could easily reproduce this
by rebooting system while netperf 64bytes UDP test is in progress.
If heavy RX frames hit the controller while interface UP is in
progress, controller started DMAing to freed mbufs such that
"Memory modified after free" message showed up. Based on OpenBSD's
patch I made a patch which seems to fix the issue.
If you saw this type of issue please give it try and let me how
it goes on your box. The patch has effect only on interrupt mode so
if you're using polling(4) you would have no effects.
You can get download the patch at the following URL.
http://people.freebsd.org/~yongari/fxp/fxp.rx.race.patch
After applying the patch you may see somewhat increased RNR counter
value from sysctl node(dev.fxp.0.rnr). Previously fxp(4) might have
lower RNR counter value but that fake value came from DMAing to
freed mbufs which was completely wrong.

Hmm, it seems there are other issues in the patch. I'll post new
patch after fixing this.

Post by Pyun YongHyeon
Thanks.