https://bugs.kde.org/show_bug.cgi?id=522615

Branislav Klocok <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #6 from Branislav Klocok <[email protected]> ---
Also reproducible on openSUSE Tumbleweed, so this is not distro-specific:

  openSUSE Tumbleweed, Wayland
  kwalletd6 6.28.0
  plasma6-nm 6.7.2, plasmashell 6.7.2
  Qt 6.11.1
  dbus-1 1.14.10
  kernel 7.1.3

THE WRITE ACTUALLY SUCCEEDS - ONLY ITS COMPLETION IS LOST

This seems worth highlighting, because it reframes the bug: it is not that
saving the secret fails. After the loop had been running for hours I dumped the
wallet directly:

  $ kwallet-query -l -f "Network Management" kdewallet
  ... 188 entries ...

  $ kwallet-query -r "{<uuid>};802-11-wireless-security" -f "Network
Management" kdewallet
  (non-empty, contains the psk key, same structure as entries written before
the regression)

So the data lands in the wallet correctly. What never arrives is the
acknowledgement, which matches the "secret_service_real_prompt_async finalized
without ever returning" backtrace and the "ao" vs "o" signature mismatch in the
Completed signal. The client therefore never learns it succeeded and retries
forever.

WHO IS RETRYING

A short "dbus-monitor --profile" capture (3 s, ~34k lines) shows kded6 - the
plasma-nm secret agent - calling org.kde.KWallet.writePassword (plus open and
networkWallet) on kwalletd6 at roughly 22 calls/second, while transient bus
connections hit CreateItem / ReadAlias / Properties.GetAll / StartServiceByName
on org.kde.secretservicecompat at the same rate. This also explains why killing
ksecretd does not help: clients re-activate it immediately.

The item being rewritten is the PSK of the *currently active* wifi connection,
with Created == Modified == now - it is continuously deleted and recreated.
ksecretd signal serials advanced by >1.17M in ~34 minutes (~570 broadcasts/s),
and kdewallet_attributes.json (85 KB) is rewritten constantly, producing an
inotify storm.

TRIGGER AND USER-VISIBLE SYMPTOM

It starts when a *new* wifi network with a password is added. The giveaway is
that the password prompt appears twice - first the inline prompt in the panel,
then a separate dialog. That is the agent not knowing whether the first write
went through.

It is intermittent, not every save - I have hit it only a handful of times over
a long period, on an ordinary WPA2-PSK network (key-mgmt=wpa-psk, PMF disabled)
with nothing to distinguish it from the ~90 other WPA2-PSK networks that saved
fine. Open networks never trigger it, since nothing is written.

WORKAROUND THAT WORKS

  systemctl --user restart plasma-kded6.service

Because the entry is already in the wallet, the restarted agent finds it, has
nothing to write, and the loop cannot re-ignite. Measured immediately after the
restart:

                        during the loop            after restarting kded6
  kwalletd6 RSS         2.7 GB, +600 MB/min        15-20 MB, flat
  ksecretd CPU          ~22 % sustained            0 %
  MOVED_TO events       dozens per second          0
  CPU package temp      81 C                       49 C

The secret stays in the wallet; nothing needs to be moved out of it.

TWO NEGATIVE RESULTS THAT MAY SAVE OTHERS TIME

- "Close When Idle=true" in kwalletrc does NOT help. The loop itself generates
hundreds of accesses per second, so the wallet is never idle and the timer
never fires. Tried it: RSS still reached 2.7 GB and the OOM killer stepped in
twice.

- Killing ksecretd appears to help but only because the wallet locks as a side
effect. Once it is unlocked again the loop resumes. It also comes back without
--pam-login, which breaks the automatic unlock for the rest of the session.

ONE MORE DATA POINT FOR THE ACCUMULATION THEORY

While the wallet was locked, kwalletd6 RSS dropped from 1.7 GB to 663 MB on its
own, and resumed growing after unlocking. So the memory is reachable and tied
to serving requests, which fits accumulating client-side async objects rather
than a classic leak.

Happy to provide the full D-Bus capture or run further instrumentation if
useful.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to