A conceivable attack is inspired by this extract of LUKS On-Disk Format Specification
Version 1.1.1, section 1:
A partition can have as many user passwords as there are key slots. To
access a partition, the user has to supply only one of these
passwords. If a password is changed, the old copy of the master key
encrypted by the old password must be destroyed. Peter Gutmann has
shown in [Gut96], how data destruction shall be done to maximise the
chance, that no traces are left on the disk. Usually the master key
comprises only 16 or 32 bytes. This small amount of data can easily be
remapped as a whole to a reserved area. This action is taken by modern
hard disk firmware, when a sector is likely to become unreadable due
to mechanical wear. The original sectors become unaccessible and any
traces of key data can’t be purged if necessary.
Assume that a weak or compromised password has been used, then the password changed with hope of restoring security. Due to wear-leveling on the SSD, the master key enciphered using the weak or compromised password may remain physically on the drive, although it is no longer logically mapped. In theory, reading the bare flash in the drive (either physically, or using some undocumented commands that may or may not exist in the SSD firmware, perhaps after loading an instrumented version of that) may allow reading the block(s) still containing the master key enciphered using the weak or compromised password, which in turn trivially breaks the whole encryption. It is hard to tell if the " anti-forensic information splitter " of LUKS can prevent that.
This attack is in theory also relevant in the context of blocks that become bad on traditional hard drives (the original data then becomes logically unmapped while potentially physically there, unless the drive physically erases it after remapping, which is not an advertised feature); but the odds that precisely the block(s) enabling the attack becomes bad are minuscule. The odds are less low with a SSD, especially soon after the password is changed.
TRIM likely impact the odds of the attack to succeed, because it modifies the blocks erased by the wear-leveling algorithm, but I can't tell if that will increase or decrease the odds. I can vaguely imagine algorithms in which the periodical erasing of TRIM makes it unnecessary to use backup means to recover unused space, making it more likely that blocks logically rewritten in seldom rewritten areas still have their former values physically there.
I guess that reading logically-rewritten but still-physically-there blocks in SSD has become a forensic trick for high-value target and some SSD. But I have no indication that the LUKS attack I discuss was ever attempted, much less successful. I would fear, much more, a compromise of password or master key by more traditional means (key-logger, camera, paper backup of password, configuration goof, compromized software, DMA memory grabber..)