qcom_pd_mapper: SERVREG_LOC request handlers do not validate the QMI sender

qcom_pd_mapper: SERVREG_LOC request handlers do not validate the QMI sender

[Kenneth Kabogo]

Hi,

Flagging a hardening gap in the in-kernel protection-domain mapper, found
by code inspection (no proof-of-concept, and I don't have the hardware to
test on at runtime).

qcom_pdm_get_domain_list() and qcom_pdm_pfr() are the two QMI_REQUEST
handlers for the SERVREG_LOC service this driver registers. Neither
validates the sender address (struct sockaddr_qrtr *sq); it is used only
to address the response.

  - qcom_pdm_get_domain_list(): any local sender that can reach the qrtr
    socket can enumerate the registered protection-domain / service list
    for any service name.

  - qcom_pdm_pfr(): any such sender can submit a restart/crash report
    with attacker-controlled service and reason strings. The handler logs
    them via pr_warn_ratelimited() and acks QMI_RESULT_SUCCESS_V01. There
    is no check that the sender owns the domain it is reporting on, and no
    recovery action is taken, so the practical effect is an
    attacker-influenced ratelimited kernel log line.

Impact is low. On Android the qrtr socket is not reachable by untrusted
apps (SELinux neverallow on qipcrtr_socket), so this is gated to
privileged system components, and there is no memory-safety issue. But a
PFR report in particular seems like it should only be accepted from the
entity managing the domain being reported.

Two questions:

  1. Is get_domain_list intended to be an open lookup service for any
     local client, or should it be restricted? If restricted, on what
     basis?

  2. For pfr, would you take a patch that rejects reports for domains the
     sender does not provide (or checks the sender against the registered
     owner of the reported domain)?

Happy to send patches once the intended trust model is clear.

Thanks,
Kenneth Kabogo