| created | 2021-11-20T18:19:14Z |
|---|---|
| begin | 2021-11-17T00:00:00Z |
| end | 2021-11-18T00:00:00Z |
| path | src/sys |
| commits | 6 |
| date | 2021-11-17T06:20:30Z | |||
|---|---|---|---|---|
| author | anton | |||
| files | src/sys/dev/usb/uhidev.c | log | diff | annotate |
| message |
Fix a double free in uhidev_close() caused by a race between uhidev_open() and uhidev_close(). In uhidev_close() the UHIDEV_OPEN flag is cleared early on but the same thread can end up sleeping while closing the input or output pipe. This allows another thread to enter uhidev_open() but only to fail opening either the input or output pipe since they are already open for exclusive use. The uhidev_open() error path frees the input buffer but leaves a dangling pointer around; causing uhidev_close() to free the same buffer. This can at least happen on xhci(4) which can end up sleeping in xhci_pipe_close(). Reported by and ok gnezdo@ |
|||
| date | 2021-11-17T06:21:23Z | |||
|---|---|---|---|---|
| author | anton | |||
| files | src/sys/dev/usb/ucc.c | log | diff | annotate |
| message | ucc does not claim multiple report ids | |||
| date | 2021-11-17T06:22:14Z | |||
|---|---|---|---|---|
| author | anton | |||
| files | src/sys/dev/usb/uhidpp.c | log | diff | annotate |
| message | uhidpp does claim multiple report ids | |||
| date | 2021-11-17T15:15:32Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/dev/pci/if_iwm.c | log | diff | annotate |
| message |
Disable active scanning on iwm(4) 9260 and 9560. For some reason, if we send a scan command that actively scans for a particular SSID with probe requests, the device will occasionally lock up after associating to the AP, with no interrupts, totally dead. The symptom of this is an interface that shows as "active" in ifconfig but does not receive or transmit any packets. Observed by kmos@ for some time already, and myself while testing new Intel wifi firmware versions on iwm(4) 9560. This problem was also observed on AX200 by me with old firmware. We had the same workaround in place for iwx(4) for some time, until we upgraded that driver to use newer firmware which uses a different scan command. Workaround tested by kmos@ and myself. |
|||
| date | 2021-11-17T18:00:24Z | |||
|---|---|---|---|---|
| author | bket | |||
| files | src/sys/net/if_sppp.h | log | diff | annotate |
| src/sys/net/if_spppsubr.c | log | diff | annotate | |
| message |
Display DNS information from sppp(4) in ifconfig(8) Behaviour is similar to that of umb(4). OK kn@ |
|||
| date | 2021-11-17T22:56:19Z | |||
|---|---|---|---|---|
| author | mvs | |||
| files | src/sys/kern/uipc_usrreq.c | log | diff | annotate |
| message |
When unp_connect() releases both solock() and vnode(9) locks the socket we were connected could be closed by concurrent thread. Check connection state and return ECONNREFUSED if the connection was lost. ok bluhm@ |
|||