Bug#818652: dovecot-imapd: Crash upon virtual folder selection after update to 1:2.2.21-1
Package: dovecot-imapd
Version: 1:2.2.21-1
Severity: important
Dear Maintainer,
I am seeing a reproducible crash upon selection of one of my virtual folders.
Only one of these virtual folders leads to a crash.
The core dump occurs on my kirkwood box, I am not able to obtain a crash on an
x86_64 VPS with a similar setup.
This setup was working flawlessly before upgrading from 1:2.2.18-2+b1 to
1:2.2.21-1.
This is what appears in syslog:
Mar 19 09:18:20 donkeykong dovecot: imap(sleveque): Fatal: master:
service(imap): child 15037 killed with signal 11 (core dumped)
Mar 19 09:18:21 donkeykong dovecot: imap(sleveque): Fatal: master:
service(imap): child 15040 killed with signal 11 (core dumped)
Mar 19 09:18:22 donkeykong dovecot: imap(sleveque): Fatal: master:
service(imap): child 15042 killed with signal 11 (core dumped)
Mar 19 09:18:22 donkeykong dovecot: imap(sleveque): Fatal: master:
service(imap): child 15044 killed with signal 11 (core dumped)
Mar 19 09:24:55 donkeykong dovecot: imap(sleveque): Fatal: master:
service(imap): child 15242 killed with signal 11 (core dumped)
Mar 19 09:25:14 donkeykong dovecot: imap(sleveque): Fatal: master:
service(imap): child 15257 killed with signal 11 (core dumped)
Mar 19 09:25:31 donkeykong dovecot: imap(sleveque): Fatal: master:
service(imap): child 15276 killed with signal 11 (core dumped)
Mar 19 09:25:38 donkeykong dovecot: imap(sleveque): Fatal: master:
service(imap): child 15288 killed with signal 11 (core dumped)
Mar 19 09:25:41 donkeykong dovecot: imap(sleveque): Fatal: master:
service(imap): child 15292 killed with signal 11 (core dumped)
Here is the content of the imapfilter script I run to test dovecot.
$ cat test_dovecot_crash.lua
options.certificates = false
localhost = IMAP {
server = 'localhost',
username = 'sleveque',
password = 'password',
ssl = 'tls1'
}
mails = localhost['Tous les messages']:is_newer(1)
mails = localhost['Raccourcis/Feeds récents']:is_newer(1)
-- Crash on next select
mails = localhost['Raccourcis/Messages récents']:is_newer(1)
Here is the output until a Ctrl+C when it starts reissuing the request several
times.
$ imapfilter -v -c test_dovecot_crash.lua
S (4): * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
IDLE AUTH=PLAIN] Dovecot ready.
C (4): 1000 CAPABILITY
S (4): 1000 OK Pre-login capabilities listed, post-login capabilities have more.
C (4): 1001 LOGIN "sleveque" *
S (4): 1001 OK Logged in
C (4): 1002 CAPABILITY
S (4): 1002 OK Capability completed.
C (4): 1003 NAMESPACE
S (4): 1003 OK Namespace completed.
C (4): 1004 SELECT "Tous les messages"
S (4): 1004 OK [READ-WRITE] Select completed (0.000 + 0.000 secs).
C (4): 1005 UID SEARCH ALL SINCE 18-Mar-2016
S (4): 1005 OK Search completed (5.658 + 0.001 secs).
C (4): 1006 SELECT "Raccourcis/Feeds r&AOk-cents"
S (4): 1006 OK [READ-WRITE] Select completed (0.000 + 0.000 secs).
C (4): 1007 UID SEARCH ALL SINCE 18-Mar-2016
S (4): 1007 OK Search completed (0.295 + 0.000 secs).
C (4): 1008 SELECT "Raccourcis/Messages r&AOk-cents"
imapfilter: reading data through SSL; the connection has been closed cleanly
S (5): * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
IDLE AUTH=PLAIN] Dovecot ready.
C (5): 1009 CAPABILITY
S (5): 1009 OK Pre-login capabilities listed, post-login capabilities have more.
C (5): 100A LOGIN "sleveque" *
S (5): 100A OK Logged in
C (5): 100B CAPABILITY
S (5): 100B OK Capability completed.
C (5): 100C NAMESPACE
S (5): 100C OK Namespace completed.
C (5): 100D SELECT "Raccourcis/Feeds r&AOk-cents"
S (5): 100D OK [READ-WRITE] Select completed (0.000 + 0.000 secs).
C (5): 100E SELECT "Raccourcis/Messages r&AOk-cents"
imapfilter: reading data through SSL; the connection has been closed cleanly
S (6): * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
IDLE AUTH=PLAIN] Dovecot ready.
C (6): 100F CAPABILITY
S (6): 100F OK Pre-login capabilities listed, post-login capabilities have more.
C (6): 1010 LOGIN "sleveque" *
S (6): 1010 OK Logged in
C (6): 1011 CAPABILITY
S (6): 1011 OK Capability completed.
C (6): 1012 NAMESPACE
S (6): 1012 OK Namespace completed.
C (6): 1013 SELECT "Raccourcis/Feeds r&AOk-cents"
S (6): 1013 OK [READ-WRITE] Select completed (0.000 + 0.000 secs).
C (6): 1014 SELECT "Raccourcis/Messages r&AOk-cents"
imapfilter: reading data through SSL; the connection has been closed cleanly
S (7): * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
IDLE AUTH=PLAIN] Dovecot ready.
C (7): 1015 CAPABILITY
S (7): 1015 OK Pre-login capabilities listed, post-login capabilities have more.
C (7): 1016 LOGIN "sleveque" *
S (7): 1016 OK Logged in
C (7): 1017 CAPABILITY
S (7): 1017 OK Capability completed.
C (7): 1018 NAMESPACE
S (7): 1018 OK Namespace completed.
C (7): 1019 SELECT "Raccourcis/Feeds r&AOk-cents"
S (7): 1019 OK [READ-WRITE] Select completed (0.000 + 0.000 secs).
C (7): 101A SELECT "Raccourcis/Messages r&AOk-cents"
^Cimapfilter: killed by signal 2
The s
Bug#803255: exim4: segfault upon reading /etc/email-addresses
Package: exim4
Version: 4.86-4
Severity: important
Dear Maintainer,
After upgrading from exim4 4.86-3 to 4.86-4, I observe a segfault when
/etc/email-addresses is looked up by sendmail/exim and an entry with a
rewriting rule is found. These mails don't get sent.
Commenting out the corresponding line in /etc/email-addresses fixes the
problem.
I am seeing this segfault on armel, but not on amd64.
# cat /etc/email-addresses
# This is /etc/email-addresses. It is part of the exim package
#
# This file contains email addresses to use for outgoing mail. Any local
# part not in here will be qualified by the system domain as normal.
#
# It should contain lines of the form:
#
#user: some...@isp.com
#otheruser: someonee...@anotherisp.com
sleveque: sylv...@gromi.net
monit@donkeykong: sylv...@gromi.net
root: sylv...@gromi.net
# echo "Subject: test" | /usr/lib/sendmail -v sylv...@gromi.net
Segmentation fault
# echo "Subject: test" | strace /usr/lib/sendmail -v sylv...@gromi.net
[snip]
rt_sigaction(SIGTERM, {0xb6ec3b4c, [TERM], SA_RESTORER|SA_RESTART, 0xb68accf0},
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0xb6ec3b4c, [INT], SA_RESTORER|SA_RESTART, 0xb68accf0},
{SIG_DFL, [], 0}, 8) = 0
fstat64(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6e58000
read(0, "Subject: test\n", 4096)= 14
read(0, "", 4096) = 0
open("/etc/email-addresses", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=400, ...}) = 0
fstat64(4, {st_mode=S_IFREG|0644, st_size=400, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6e57000
_llseek(4, 0, [0], SEEK_SET)= 0
read(4, "# This is /etc/email-addresses. "..., 4096) = 400
read(4, "", 4096) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xc8b80b28} ---
+++ killed by SIGSEGV +++
Segmentation fault
# cat /etc/email-addresses
# This is /etc/email-addresses. It is part of the exim package
#
# This file contains email addresses to use for outgoing mail. Any local
# part not in here will be qualified by the system domain as normal.
#
# It should contain lines of the form:
#
#user: some...@isp.com
#otheruser: someonee...@anotherisp.com
sleveque: sylv...@gromi.net
monit@donkeykong: sylv...@gromi.net
#root: sylv...@gromi.net
# echo "Subject: test" | /usr/lib/sendmail -v sylv...@gromi.net
LOG: MAIN
<= r...@donkeykong.gromi.net U=root P=local S=358
donkeykong:~# delivering 1ZrPx0-0002Kr-GX
R: smarthost for sylv...@gromi.net
T: remote_smtp_smarthost for sylv...@gromi.net
Connecting to XXX:25 ... connected
SMTP<< 220 ESMTP Postfix
SMTP>> EHLO donkeykong.gromi.net
SMTP<< 250-
250-PIPELINING
250-SIZE 3500
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
SMTP>> STARTTLS
SMTP<< 220 2.0.0 Ready to start TLS
SMTP>> EHLO donkeykong.gromi.net
SMTP<< 250-
250-PIPELINING
250-SIZE 3500
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
SMTP>> MAIL FROM: SIZE=1390
SMTP>> RCPT TO:
SMTP>> DATA
SMTP<< 250 2.1.0 Ok
SMTP<< 250 2.1.5 Ok
SMTP<< 354 End data with .
SMTP>> writing message and terminating "."
SMTP<< 250 2.0.0 Ok: queued as 8F372D480B3
SMTP>> QUIT
LOG: MAIN
=> sylv...@gromi.net R=smarthost T=remote_smtp_smarthost H=X
[XX] X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 CV=no
DN="OU=GT42558204,OU=See www.rapidssl.com/resources/cps (c)15,OU=Domain Control
Validated - RapidSSL(R),CN=" C="250 2.0.0 Ok: queued as 8F372D480B3"
LOG: MAIN
Completed
-- Package-specific info:
Exim version 4.86 #3 built 17-Oct-2015 13:01:01
Copyright (c) University of Cambridge, 1995 - 2015
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2015
Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM DNSSEC PRDR
OCSP
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (50, 'unstable'), (40, 'experimental')
Architecture: armel (armv5tel)
Kernel: Linux 3.15-rc8-kirkwood
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages exim4 depends on:
ii debconf [debconf-2.0] 1.5.57
ii exim4-base 4.86-4
Bug#735172: linux: Upgrade to linux-image-3.12-1-kirkwood prevents QNAP TS-119 from booting
Package: linux Version: 3.12.6-2 Severity: important Dear Maintainer, I upgraded a QNAP TS-119 from linux-image-3.11-2-kirkwood to linux-image-3.12-1-kirkwood. dpkg.log states: 2014-01-06 14:37:08 upgrade linux-image-kirkwood:armel 3.11+54 3.12+55 On the next reboot, the NAS was stuck early. I gave it a whole afternoon to boot, initially thinking an fsck was going on (which can take some time on a slow CPU with a large drive). I used the recovery console to get more information and instructions from http://cyrius.com/debian/kirkwood/qnap/ts-119/uboot/ to get back to normal, by reflashing linux-image-3.11-2-kirkwood over the failing 3.12. I suspect http://comments.gmane.org/gmane.linux.debian.ports.arm/13582 to be the same issue on a close hardware. Here is the boot log from the console: __ __ _ _ | \/ | __ _ _ _| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_|\_/ \___|_|_| _ _ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/|/ \___/ \___/ \__| ** LOADER ** ** MARVELL BOARD: DB-88F6281A-BP LE U-Boot 1.1.4 (Feb 9 2009 - 11:13:32) Marvell version: 3.4.4 U-Boot code: 0060 -> 0067FFF0 BSS: -> 00690DCC Soc: 88F6281 A0 (DDR2) CPU running @ 1200Mhz L2 running @ 400Mhz SysClock = 400Mhz , TClock = 200Mhz DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 DRAM CS[0] base 0x size 256MB DRAM CS[1] base 0x1000 size 256MB DRAM Total size 512MB 16bit width [16384kB@f800] Flash: 16 MB Addresses 8M - 0M are saved for the U-Boot usage. Mem malloc Initialization (8M - 7M): Done CPU : Marvell Feroceon (Rev 1) Streaming disabled Write allocate disabled USB 0: host mode PEX 0: interface detected no Link. Net: egiga0 [PRIME] Marvell Serial ATA Adapter Integrated Sata device found [0 0 0]: Enable DMA mode Device 0 @ 0 0: Model: WDC WD10EADS-00L5B1 Firm: 01.01A01 Ser#: WD-WCAU4D159618 Type: Hard Disk Supports 48-bit addressing Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512) Hit any key to stop autoboot: 0 ## Booting image at 0080 ... Image Name: kernel 3.12-1-kirkwood Created: 2014-01-12 12:05:37 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1929800 Bytes = 1.8 MB Load Address: 8000 Entry Point: 8000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Thank you -- Sylvain -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (50, 'unstable'), (40, 'experimental') Architecture: armel (armv5tel) Kernel: Linux 3.11-2-kirkwood Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733608: jhead: Comment removed when adjusting time
Package: jhead
Version: 1:2.97-1
Severity: normal
Dear Maintainer,
While adjusting some EXIF dates on pictures, the observed change between the
original picture and the jhead-ed one goes beyond time modifications of the
corresponding tags.
The default EXIF comment from my camera is a sequence of spaces, which
translates inside the header to "ASCII\0\0\0 " (36 spaces
overall).
This is basically my workflow:
cp -p DSC.JPG DSC_orig.JPG
jhead -ta-1 DSC.JPG
hexdump -Cv DSC_orig.JPG > DSC_orig.txt
hexdump -Cv DSC.JPG > DSC.txt
`diff DSC_orig.txt DSC.txt` returns
17c17
< 0100 32 3a 32 35 3a 35 35 00 20 20 20 20 20 20 20 20 |2:25:55.|
---
> 0100 31 3a 32 35 3a 35 35 00 20 20 20 20 20 20 20 20 |1:25:55.|
56,57c56,57
< 0370 3a 31 32 3a 32 35 20 31 32 3a 32 35 3a 35 35 00 |:12:25 12:25:55.|
< 0380 32 30 31 33 3a 31 32 3a 32 35 20 31 32 3a 32 35 |2013:12:25 12:25|
---
> 0370 3a 31 32 3a 32 35 20 31 31 3a 32 35 3a 35 35 00 |:12:25 11:25:55.|
> 0380 32 30 31 33 3a 31 32 3a 32 35 20 31 31 3a 32 35 |2013:12:25 11:25|
60,62c60,62
< 03b0 00 00 00 0a 41 53 43 49 49 00 00 00 20 20 20 20 |ASCII...|
< 03c0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 ||
< 03d0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 ||
---
> 03b0 00 00 00 0a 41 53 43 49 49 00 00 00 00 00 00 00 |ASCII...|
> 03c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
> 03d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
I expect the output to be
17c17
< 0100 32 3a 32 35 3a 35 35 00 20 20 20 20 20 20 20 20 |2:25:55.|
---
> 0100 31 3a 32 35 3a 35 35 00 20 20 20 20 20 20 20 20 |1:25:55.|
56,57c56,57
< 0370 3a 31 32 3a 32 35 20 31 32 3a 32 35 3a 35 35 00 |:12:25 12:25:55.|
< 0380 32 30 31 33 3a 31 32 3a 32 35 20 31 32 3a 32 35 |2013:12:25 12:25|
---
> 0370 3a 31 32 3a 32 35 20 31 31 3a 32 35 3a 35 35 00 |:12:25 11:25:55.|
> 0380 32 30 31 33 3a 31 32 3a 32 35 20 31 31 3a 32 35 |2013:12:25 11:25|
I tracked the issue down to exif.c where the code takes conditional actions on
the comment field. It will remove trailing spaces and replace them with \0,
then conditionnally copy the comment if one of the five first characters after
the 'ASCII' string is different from a space of \0.
I expect this situation to lead to a corner case bug (untested): a comment
starting with several spaces will be wiped when adjusting time.
I also think this happens upon creation of the modified file and is likely not
limited to the -ta option.
The issue is not Debian specific but in the upstream code. A patch is attached
to suggest a more conservative behaviour of jhead.
Thank you
--
Sylvain
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (50, 'unstable'), (40, 'experimental')
Architecture: armel (armv5tel)
Kernel: Linux 3.11-2-kirkwood
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages jhead depends on:
ii libc6 2.17-97
ii libjpeg-progs 8d-2
jhead recommends no packages.
Versions of packages jhead suggests:
ii imagemagick 8:6.7.7.10-7
-- no debconf information
diff -ru jhead.orig/jhead-2.97/exif.c jhead/jhead-2.97/exif.c
--- jhead.orig/jhead-2.97/exif.c 2013-01-30 18:02:56.0 +0100
+++ jhead/jhead-2.97/exif.c 2013-12-30 12:16:47.037757973 +0100
@@ -663,33 +663,12 @@
break; // Already have a windows comment, skip this one.
}
-// Comment is often padded with trailing spaces. Remove these first.
-for (a=ByteCount;;){
-a--;
-if ((ValuePtr)[a] == ' '){
-(ValuePtr)[a] = '\0';
-}else{
-break;
-}
-if (a == 0) break;
-}
-
// Copy the comment
{
int msiz = ExifLength - (ValuePtr-OffsetBase);
if (msiz > ByteCount) msiz = ByteCount;
if (msiz > MAX_COMMENT_SIZE-1) msiz = MAX_COMMENT_SIZE-1;
-if (msiz > 5 && memcmp(ValuePtr, "ASCII",5) == 0){
-for (a=5;a<10 && a < msiz;a++){
-int c = (ValuePtr)[a];
-if (c != '\0' && c != ' '){
-strncpy(ImageInfo.Comments, (char *)ValuePtr+a, msiz-a);
-break;
-}
-}
-}else{
-strncpy(ImageInfo.Comments, (char *)ValuePtr, msiz);
-}
+strncpy(ImageInfo.Comments, (char *)ValuePtr, msiz);
}
break
Bug#726138: dspam css file size dramatically increased after upgrade
Package: dspam Version: 3.10.2+dfsg-10 Severity: important Dear Maintainer, After upgrading from 3.10.2+dfsg-9 to 3.10.2+dfsg-10, the size of the css file located in /var/spool/dspam/data/local/$USER/$USER.css increased from around 4.5MB to 2.6GB. It couldn't grow any longer, as it had filled the disk of the VPS, which in turn broke lots of services on this system. After stopping dspam, deleting the large css file and rebooting, a new css file was created, which is now of 1.6GB, leaving some spare disk on the VPS. The upgrade log: # grep dspam /var/log/dpkg.log | grep upgrade 2013-10-11 15:08:18 upgrade dspam:amd64 3.10.2+dfsg-9 3.10.2+dfsg-10 2013-10-11 15:08:18 upgrade libdspam7-drv-hash:amd64 3.10.2+dfsg-9 3.10.2+dfsg-10 2013-10-11 15:08:18 upgrade libdspam7:amd64 3.10.2+dfsg-9 3.10.2+dfsg-10 2013-10-11 15:08:44 upgrade dspam-webfrontend:all 3.10.2+dfsg-9 3.10.2+dfsg-10 Please find attached the evolution of the disk space over time that highlights the issue upon upgrading. I am the only user on this machine, so I don't know if the same issue would affect other css files or not. I have backups of the files before and after upgrade if more information is required. Thank you -- Sylvain -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.50-xenU-8149-x86_64 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dspam depends on: ii libc6 2.17-93 ii libdspam7 3.10.2+dfsg-10 ii libdspam7-drv-hash 3.10.2+dfsg-10 ii libpq5 9.3.0-2 ii lsb-base4.1+Debian12 ii perl5.18.1-4 Versions of packages dspam recommends: pn dspam-doc ii procmail 3.22-20 Versions of packages dspam suggests: ii clamav-daemon 0.97.8+dfsg-1 ii dspam-webfrontend 3.10.2+dfsg-10 <>
Bug#650373: isync: Overlapping memcpy leads to "IMAP error: unexpected tag" error
Package: isync Version: 1.0.4-2.1+b1 Severity: normal Hello mbsync stopped working for me this week-end with an "IMAP error: unexpected tag" error. I tracked down the issue to a call to memcpy with no check on potential overlaps. It appears this bug was corrected in 2006: http://isync.git.sourceforge.net/git/gitweb.cgi?p=isync/isync;a=commitdiff;h=617d1a6e4983a6c0903b46652ee502a804a312ee -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.36-xenU-4814-i386 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages isync depends on: ii libc62.13-21 ii libdb5.1 5.1.25-11 ii libssl1.0.0 1.0.0e-2 isync recommends no packages. Versions of packages isync suggests: pn mutt -- no debconf information Fix potential overlap in memcpy See http://isync.git.sourceforge.net/git/gitweb.cgi?p=isync/isync;a=commitdiff;h=617d1a6e4983a6c0903b46652ee502a804a312ee --- a/src/drv_imap.c +++ b/src/drv_imap.c @@ -376,7 +376,7 @@ n = b->bytes - start; if (n) - memcpy( b->buf, b->buf + start, n ); + memmove( b->buf, b->buf + start, n ); b->offset -= start; b->bytes = n; start = 0;
