ppp: fix locking issues related to ppp_ioctl()
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest5 patches 3 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/5 | ppp: lock ppp structure before modifying mru in ppp_ioctl()drivers/ | +3 | 3 replies | |
| 2/5 | ppp: fix unprotected accesses to ppp->flags and ppp->n_channelsdrivers/ | +12 | 0 replies | |
| 3/5 | ppp: protect ppp->debug in ppp_ioctl()drivers/ | +8 | 0 replies | |
| 4/5 | ppp: protect access to ppp->last_{xmit,recv} in ppp_ioctl()drivers/ | +3 | 0 replies | |
| 5/5 | ppp: protect ppp->npmodedrivers/ | +13 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH net 0/5] ppp: fix locking issues related to ppp_ioctl()
This series fixes unprotected accesses to several struct ppp fields. Only fields used in ppp_ioctl() have been considered, though.
Locking of the xstate and rstate fields remains incomplete: although a side effect of patch #2 provides protection in ppp_ioctl(), xstate and rstate can still be modified without appropriate locking by ppp_ccp_peek(). Taking the missing locks in ppp_ccp_peek() isn't possible as this would lead to lock inversion (when protecting xstate with ppp_xmit_lock() while ppp_ccp_peek() is called in the Rx path).
Using a workqueue to run ppp_ccp_peek() might be a solution, but this is left for another series.
Guillaume Nault (5):
ppp: lock ppp structure before modifying mru in ppp_ioctl()
ppp: fix unprotected accesses to ppp->flags and ppp->n_channels
ppp: protect ppp->debug in ppp_ioctl()
ppp: protect access to ppp->last{xmit,recv} in ppp_ioctl()
ppp: protect ppp->npmode
drivers/net/ppp/ppp_generic.c | 42 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 39 insertions(+), 3 deletions(-)
Signature · 1 line
2.7.0