Yes, you can.
As I understand it, the issue is a new flag 0x800 that is set for split alignment records, used instead of 0x100 for a secondary alignment. Neither Picard nor Samtools understand this flag (yet).
From Heng on the samtools-help mailing list:
Those on the samtools mailing list may know I have proposed to a new SAM flag 0x800 to better describe chimeric alignment. I have also
proposed to standardize the XP tag as SA. The format of SA follows:
"(chr,pos,strand,CIGAR,mapQ,NM;)+". Note that SA separates position
and strand, slightly different from XP. Other samtools developers,
including the Picard group, have seconded the changes. I will write
this to the SAM spec.
The latest bwa-mem at github implements these changes. In the new
output (without option -a), a read may appear in two or more SAM lines
as before. But in this case, one and only one line is NOT flagged with
0x800. This line is called the "primary line" and always uses soft
clipping. The rest of lines are flagged with 0x800. These lines are
called "supplementary lines" and always use hard clipping. Having one
primary line helps operations such as MarkDuplicates, SamToFastq and
FixMateInformation.
Samtools ignores the new flag. Picard may not work with the new bwa-mem output, but it is going to. Before Picard supports the new
0x800 flag, you may still use flag "-M" as before. The only effect of
"-M" is to change 0x800 to 0x100. You may also change 0x800 to 0x100
with a script if you need the compatibility with older Picard but
forget to use "-M" when invoking bwa-mem.
So I think the easiest fix is to write a short script going through the file in sam format and changing the 0x800 flag to 0x100, if it's set. Or even simpler (though lossy), you could exclude reads that have the 0x800 flag set, producing a file that's compatible with current Picard tools.
Or I guess (for completeness) you could patch a local version of Picard to check for 0x800 as well as 0x100...
What's your error message?