RETURNED MAIL: SEE TRANSCRIPT FOR DETAILS

[Bounced mail]

IˆªG«–±ô«ª?¦þtw2õèÚÁ*âV‰gÉûm
h†§”µ ÔÂYºÅ·ìžÉŽG±?Eéâ$B2ÙF–i²•úørnÍçƒÔ§S1»ÆwÜR òmúýúF?¤Êª}K–O˲RȲqQûˆá·tU
W5•{ï•aŒiÜu‚—VOþÕÚÚ¿,û†LµÊÓðêußê‚T™Äˆ˜ÀÍÇàTbÞU*(Ÿ8¼(_xšxïSoK$F­Š(ÅUP÷´~näïÕç‹ãði%Û¬í´Á/ˆ1ŠÑA«duR:Æû‡É鸣7¾·D»ø.DúsÖ
 _îkzš
Ž.˜¶b✽Òh•]µ
#Ñ£ÖýИE‘›ü)á?#fžØåÖ.Õ<‘Q{•™;È.ûï¸Vw5
 ‹Ç3H预‡‚éFw¨äe`‰uA?Ùû9;"7oÂÄ(äƒÜßÑäܕV‹{œAìÜVo^yƒìCôW°CãJ÷íL[
0É6<é­
X´„`ƒÀ¬DÞã'Ǥ¶ôxÁæ(B¿æ°çZªyú?µ§ÅC½²Áðð¤Êñ%øПw‘ƇÑÅ´çvÝ45
{˜õ˜H©;lëÚ¦2ÝEßé˜ô¸û|`XK·(é9þŠs#O?kCïGSçÜZ3ö\–s
§E8Qú
9¤â°`úŸêVûïiq74¹%;îQ&åqŠ'Ï'
¸UIÇÞBˆQÊ&8áìÔc¤ä2¡Ò‰Œn/uË×|]AèºUE ]§v0(.Y¥î}ýQš¹J*¨
3g°ÝM©E˜pÊ|Î?z%.5F‹ˆ÷]o뒉®]¨Loì6-¹}~1Ù9Uex–AU"ñóB¾Ðd˜ìy‚FáeNiòÎSsYª‹a³Zö׋ŠŽ¡¡&·ŒÚmŽÆæÒÀr0„D{9ÊXB²•[GmÒÔ
’¯kº&*Òàg”¥7‚PÄÅÝ°˜ %šLU$A7ÉáÕù”³xłɿãß5-û—Ø’£M™–¦CàÐTIܾ4EÕzq”Ò?ëö®¨›ý¾‡OÕT
TµÕÔ4
˅)`ÝÖ-úX¡ze¯ð{wj„óù¢Rw*‰î¢mÕ~'hÓ²ÉtҔÕqVPö$E„ã逸.«®Pzæϯ>ãà 
ÎçM:þiU©LæYZ_^·ØŽ•ÇÚ·ÏÜòË®i0^vǨ!:×]¢ØnñOð!ç÷Ð-˜Æ6tÌ! í£nɎþ:;ÇCÈLê¢-m3|
Rñç;íEÎíx¸´Ä³þê”!

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH] nvdimm: move the check on nd_reserved2 to the endpoint

[Dan Williams]

On Mon, Sep 4, 2017 at 8:34 AM, Meng Xu  wrote:
> This patch delays the check of nd_reserved2 to the actual endpoint
> (acpi_nfit_ctl) that uses it, as a prevention of a potential
> double-fetch bug.
>
> Detailed discussion can be found at
> https://marc.info/?l=linux-kernel=150421938113092=2

Thanks for doing this, I went ahead and copied this discussion into
the patch and applied it.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH] dax: fix FS_DAX=n BLOCK=y compilation

[Dan Williams]

On Mon, Sep 4, 2017 at 3:26 AM, Jan Kara  wrote:
> On Sun 03-09-17 10:25:55, Dan Williams wrote:
>> The 0day kbuild robot reports:
>>
>> >> drivers//dax/super.c:64:20: error: redefinition of 'fs_dax_get_by_bdev'
>> struct dax_device *fs_dax_get_by_bdev(struct block_device *bdev)
>>^~
>>In file included from drivers//dax/super.c:22:0:
>>include/linux/dax.h:76:34: note: previous definition of 
>> 'fs_dax_get_by_bdev' was here
>> static inline struct dax_device *fs_dax_get_by_bdev(struct block_device 
>> *bdev)
>>  ^~
>>
>> Protect the definition of fs_dax_get_by_bdev() in drivers/dax/super.c
>> with an ifdef.
>>
>> Fixes: 78f354735081 ("dax: introduce a fs_dax_get_by_bdev() helper")
>> Cc: Jan Kara 
>> Cc: Christoph Hellwig 
>> Cc: Darrick J. Wong 
>> Reported-by: kbuild test robot 
>> Signed-off-by: Dan Williams 
>
> OK, or you could have both !DAX and DAX implementations in
> include/linux/dax.h as inline together? It would look a bit more logical to
> me. But I don't care much. So
>
> Reviewed-by: Jan Kara 

My motivation for not doing that is to avoid including blkdev.h from dax.h.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH] nvdimm: fix potential double-fetch bug

[Meng Xu]

Hi Dan,

I have adjusted the patch as suggested by moving the check
on nd_reserved2 to acpi_nfit_ctl(). The new patch can be found
at https://marc.info/?l=linux-kernel=150453930712916=2

Best Regards,
Meng

On 08/31/2017 06:42 PM, Dan Williams wrote:

[ adding Jerry ]

On Wed, Aug 23, 2017 at 2:07 PM, Meng Xu  wrote:

From: Meng Xu 

While examining the kernel source code, I found a dangerous operation that
could turn into a double-fetch situation (a race condition bug) where
the same userspace memory region are fetched twice into kernel with sanity
checks after the first fetch while missing checks after the second fetch.

In the case of _IOC_NR(ioctl_cmd) == ND_CMD_CALL:

1. The first fetch happens in line 935 copy_from_user(, p, sizeof(pkg)

2. subsequently `pkg.nd_reserved2` is asserted to be all zeroes
(line 984 to 986).

3. The second fetch happens in line 1022 copy_from_user(buf, p, buf_len)

4. Given that `p` can be fully controlled in userspace, an attacker can
race condition to override the header part of `p`, say,
`((struct nd_cmd_pkg *)p)->nd_reserved2` to arbitrary value
(say nine 0x for `nd_reserved2`) after the first fetch but before the
second fetch. The changed value will be copied to `buf`.

5. There is no checks on the second fetches until the use of it in
line 1034: nd_cmd_clear_to_send(nvdimm_bus, nvdimm, cmd, buf) and
line 1038: nd_desc->ndctl(nd_desc, nvdimm, cmd, buf, buf_len, _rc)
which means that the assumed relation, `p->nd_reserved2` are all zeroes might
not hold after the second fetch. And once the control goes to these functions
we lose the context to assert the assumed relation.

6. Based on my manual analysis, `p->nd_reserved2` is not used in function
`nd_cmd_clear_to_send` and potential implementations of `nd_desc->ndctl`
so there is no working exploit against it right now. However, this could
easily turns to an exploitable one if careless developers start to use
`p->nd_reserved2` later and assume that they are all zeroes.

Proposed patch:

The patch explicitly overrides `buf->nd_reserved2` after the second fetch with
the value `pkg.nd_reserved2` from the first fetch. In this way, it is assured
that the relation, `buf->nd_reserved2` are all zeroes, holds after the second
fetch.

Signed-off-by: Meng Xu 
---
  drivers/nvdimm/bus.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index 937fafa..20c4d0f 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -1024,6 +1024,12 @@ static int __nd_ioctl(struct nvdimm_bus *nvdimm_bus, 
struct nvdimm *nvdimm,
 goto out;
 }

+   if (cmd == ND_CMD_CALL) {
+   struct nd_cmd_pkg *hdr = (struct nd_cmd_pkg *)buf;
+   memcpy(hdr->nd_reserved2, pkg.nd_reserved2,
+   sizeof(pkg.nd_reserved2));
+   }
+

I think we're ok because the end point like acpi_nfit_ctl() is
responsible for re-validating the buffer. So what I would rather like
to see is deleting this loop:

 for (i = 0; i < ARRAY_SIZE(pkg.nd_reserved2); i++)
 if (pkg.nd_reserved2[i])
 return -EINVAL;

...from __nd_ioctl() and move it into acpi_nfit_ctl() directly where it belongs.


___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[PATCH] nvdimm: move the check on nd_reserved2 to the endpoint

[Meng Xu]

This patch delays the check of nd_reserved2 to the actual endpoint
(acpi_nfit_ctl) that uses it, as a prevention of a potential
double-fetch bug.

Detailed discussion can be found at
https://marc.info/?l=linux-kernel=150421938113092=2

Signed-off-by: Meng Xu 
---
 drivers/acpi/nfit/core.c | 4 
 drivers/nvdimm/bus.c | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 19182d0..694b1b1 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -228,6 +228,10 @@ int acpi_nfit_ctl(struct nvdimm_bus_descriptor *nd_desc, 
struct nvdimm *nvdimm,
if (cmd == ND_CMD_CALL) {
call_pkg = buf;
func = call_pkg->nd_command;
+
+   for (i = 0; i < ARRAY_SIZE(call_pkg->nd_reserved2); i++)
+   if (call_pkg->nd_reserved2[i])
+   return -EINVAL;
}
 
if (nvdimm) {
diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index 937fafa..0fb9adb 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -980,10 +980,6 @@ static int __nd_ioctl(struct nvdimm_bus *nvdimm_bus, 
struct nvdimm *nvdimm,
dev_dbg(dev, "%s:%s, idx: %llu, in: %zu, out: %zu, len %zu\n",
__func__, dimm_name, pkg.nd_command,
in_len, out_len, buf_len);
-
-   for (i = 0; i < ARRAY_SIZE(pkg.nd_reserved2); i++)
-   if (pkg.nd_reserved2[i])
-   return -EINVAL;
}
 
/* process an output envelope */
-- 
2.7.4

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH] dax: fix FS_DAX=n BLOCK=y compilation

[Jan Kara]

On Sun 03-09-17 10:25:55, Dan Williams wrote:
> The 0day kbuild robot reports:
> 
> >> drivers//dax/super.c:64:20: error: redefinition of 'fs_dax_get_by_bdev'
> struct dax_device *fs_dax_get_by_bdev(struct block_device *bdev)
>^~
>In file included from drivers//dax/super.c:22:0:
>include/linux/dax.h:76:34: note: previous definition of 
> 'fs_dax_get_by_bdev' was here
> static inline struct dax_device *fs_dax_get_by_bdev(struct block_device 
> *bdev)
>  ^~
> 
> Protect the definition of fs_dax_get_by_bdev() in drivers/dax/super.c
> with an ifdef.
> 
> Fixes: 78f354735081 ("dax: introduce a fs_dax_get_by_bdev() helper")
> Cc: Jan Kara 
> Cc: Christoph Hellwig 
> Cc: Darrick J. Wong 
> Reported-by: kbuild test robot 
> Signed-off-by: Dan Williams 

OK, or you could have both !DAX and DAX implementations in
include/linux/dax.h as inline together? It would look a bit more logical to
me. But I don't care much. So

Reviewed-by: Jan Kara 

Honza


> ---
>  drivers/dax/super.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index b699aac268a6..3600ff786646 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -61,6 +61,7 @@ int bdev_dax_pgoff(struct block_device *bdev, sector_t 
> sector, size_t size,
>  }
>  EXPORT_SYMBOL(bdev_dax_pgoff);
>  
> +#if IS_ENABLED(CONFIG_FS_DAX)
>  struct dax_device *fs_dax_get_by_bdev(struct block_device *bdev)
>  {
>   if (!blk_queue_dax(bdev->bd_queue))
> @@ -68,6 +69,7 @@ struct dax_device *fs_dax_get_by_bdev(struct block_device 
> *bdev)
>   return fs_dax_get_by_host(bdev->bd_disk->disk_name);
>  }
>  EXPORT_SYMBOL_GPL(fs_dax_get_by_bdev);
> +#endif
>  
>  /**
>   * __bdev_dax_supported() - Check if the device supports dax for filesystem
> 
-- 
Jan Kara 
SUSE Labs, CR
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

回复：塑胶（料）件的相关知识如何进行系统的整理

[侯别]

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Mail System Error - Returned Mail

[kim]

â».^QÊѪVûÑMŽbd÷/âЪ^Q*ÝAW› C5·²’•hÅòSk9þÐúÔ[}ÅK¨ÊxW“Ÿ(r¯ÚëÀkÔoˆí…
ÅÉ«Y/ÇM8´hŠSS<ô¹YµD
ÞSib
Œ6UiZcM†Ñ©ŒÈ~ù‘¢qêm¿49ä[ÒzX-–ìh‚“WIËÉu#Ÿ} ª‡³zƊå£úP‚¢FÅ1>Uvs¹àöÔ§LtÂ
æ나$,1cÆz$ÑÏB‰±xǕù¿¬_i–Šï§ì®•y0hôŽÀïÚəBÇU–ÓýZì¶iK"C܌E¼`—<Ëv×:¨­›%Rb
Φ4vÛEkܑŸ‚—²·õ#GÎYq¨
»5oGÁ;ÂùÌÎÛc¹"hÞµà`X¬Â
߉crî“>¹£Ô³N>›…¦û[éäJB<¦¢)w½cdŒ ¯*oæíø
]&è^¾²!)÷e†ƒ|C2i1cöòoÕðȈ/Âßü7ÉýϧÌ|×÷él›í1oØ),ˁ‘ʯϙ9ìD‡×µªk?½Ùs¬½%’ìŠçœtÏv‰RÂ!R†jǦ*­i°Ñ>ø©Í£/*D,Õ
 IX ªÔB5ê4mŸ’iÏe4W§6CaŸ¸#°ñAì
Ž0C¿»i~fÓfò~q¾Á
xL–~ª
ñmF¯èIœRY–YCp杖ßoICY‹†¤Œ<úX–œçÚk—õb¢dj˜
>Æ~¶£j³Bg’êö‚È.¤ÀÊY˜ò²XÚìŸÏ?R½®5ömI¬LÏיïK
õtg!»6~?måԐ»Îå«u׆M^8¡„·
ñ|f9‰ÔŒCIF’VÂؘ—FqÄQj]¾p‹Ê3”3ñý]R
”Y×êâÂy×VégZ6?©·ë|ª·ƒº'/ՍWÅ4»œ>û>Î9¶÷Êw2)ò^–^êÎ1mÐdßiªƒž-?· 
õVE܉cU#»¨ßMѬ×15‘\òß:“SYwaÃ3ž·9)¤åe0|K¤Eéø…\]«ˆÎ`ÜW¼]*¨U>\òm1|?ßåTyoº˜ûS„Ä5rlK)èpóT}ö2PäC±þò;¿
|X”Ãj·ú¹œ…‰¯›ŠTI"dá>¢dR¿/ŸwÐþŸk^ûÃ
äï1†X|[#XÅà…:uÊ}¥iX…#•ènÒ6Ü_”„“{1Á’ñ–, 2²
´´ÔáGήÌ÷Wæ¿­îCÓ`/‘\I²"Óô
Øéx‰QÉÅá£âuMd'~я8yH¼­gûæ,³¯¢§µ¡ 
ýàSè´{3Ù¤•Åª5|-Ž­°©|3®Zޚ©r‚Ïl²Š¼áƒ}a²§¢gt[då¿i1ð‡MÌ|ià‘ÐÜR2&ëD›Õ¾c0·àÝæC 
|Wci¢T_*T;¬ûmÇtðLàץËNç´ ò_¯w‰
;9Q«"^î
¿:4vlqOë>ûœ®ñý±åÉû†*J'äÃ>å'tVw¬{º5ƒ
iƒð£?öêâqŠŸ³Ú_“¦ód¨(]ÊÅéUÍìKÌ
éZÎ

___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm